拿到录用

面试流程考什么，逐一定级

先说清我们知道得有多少。没有哪家雇主公布自己的 FDE 面试流程，也没有人公布过通过率，更不用说哪几轮能预测交付做得好。现有的只是候选人自述，由面试准备网站从规模很小、自我选择的样本里收集而来。本章对面试流程的每一处描述都是 T4：汇总起来的轶事。招聘启事是更好的证据，但只证明一件窄事，即雇主要求什么，本章也只在这个意义上使用它们。

带着这层保留，各方自述在大致形状上是一致的。编程轮几乎总是有，而且它是底线：没过，其他一切都不算数；过了，它也决定不了多少。与软件工程面试不同的轮次有三类。拆解轮交给你一个开放问题，看你怎样把它变成可以动手构建的东西。带回家作业或构建题不只要能跑，还要能对照客户的需要为它辩护。项目深挖要求你为自己做过的东西里的每一个决定辩护。三者问的是同一个问题，只是换了装扮：为什么这样做、为这个客户这样做，你又怎么知道它奏效了？

作为本章论点的支撑，这些证据很弱。记录最详细的面试流程属于历史最久、也最不典型的 FDE 模式；第二家靠的是两份自述和一份指南；第三家是一片空白。论点之所以站得住，是因为它不需要精确的面试流程数据：不管那一轮叫什么，FDE 面试官想看到的，都是技能地图里那些简历显示不出来的行为，而判断和产品正是招聘启事衡量得最差的两个领域。

这就定下了时间预算。这是经验法则，不是数据：练编程，练到中等难度的题无论用不用 AI 助手都成了家常便饭，然后把剩下的时间投到 16.6 节的项目和限时拆解练习上。如果启事把算法列为必备基础，也要为一轮标准的软件工程筛选留出时间。如果一套面试流程只有编程和系统设计、别无其他，那就相信它：这份工作多半是挂着 FDE 头衔的 AI 工程（16.7 节）。

证据告诉不了你什么，以及去哪里准备

有三处空白值得注意：任何一轮都没有通过率；没有任何关于雇主如何给各轮加权的说明；也没有证据表明专门的“客户角色扮演”轮在哪里是标准配置。那份唯一经过核实的 OpenAI 候选人自述把两轮标为“客户互动”，却没有描述角色扮演，OpenAI 的指南也没有提到。

正是最后这处空白里，一个回声数字正在成形。APPSO 的一篇中文文章于 2026 年 8 月以爱范儿的名义经 36氪转载，描述了一套五轮的 Anthropic FDE 面试流程，其中有一轮客户模拟；文章把这套流程归于 Reddit 上发布的一份指南，并给这一轮附上了一个淘汰率，来源只写了“有机构估算”（APPSO，经 36氪转载，2026 年 8 月 29 日；T3 转述一条匿名的 T4）。本书不转述这个数字。以后再看到任何 FDE 面试轮次的通过率，先问是谁统计的、统计了多少候选人、在哪里统计的；到目前为止，没人说得出来。

按公司逐家准备的资料已经很充足；直接链接过去，并按样本量给每份资料定级：

• Aced（原名 Exponent）的面试流程指南最详细，链接见上面的框。每份指南都列出了背后有多少份候选人经历，而数量都很小：用它们来了解轮次名称和题目，不要用来看比率。
• Paden Gayle 的免费 FDE 手册（Maven），约十页，承诺讲清“想被录用必须展示的四件事”。它的落地页上没有说出这四件事是什么。这是一位从业者的视角（T4）；按页面的说法，作者是一位创始 FDE，正在为 O'Reilly 写一本关于这个角色的书（目前为抢先版，12 章中已发布 2 章，预计 2027 年 12 月出版）。

拆解就是计时的需求挖掘

拆解轮看起来像一道问题是编出来的系统设计题，把它当系统设计来答的候选人，会在第三分钟就开始画框，然后输掉。这一轮其实是把一次交付的头两周压缩进一小时。拿“改善纽约交通”来说。弱的回答去设计传感器数据管道。强的回答先问客户是谁、他们靠推动哪个数字领工资：交通管理局、配送车队和市长办公室，各自需要不同的系统。

方法就是第 II 部分教的那一套，只是要边做边说出来。五步，按顺序：

• 杠杆。谁在提问，他们向上汇报哪个数字，“更好”对他们意味着什么。如果面试官不肯说，就自己提一个，并说明这是假设。这就是需求挖掘里“说出的问题与观察到的问题”的那个难题。
• 工作流及其数据。谁在做这项工作，数据在哪里、归谁所有，第一周你能接触到什么。说清哪里会很棘手。
• 首个成果和“暂不做”清单。挑一块重要且几周内做得完的切片，并说出你放下了什么。这就是划定范围，而“暂不做”清单是面试官最常听不到的那一步。
• 数字，以及你怎么核查它。一条基线、一个阈值和一个小评测集，和懂这项工作的人一起建。评测一章讲的就是这个；据报道，OpenAI 的系统设计题问的正是这一点。
• 什么会出问题，你走后谁来运行。那条绝不能破的规则，在模型之外强制执行；以及你离开后负责这套系统的团队。

