48 小时的居家项目，主体代码大约 6 小时就写完了，剩下的时间拿去测重试、造故障、改边界。这个细节比“某某公司面试很难”更有用。
这是一份经历者摊开的 OpenAI 软件工程师面经：整个流程约两周，按八个环节展开，大约九成人没有走到最后。其中还有一轮公开说明里没有写出的 Agentic Coding，要求候选人使用 AI 编码 Agent。这里的两周、八个环节和淘汰比例，指的是这份个人经历，不是 OpenAI 公布的统一流程或全公司统计。
OpenAI 官方的 Interview Guide 也先把边界写在前面：实际经历会因岗位不同而变化，技能评估可能是 pair coding、take-home project 或 technical test，终面通常是 4—6 小时、4—6 位面试官，分布在 1—2 天。官方对工程候选人的描述，反复出现的是设计质量、代码质量、性能、测试覆盖、沟通和思考过程。
所以这篇文章不打算替这份面经补一套“固定题库”。我更关心它为什么一直追问同一类问题：系统坏了以后，谁来恢复；要求变了以后，你能不能重排方案；Agent 把代码交回来以后，你有没有验收证据。
八个环节，底下其实是一条主线
面试流程很容易把人带进支线任务。初筛像在考简历，编码像在考速度，系统设计像在考术语，行为面像在考表达，Agentic Coding 又像突然换了赛道。候选人如果按轮次逐个背，最后会得到一堆散牌。
把它们放回工程现场，主线就清楚了。
一个服务收到请求，写入状态，交给 worker 处理，失败后重试，最终要让用户看到结果。面试官会在这条链上不断加条件：worker 在半路崩了怎么办？消息重复投递怎么办？数据库写到一半断电怎么办？对端 500 了一小时怎么办？流量突然放大十倍，成本和延迟怎么守？
这时候，背出“最终一致性”没什么用。你要说明哪一个状态是事实，谁有权把它往前推进，重复请求靠什么去重，租约过期以后旧 worker 为什么不能继续写。fencing 标记、WAL、MVCC、幂等键、退避抖动和熔断器，这些术语只有放进因果链里才算牌。
用一个中国团队熟悉的场景想象追问
举个电商仓库的例子。大促当天，支付回调可能因为网络抖动到两次。第一台 worker 拿到“已支付”的消息，写入订单后挂了；第二台 worker 又拿到同一条消息。系统如果只靠“希望它别重复”，那就会重复发货。
工程上至少要回答四件事：订单状态有没有唯一的幂等键；写库和发货之间怎样留下可恢复的记录；worker 处理任务时的租约多久过期；旧 worker 恢复后，凭什么证明自己已经失去写入资格。
这不是为了把面试说得复杂。真实公司里，客服、仓库和财务最后都会来找同一个人：“为什么这单发了两次？”你如果只能说“理论上不会”，那是解释失败；如果能给出日志、状态迁移和补偿动作，才是交付。
OpenAI 的 Platform Systems 岗位公开提到 fault tolerance、failure detection、observability、large-scale debugging 和 distributed systems。Applied Foundations 的岗位则把可扩展后端、分布式服务可靠性、端到端 ownership 和处理模糊问题放在一起。它们并不能证明某一轮面试的固定题目，却能解释为什么这份面经里的追问听起来像生产事故复盘。
48 小时项目为什么要把时间花在失败上
六小时写出主体并不稀奇。调用 API、起一个队列、存几张表，今天的代码助手都能很快给你第一版。难的是第一版之后发生的事。
你要主动让 worker 崩溃，看看任务会不会永久卡在 in-progress；让对端连续返回 500，看看重试是不是变成重试风暴；把同一事件回放两次，看看账有没有重复；把延迟拉长，看看租约是否误判；把成本算出来，看看所谓的高可用是不是贵到不能用。
这些测试不是“加分项”。它们决定你是否理解自己的系统。测试结果、日志片段、失败复盘和下一版取舍，才是项目真正能被别人验收的部分。
Agentic Coding 让验收责任更明显
Agent 能写代码之后，面试准备也容易走偏。有人把重点放在 prompt 写得像不像，或者让 Agent 一次生成更多文件。可公开的 OpenAI harness engineering 文章给出的方向，恰恰是人负责设计环境、明确意图和建立反馈回路，Agent 负责执行代码、测试和文档；Agent 失败时，要找缺失的工具、约束、文档或反馈，而不是只喊它“再认真一点”。
这和那份面经里的 Agentic Coding 是两层证据：前者是官方工程实践文章，后者是个人经历中的一轮面试，不能相互替代。但它们指向同一个工作习惯：代码交回来的那一刻，工作还没结束。
准备这类面试时，可以把项目交给 Agent 做一遍，再自己完成五件事：写验收标准；给出会失败的输入；检查它是否真的执行了测试；审查权限、重试和成本；最后用一段简短记录说明哪些地方仍然不确定。你不需要假装比 Agent 打字更快，你需要证明自己知道什么时候不能相信它。
把面经变成自己的五问
不要再按“第一轮考什么、第二轮考什么”背。拿你最近做过的项目，逐条问：
- 进程突然挂掉，哪些状态会丢，哪些状态能恢复？
- 同一个请求到两次，系统如何避免重复扣款、重复发货或重复写入？
- 对端连续失败时，重试什么时候停止，谁来接手？
- 题目临时增加并发、延迟或成本约束，你先改哪一层，为什么？
- 代码由 Agent 生成后，你拿什么测试、日志和指标证明它真的工作？
答不出来的地方，就是下一周该补的地方。别先去收藏一百篇分布式系统文章，也别急着把简历上的“熟悉高并发”改成“精通高并发”。先在自己的小项目里杀掉一个 worker，回放一次事件，打开一条日志，再把取舍写下来。
面试当然有运气、有岗位差异，也有团队偏好。官方资料已经明确说过，实际流程会因岗位变化。可一个工程判断不会因为换了公司就消失：故障会发生，约束会变化，结果必须有人负责。
这份面经最值得带走的，不是八轮，也不是“九成人没走完”这句刺激人的数字。它提醒你，真正的主线任务是把一个系统从能跑，带到能解释、能恢复、能验收。做到这一步，面试题才不只是题。