Robinhood SWE / Dev Infra 面经

💡 核心要点 (Key Takeaways)

• Robinhood SWE 主流流程是 Recruiter talk → 45 分钟店面 Live Coding → 三轮 VO（Project Deep Dive + System Design + Coding），部分岗位前置 OA，整体节奏快，面完第二天就能主动要 feedback
• System Design 最高频是 Job Scheduler（支持定时创建、准时可靠执行、超时处理、历史状态与日志查询），多位候选人反馈这题主要出现在 Senior+ 轮次；Dev Infra / Platform 背景是它的天然主场
• Coding 两大高频方向：图论（DAG 节点触发计数 / 拓扑排序变体）和业务规则 OOP 设计（支付系统：注册、好友请求、转账，request id 映射是经典坑），且多轮明确只能用 Python
• 最常见挂点：图论题 edge case（非连通节点 / 不存在课程）卡住、支付系统忘记存 request id 映射、System Design 缺后端与分布式基础被连环追问后提前结束、项目深挖讲不出 ownership

这篇适合谁：Robinhood SWE / Dev Infra 面试定位

一句话定位：这是基于 2025 下半年到 2026 年公开面经信号整理的 Robinhood SWE / Dev Infra 面经，覆盖 Mid、Senior、Staff 各级别的店面（Live Coding）和 VO 轮。

适合以下几类读者：

- 投 Robinhood SWE / Backend / Platform 的社招候选人：想确认「Robinhood 面几轮、每轮考什么、难度对标什么」。
- Dev Infra / 基础设施 / 工具链背景的工程师：包括 C++ SDK、test framework、CI/CD、调度系统方向。多份面经显示，背景不完全重合的 infra 候选人也能拿到面试，infra 背景在 Robinhood 的 System Design 轮反而有天然优势。
- Security 工程方向候选人：Robinhood 的 security 岗位偏工程和系统层面（权限系统、审计监控、key 管理），不是纯安全研究，准备方式和 SWE 有重叠。

Robinhood 是 fintech startup 里面试节奏快、流程简洁的代表。和站内已有的 Coinbase SWE / MLE 面经 相比：Coinbase 主轴是 CodeSignal OA + 迭代式 LLD + crypto 场景设计；Robinhood 主轴是 图论店面题 + Job Scheduler 系设计题 + 支付系统 OOP 编码，且整体轮次更少、节奏更快。如果你同时在准备两家公司，这篇和 Coinbase 那篇可以对照着看。

面试流程：Recruiter talk → 店面 → 三轮 VO

把 13 篇 2025-07 至 2026-08 的公开面经放在一起看，Robinhood SWE / Dev Infra 的主线流程是：

1. Recruiter talk / HR call（15-30 分钟）：介绍岗位和团队，了解背景，确认意向和级别，谈初步薪资范围。有候选人反馈这一轮会直接确认能给到的 level（比如 IC4 和 Senior 的区别）和薪资 band，建议面前提前查好市场行情再谈。

2. 店面 / 技术电面（45 分钟，Live Coding）：一道 live coding 题，边写边讲。题目难度在 LeetCode Medium 左右，但 Robinhood 对 edge case 的覆盖要求不低——多份挂经都卡在边界条件上。有候选人反馈店面是原题复现（和面经社区流传的题一致），也有候选人反馈店面题和后续 VO 的 coding 题会重复，做过之后面试官会直接换题。

3. VO / Onsite（三轮，每轮 45-60 分钟），典型组合是：

- Project Deep Dive（PDD）：选一个项目深挖，正常 BQ 混合。有候选人被要求准备 PPT（recruiter 说最多两页）。面试官会追问技术决策、准确度保证、时间分配、「如果重来哪里做得不一样」。
- System Design：一轮完整 SD，Robinhood 最高频的是 Job Scheduler（详见下一节）。多份信号指向 SD 主要出现在 Senior+ 级别。
- Coding（Live Coding）：另一道编码题，多位候选人明确提到「只能用 Python」，方向偏 OOP 设计和业务规则实现（支付系统是最高频）。

