OpenAI 的面试既不像传统大厂那样高度套路化，也不是完全偏研究导向的随便聊聊。更准确地说，它是一套把工程能力、抽象能力和一定程度研究思维融合在一起的面试体系。大多数候选人的流程从 recruiter call 开始，接下来通常是两轮技术面试（一轮 coding，一轮 system design），通过后进入 onsite。
Coding 题很少追求特别刁钻的算法技巧，反而更偏向工程化的问题建模。最典型的一类是感染问题——围绕二维网格展开，给定初始感染源按规则扩散。最基础解法是 multi-source BFS，但真正的难点来自后续扩展规则，比如加入免疫单元、感染阈值、恢复机制，甚至多阶段状态变化。做这类题时真正的考察点不是 BFS 本身，而是你如何处理同步更新、如何设计状态机，以及能不能正确处理各种边界情况。
另一类常见题是结构设计类问题，例如 toy language 或类型推断。核心是构建抽象语法树、处理泛型绑定以及递归式的结构匹配。它不考 parsing，而是直接操作对象结构，更像是在写一个小型类型系统。代码量不大，但对思维清晰度要求很高。
还有不少题偏向工程实现，例如 batching API calls（收集一批再发，加时间窗口，加并发，讨论 failure retry）、distributed log merging（k-way merge heap，streaming/iterator 形式，加入 failure handling）、retry with backoff scheduler（基本 retry，引入 exponential backoff，要求 jitter 避免 thundering herd，讨论任务持久化或 crash recovery）。关键在于时间调度是否准确、任务状态管理是否清晰，以及边界情况（比如最大等待时间、任务取消）。
System Design 部分不会局限在 AI 领域。面经中出现的题目范围很广，包括聊天系统、URL 短链、支付系统、日历甚至在线游戏。从题面来看都是常见题，但面试风格有一个明显特点：会深入细节。不是简单画一个高层架构图，而是会继续追问具体组件如何实现、瓶颈在哪里，以及在不同约束下如何权衡。
几乎所有面经都提到一个共同点：反馈不透明。很多时候你很难知道具体是哪一轮出了问题，甚至在感觉整体表现不错的情况下仍然被拒。最终决策依赖整体 signal 而不是单轮表现，只要某一部分不够 strong，即使没有明显 fail 也可能影响最终结果。