到这时才画架构：能越过阈值的、最不花哨的那个方案。六十分钟一轮的经验法则（不是自述数据）：第十五分钟前讲完杠杆和工作流，第三十分钟前讲完首个成果和数字，剩下的时间给架构。一位候选人很晚才讲到架构，但杠杆清楚、首个成果范围划定、数字明确，他已经做到了这一轮要考的东西。另一位为一个从没说清的问题画出了完美的架构，他只展示了这份工作里 AI 工程的那一半，别的什么也没有。

深挖才是考判断的地方

带回家作业的答辩和项目深挖，是客户行为和判断行为能被看见的地方，因为它们问的是已经做过的决定。它们深挖的，是评分标准里 L2 和 L3 那几行所写的东西：一个有人认可的数字，一个有人反对过的范围，一条坏消息以及之后发生了什么，一套如今由别人运行的系统。

所以只讲一次交付，并且按这个顺序讲。要的是什么，实际出了什么问题。数字是什么、谁认可的、基线是多少。你拒绝了什么，为什么它是承重的（“压力下的判断”里有值得坚守的四条承诺）。它没达标的那一刻，以及你给出的计划。现在谁在运行它。每个回答里都说出一个角色和一个日期，并且说清哪些是你的负责人做的、不是你做的；好的面试官会找到那条接缝。

保密协议让这件事比听起来更难。反复练习，直到这个故事不用一个专有名词也立得住；如果去掉客户的名字它就散了，那它讲的是客户，不是你。

入行的路径

从各家的要求能看出门在哪里，而每一扇门都是同一个考验：证明你曾为别人负责过一个问题。大多数岗位是中级。少数直接招应届毕业生，通常是那些这个角色由来已久的平台型公司。好几家雇主点名欢迎前创始人，大概是因为创始人为自己的产品做过需求挖掘、划定范围和交接。还有好几份启事直说个人项目也算证据，16.6 节的作品集项目正是为这个口子准备的。每种背景各自带来的短板，见技能地图。

中国值得单独看，因为那里的门挂的牌子不一样。见诸报道的启事偏重社招，常见的明文门槛接受 toB 交付经验来替代工程经验。论点相同，市场不同：交付就是客户工作，这为实施工程师、售前工程师和项目经理打开了路径。证据是两篇文章和几份启事，只是一个方向，算不上地图。正如“FDE 是什么，不是什么”所提醒的，要查清职位族：归在销售支持下的实习和归在研发下的实习，练出来的是两种不同的工作。薪资和更大范围的市场，见“FDE 在哪里工作”。

一个作品集项目，做成交付的样子

做一个项目，而不是五个。在干净数据上做五个演示，是把技术 L1 做了五遍，而 L1 重复再多也加不出 L2。一个形似交付的项目能喂饱每一轮面试：拆解轮用得上你那个“说出的问题与观察到的问题”的故事，项目深挖用得上一个有人认可的数字，行为面试用得上你拒绝过的那件事。

不容商量的部分，是一位不是你自己的真实用户。一位开源维护者、一家小诊所、一个公益组织、朋友的小生意、你现在公司里的一个团队：问题是他们的，他们可以不同意你的阈值，而且在你停手之后还会继续运行这个东西。没有这个人，项目就没有见证人。技术栈远没有那么重要。把规模控制在四到六个周末能做完的程度（这是经验法则）。

要准确说出它能证明什么。只做一次，按技能地图自己的规则，它产出的是一次性的数据点，而不是级别。做得好，这些数据点在每个领域都落在 L2：如果它在用户的环境里、用用户的真实数据运行并配有评测集，就是技术 L2；如果用户认可了你的“说出的问题与观察到的问题”摘要，就是客户 L2；如果你给所用工具的维护者发了一份反馈简报，就是产品 L2；如果你在风险落地之前书面标出了它，就是判断 L2。任何领域都没有 L3，因为每个 L3 都需要一个本可以拒绝的有权者。在面试里就这么说；知道自己的证据止于何处，本身就是判断。

PORTFOLIO PROJECT BRIEF                         date: ____________
Project: ______________________  User (not you): __________________
Their role: ___________________  Will run it after: _______________

1. PROBLEM
   As stated by the user: __________________________________________
   As observed (what you watched, how long): _______________________
   The number they care about: _____________________________________
   User agreed the observed version?  YES / NO   date: ___________

2. SCOPE
   First win: ______________________________________________________
   Not now:   ______________________________________________________
   Never (rule enforced outside the model): ________________________
   Success metric: __________________  baseline: ___________________
   Threshold (set by the user): ____________________________________

3. EVAL SET
   Source of cases: ________________   size: ______   held out: ___
   Who labelled: ___________________   agreement between labellers: _
   Failure categories found: _______________________________________

4. THE BUILD
   Where it runs (theirs, not yours): ______________________________
   Acts or proposes?  ACTS / PROPOSES   why: _______________________
   Result vs threshold: ____________   date measured: ______________
   The bad news, if any, and the plan you gave: ____________________