4. 结果与时间线：Robinhood 的节奏在 startup 里算快。店面到 VO 通常间隔一周左右，有候选人反馈「VO 第二天就可以主动联系 recruiter 问 feedback」，live coding 结束后 recruiter 发邮件问结果，9 分钟内就收到拒信。整个 pipeline 从 recruiter talk 到终局通常 2-4 周，没有拖很久的公开反馈。

分支流程：部分岗位（NG、部分 SWE 和 Security 岗）会在店面前加一场 OA，约 70 分钟 4 道题，easy-medium 为主，前两道几分钟就能做完；Security 方向的 Staff 岗有完整走 OA → recruiter phone → onsite 的公开记录。前端岗的店面则是 React 实操（组件复用、状态管理、性能优化、accessibility）。以你实际收到的邀请为准。

题型雷达：Coding、System Design、PDD、BQ

Robinhood SWE / Dev Infra 的题型分布可以画成这样（按出现频率排序）：

Coding（店面 1 道 + VO 1 道）——权重最高
- 图论 / DAG 题：节点触发计数、拓扑排序变体。店面高频方向。
- 业务规则 OOP 设计：支付系统类，给定一串操作请求（注册、加好友、转账），实现状态管理。考 extensibility 和 design pattern，不考算法难度。
- 其他：load factor 计算、LRU 类受约束数据结构（Security 岗）、字符串校验（Security 岗）。
- 共性：难度 Medium 上下，但 edge case 覆盖是生死线，且多轮明确限 Python。

System Design——Senior+ 权重高
- Job Scheduler：绝对最高频，多位不同时间、不同级别的候选人独立提到同一题。
- 产品场景设计：基于 Robinhood 产品的 secure 系统设计（user profile 管理 + 股票查询）、实时行情展示。
- Security 场景设计（Staff / Security 岗）：内部权限访问控制（RBAC vs ABAC）、安全审计监控系统。

Project Deep Dive——每一轮 VO 几乎必考
挖一个项目讲 20-40 分钟：技术决策 why、准确度 / 可靠性怎么保证、non-funded project 怎么排时间、如果重来怎么改。

BQ——占比不高但存在
为什么选 Robinhood、最自豪的项目、怎么处理跨职能冲突、ownership 和跨团队协作（Security 岗会追问安全与业务速度冲突时的取舍）。问题不多，follow-up 会比较深入。

Robinhood 和相邻公司的差异：相比 Stripe SWE 面经 里 Stripe 的业务规则 Programming Round，Robinhood 的编码题更偏「数据结构 + 状态机」，SD 更偏 infra / 调度方向；相比 Coinbase 的迭代式 LLD，Robinhood 的 coding 更看重单题内的 edge case 完整度。

高频题目：7 个代表题和考点拆解

以下是从公开面经中反复出现、值得针对性准备的题目类型（只写题型和考点，不复制任何候选人的逐字原题）：

1. DAG 节点触发计数（店面最高频）：给一个无环有向图和一个 entry point，trigger 一次入口，沿边传播，输出每个节点被 trigger 的总次数。考点：DFS/BFS 基础、拓扑排序优化、节点入度 / 触发次数累加的边界（一个节点被多个父节点 trigger 时要累加而不是覆盖）。

2. 拓扑排序变体：课程依赖（带 edge case）：和经典 course schedule 思路一致，但输入是字符串描述的课程列表，且要处理「不连通图中的孤立节点」「输入里引用了不存在的课程」这类边界。多份挂经都卡在这类非连通 / 不存在的 case 上——提前想清楚「图外节点要不要算」是这道题的胜负手。

3. 支付系统 OOP 设计（VO coding 最高频）：给定一串请求（注册、发起好友请求、接受好友请求、转账），实现最终所有账户余额。经典坑：接受好友请求时只给 request id，你得先把「request id → 双方用户」存下来才能按图索骥登记好友；转账只能发生在好友之间且不能超额。考点：实体拆分（User / 请求注册表 / 主流程）、状态一致性、extensibility 表达（访问控制、并发安全怎么设计）。

4. Job Scheduler 系统设计（VO SD 最高频）：支持按 schedule 创建 job、在指定时间可靠执行、job 超时未完成的处理、查询历史 job 状态和日志。考点：从「用户创建 job」开始画数据流、API 设计、存储选型（状态用 DB、日志怎么存）、调度可靠性和幂等。有版本变体：job 失败不需要 retry——以面试时给的约束为准，先澄清再设计。

5. Secure Robinhood 产品设计：基于 AWS 设计 secure 的 Robinhood，deep dive user profile 管理和股票查询。考点：fintech 场景的认证 / 授权、敏感数据保护、查询链路的安全约束。

6. 实时行情展示：给用户展示 asset 最新价格，多数据源整合、websocket 推送、实时更新、scalability。考点：多源数据一致性、推送链路、缓存与降级。

7. Security 场景题（Staff / Security 岗）：受约束数据结构（LRU 思路）在高并发 / 恶意输入下是否可控、字符串校验如何防构造输入绕过、内部权限系统（RBAC vs ABAC、least privilege、权限变更生效与缓存失效）、审计监控（audit log 采集存储、防篡改、不影响主链路）。考点：把 security 当系统问题讲，而不是背安全概念。

• DAG 触发计数 / 拓扑排序变体：店面最高频，edge case（非连通节点、不存在引用）决定过不过
• 支付系统 OOP：VO coding 最高频，request id → 用户映射是经典坑，考点是 extensibility 而非算法
• Job Scheduler：VO System Design 绝对高频，Senior+ 必准备，先澄清 retry 等约束再设计
• Secure 产品设计与实时行情：fintech 场景 SD，认证授权、多源整合、降级是追问重点
• Security 岗加考权限系统 / 审计监控 / 恶意输入下的健壮性，难度对标 Staff
• 多轮明确限 Python——即使你更熟 C++ / Java，Python 的工程写法（类型标注、简洁结构）也要练熟

公开面经信号怎么读

一亩三分地是 Robinhood 面经最集中的公开来源，但 Robinhood 的帖子有个特点：大量高信息量帖子需要社区积分权限才能看全文，免费可见的部分常常只有标题和一句摘要。几个实用读法：

1. 按「年份 + 级别 + 岗位」筛选。Robinhood 的轮次结构随级别变化明显：Mid 可能只有店面 + 两轮技术，Senior+ 才有完整 SD 轮，Security 岗还多一套 security 专题题。2025 年的 IC4 面经和 2026 年的 Staff 面经参考价值差异很大，优先看最近 3-6 个月、级别对得上的帖子。

2. 找共识，不信个例。单篇说「只有一轮 coding」不能当结论。Job Scheduler 之所以被本文列为最高频 SD 题，是因为 2025-09 到 2026-02 的多个独立帖子（不同级别、不同地区）都提到它；「coding 只能用 Python」也是多份面经的共同说法。而「店面是原题复现」只有零星反馈，当参考不当结论。

3. 提取「轮次结构 + 题型方向 + 挂点」，忽略剧情。每篇面经真正值钱的就这三样。帖子标题里的「全套挂经」「昂赛挂经」是挂经信号库——挂经比过经信息密度更高，因为会写清楚「卡在哪一步、被追问什么、面试官在哪个点结束面试」。

4. 看反馈渠道。多位候选人提到 Robinhood 的节奏快：面完第二天就可以主动联系 recruiter 要 feedback，终面 coding 结束后几分钟到几小时内就有结果通知。如果你面完一周没消息，主动问一句比干等更有效。