5. HANDOFF README (what the user needs without you)
   How to run / stop it: ___________________________________________
   How to tell it is wrong: ________________________________________
   Who to ask when you are gone: ___________________________________

6. EVIDENCE MAP (skill map, Ch 3; one-offs, not levels)
   Domain      Level shown   Artefact            Witness
   technical   ___________   _________________   _______________
   customer    ___________   _________________   _______________
   product     ___________   _________________   _______________
   judgment    ___________   _________________   _______________
   Cannot show (and why): __________________________________________

下面填好的版本是一个演示用的例子，不是真实项目：为一个中等规模的开源库做 issue 分拣。其中的数字都是示意性的区间。

PORTFOLIO PROJECT BRIEF                     date: 6 weekends, done
Project: issue triage, OSS library  User: lead maintainer
Their role: one of 3-5 volunteers   Will run it after: maintainers

1. PROBLEM
   As stated: "we need a bot that answers user questions"
   As observed: read 2 months of issues and sat in on 2 triage
     calls; new issues wait days for a first label, and a large
     share are duplicates or mislabelled bugs vs questions
   The number they care about: time to first triage
   User agreed the observed version?  YES   date: weekend 1

2. SCOPE
   First win: propose a label + likely duplicates on new issues
   Not now:   answering questions; auto-closing; the docs site
   Never: anything mentioning security is routed to a human,
          checked by a keyword rule outside the model
   Success metric: label agreement with maintainers; time to
     first triage   baseline: from 6 months of issue history
   Threshold (set by the user): "as good as a tired maintainer,
     and nothing waits more than a day"

3. EVAL SET
   Source: closed issues with final labels   size: a few hundred
   held out: the most recent month
   Who labelled: 2 maintainers re-labelled a sample of ~50
     to check the history; they agreed on most, not all
   Failure categories: feature requests filed as bugs; vague
     one-line issues; issues in other languages

4. THE BUILD
   Where it runs: the project's own CI, on its own token
   Acts or proposes?  PROPOSES   why: a wrong close drives
     contributors away; a wrong suggestion costs one click
   Result vs threshold: below on labels at first, met after
     two rounds of fixes   date measured: weekend 5
   The bad news: told the maintainer at weekend 3, with the
     three failure categories and a re-measure date

5. HANDOFF README
   How to run / stop it: one workflow file; delete it to stop
   How to tell it is wrong: weekly count of overridden labels
   Who to ask when you are gone: the maintainer, who ran a
     full re-deploy from the README while the author watched

6. EVIDENCE MAP (skill map, Ch 3; one-offs, not levels)
   Domain      Level shown   Artefact            Witness
   technical   L2 (once)     CI workflow, evals  maintainer
   customer    L2 (once)     stated/observed     maintainer
   product     L2 (once)     brief to the label  its author
                             tool's maintainers
   judgment    L2 (once)     security rule,      maintainer
                             written weekend 1
   Cannot show: any L3; nobody with power refused anything,
     and it ran once, for one user

注意这个例子里没有什么：排行榜分数、新颖的架构，或者聊天机器人。拒绝对方要的聊天机器人，是这份简报里最有力的一句，因为那正是每次交付第一周的动作。背后的模型只是个脚注；评测工程见评测 101和评测集维护。带上这份简报，让项目深挖按它的各节顺序走下去。

反过来面试他们

质疑者最有力的证据与招聘有关。“FDE 是什么，不是什么”里那些失望的受聘者，接下的工作后来发现其实是服务工作，而且是入职之后才发现的。Gayle 的课程从另一面说明了同一点：因为“定义仍未确定”，它教的是“在评估一个岗位、一门课程或一份招聘启事时”如何分辨其中的差别（O'Reilly 直播活动页面；T4）。

所以把面试流程当作双向的需求挖掘。拆解轮显示雇主怎样框定一个客户问题：如果面试官只想要一个架构，这份工作要的也就是架构。项目深挖显示他们追问什么：如果没人问是谁认可了你的数字，工作中也不会有人问。关于面试流程本身，有三个问题值得问用人经理，因为答案描述的就是这份工作。下面的解读是本书的经验法则，不是数据：

• “在这里，最常把一位强工程师刷掉的是哪一轮？他们漏掉了什么？”回答“编程”，意味着这是一道附带出差的软件工程门槛；回答“他们太快跳到解决方案”，意味着客户这个领域是真的。
• “这套面试流程里的每位面试官，过去六个月里都在客户现场待过吗？”没待过的面试官会按自己懂的东西打分，也就是代码。
• “带回家作业的评分标准奖励什么？”如果没人说得清一个经过辩护的范围是否胜过一个精致的演示，那这一轮就是编程测试。

然后再问工作本身；这些问题本书已经准备好了：按阶段逐项检查的招聘启事清单，技能地图里每个领域一个问题，以及“起源与经济账”里关于雇主经济模式的五个问题。两个含糊的回答就是一种模式。录用之上的职级阶梯是什么样子、这种节奏要付出什么代价，是“职级、倦怠与下一步”的主题。