5. 不搬运、不暗示合作。本站 Robinhood 相关内容只归纳公开信号的方向和共识，不复制任何候选人的逐字面经，也不代表与任何面经社区有合作或转载关系。你读到的公开帖子请以原作者发布的内容为准。

常见挂点：Robinhood SWE / Dev Infra 独有的失分方式

从 13 篇公开面经（过经 + 挂经）里提炼，Robinhood 特有的失分点集中在这几个：

1. 图论题死在 edge case，而不是死在算法。多份挂经的模式完全一致：主算法（DFS/BFS/拓扑）写出来了，但「非连通图里的孤立节点」「输入引用了不存在的课程」「触发次数要累加不能覆盖」这些边界没处理，最后差几个 case 挂掉，面试官中途不会主动提示。Robinhood 的店面题难度不高，但它用 edge case 密度筛人——写完主逻辑必须留 10 分钟过边界。

2. 支付系统忘记存 request id 映射。接受好友请求只给 request id 这个设计坑，至少两位候选人栽在这里（「写的时候总是忘记这点，面试官提醒了两次」）。这类题的考点本来就不是算法而是状态管理和实体设计，同一个坑被提醒两次还没修，signal 就没了。

3. System Design 缺后端 / 分布式基础被连环追问后提前结束。有 infra 背景候选人（四年 C++ SDK + 两年 Python test framework）面 Job Scheduler 时，被从「REST API 是什么」一路追问到「用什么 database」，最后「面试官提前结束了面试」。Robinhood 的 SD 面试官会不断打断拉回主线（「Let's focus on distributed microservice structure, start from data flow」），跟不住节奏、基础概念断片的候选人会被快速判定。

4. Project Deep Dive 讲不出 ownership。有候选人做 SDK 开发多年，觉得「SDK dev 实在没有什么 ownership」，最后只能拿 side project 顶上。Robinhood 的 PDD 轮会追问「这个决定是你做的还是团队的」「non-funded project 怎么排进工作日的」，纯执行者视角的故事在这轮很难拿分。

5. 语言限制没提前适应。多轮明确「只能用 Python」，用 C++ 或 Java 写惯了 OOP 的候选人（访问控制、封装、并发 atomic 这些点）在限时 Python 里容易把时间花在语法上而不是设计上。

6. 级别预期没对齐。有候选人在 recruiter talk 才发现 JD 写的 Senior 岗位实际只能给 IC4。级别和薪资 band 在 recruiter 第一轮就应该谈清楚，否则终面通过后谈崩更亏。

准备路线：7 天 / 14 天 / 30 天

按你距面试的天数选路线。Robinhood 节奏快，从 recruiter talk 到 VO 经常只有一周左右，所以「店面前突击」和「VO 前系统准备」要分开做。三个版本的共同原则：Python 工程写法永远优先，edge case 意识贯穿所有 coding，SD 只练 Job Scheduler 到能应对任何打断追问的程度。

• 7 天（保下限版）：D1-D2 Python 速成 + DAG 触发计数和拓扑排序变体各做 2 遍，强制自己写完主逻辑后专门列 edge case 清单（孤立节点 / 不存在引用 / 累加 vs 覆盖）；D3-D4 支付系统 OOP 做 2 遍，第一遍故意不存 request id 映射感受坑，第二遍一次写对，并口述 extensibility 设计（访问控制、并发）；D5 Job Scheduler SD 按「需求澄清 → 数据流 → API → 存储 → 可靠性 → 日志查询」六步讲 2 遍，每次录音回听检查被追问时是否断片；D6 准备 PDD 故事：选一个有真实 ownership 的项目，按「决策 why → 可靠性 → 时间分配 → 如果重来怎么改」写 20 分钟讲稿；D7 完整 mock：45 分钟店面（图论题）+ 10 分钟 BQ。
• 14 天（标准版）：在 7 天基础上——D8-D10 补 SD 深度：Job Scheduler 之外再做 1 道 fintech 场景题（实时行情展示或 secure 产品设计），每道练到 45 分钟讲完且能接住 3 层追问；D11 把 7 天里做过的 coding 重做，这次限时 35 分钟（留 10 分钟 edge case）；D12 如果投 Security 方向，加练受约束数据结构 + 权限系统 SD（RBAC/ABAC 取舍、审计 log）；D13 准备 recruiter talk 话术：级别预期、薪资 band 调研、为什么 Robinhood；D14 缓冲日，检查设备、Python 环境，早睡。
• 30 天（系统版）：在 14 天基础上——D15-D20 coding 专项：再补 3 道图论 + 3 道 OOP 状态机题（load factor、LRU 变体、字符串校验），每道都写 3 个 test case 并说明为什么选这些 case，练「像工程代码一样写」的习惯；D21-D24 SD 专项：Job Scheduler + 实时行情 + 权限 / 审计系统各 1 道，每道产出 1 页纸架构 + 数据流 + 存储选型理由，重点练「被面试官打断拉回主线时 30 秒内接住」；D25-D27 BQ + PDD：准备 4 个故事（为什么 Robinhood / 最自豪项目 / 跨职能冲突 / 如果重来），每个能接 2-3 层追问，PDD 讲稿练到 20 分钟内；D28-D29 连续两场完整 mock（店面 + VO 各一场），复盘断片点；D30 缓冲日。VO 的沟通闭环细节可以配合 SWE VO Coding 沟通指南 一起看。

FAQ：Robinhood SWE / Dev Infra 面试 5 个高频问题

Q1：Robinhood SWE 面试几轮？
主流是 Recruiter talk → 45 分钟店面（Live Coding）→ 三轮 VO（Project Deep Dive、System Design、Coding），部分岗位前置 OA（约 70 分钟 4 题，easy-medium），Security 方向 Staff 岗有 OA → recruiter phone → onsite 的完整记录。级别越低轮次越少，Mid 级别可能没有独立 SD 轮。

Q2：Robinhood 考 System Design 吗？什么级别考？
考，且 Job Scheduler 是绝对高频题。多份面经反馈 SD 轮主要出现在 Senior 及以上（IC5+）；Mid 级别更可能把设计成分融进 coding 轮（比如支付系统题本身就在考 OOP 设计）。如果你是 Dev Infra / 调度系统 / 后端背景，这轮是你的主场，值得准备到细节级。

Q3：Dev Infra / 非交易背景能面 Robinhood 吗？
能。有候选人背景是 C++ SDK + Python test framework，和 Robinhood 的 infra 方向不算重合，依然拿到了完整面试机会。Robinhood 的 Dev Infra / Platform 岗位对「可靠性、调度、工具链」背景的接受度比纯交易团队高。注意两点：SD 轮会暴露后端 / 分布式短板（这是 infra 背景候选人的最大挂点），PDD 轮要拿出有真实 ownership 的项目。

Q4：Robinhood coding 限 Python 吗？LeetCode 高频有帮助吗？
多份面经明确「只能用 Python」，即使你更熟 C++ / Java，也要把 Python 的工程写法（类设计、类型标注、简洁边界处理）练到限时不卡语法。LeetCode 高频有帮助但不充分：Robinhood 的店面题方向偏图论和业务规则 OOP（支付系统类），不是纯算法难题，真正拉开差距的是 edge case 覆盖和代码组织。建议 LeetCode Medium 图论 / 设计题 + 2-3 道 Robinhood 方向的状态机 OOP 题组合着刷。

Q5：面完多久出结果？需要主动跟吗？
Robinhood 节奏快：VO 第二天就可以主动联系 recruiter 问 feedback；终面 live coding 结束后 recruiter 发邮件问结果，有候选人 9 分钟内收到回复。整体 pipeline 通常 2-4 周。一周没消息主动问一次是合理策略，不需要频繁跟进。