FDE 面试在测什么
如果说普通软件工程师面试的中心是编码和系统设计，FDE 面试的中心就是陌生情境下的判断。Palantir、OpenAI、Anthropic 的公开职位描述共同要求的东西可以捆成两束：生产级的工程能力，以及站在客户面前的沟通。所以面试也被设计成同时敲打这两样的形式。
形式因公司而异。本文不是抄录任何公司的面题库，而是从公开的职位要求反推、归纳出三种代表性形式的备考指南：技术诊断场景、客户模拟、案例研究。无论出哪一种，共同点都是：被评分的与其说是结论的准确度，不如说是收窄过程的质量。这一点与系统设计面试完全一致。
技术轮 — 系统诊断场景
最有特色的一轮。出的不是算法题，而是这样的题（构造的示例）：「客户那边从今早开始，一部分 API 响应间歇性失败。我把这个环境共享给你，请开始诊断。」有的公司给真实环境，也有口述型——面试官应你的提问口头描述系统状态。
这里评分的是三件事。第一，顺序。第 4 篇手册里讲的复现、切层、假设、验证的结构是否长在身上。一上来就乱翻日志的候选人，和以「先确认症状能否复现」开场的候选人，第一句话就分出高下。第二，提问的质量。能否问出诊断所需的信息。面试官兼任客户角色，不提问、靠猜测狂奔这件事本身就是扣分项。第三，出声思考。要不断把「现在在看什么、为什么看」说出来。沉默中抵达正确答案，不如边说边亲手推翻自己的错误假设得分高。
客户模拟轮
面试官扮演客户。构造的示例：「我是这个导入项目的业务负责人。三个星期了，什么看得见的东西都没有。我们团队已经有人提议砍掉这个项目了。你解释一下。」接受考验的不是技术知识，而是第 5 篇里那整套肌肉。
评分点是翻译与期望管理。能否从带情绪的话里剥出事实（「您说的看不见东西，具体是指哪个界面？」），能否用已确认的事实和下次汇报时刻代替辩解，能否把术语换成对方的语言。还有道歉与担责的平衡——一味道歉的候选人会挂，一味怪系统的也会挂。练习方法只有一个：请同事扮演客户，出声演练。写在纸上的答案，在压力袭来的瞬间就蒸发。
案例研究轮
带回家作业或现场展示：给你一个虚构客户的情境，让你拿出计划。构造的示例：「一家制造业客户想用我们的平台做设备数据分析。请设计 PoC。」被整体评分的，是从白纸起步做计划的能力——也就是第 6 篇的全部内容。
强答案的骨架是固定的：先把成功标准定义到数字和裁判；把数据边界和安全评审钉进第一周的日程；激进地收窄范围；写明失败条件和下一步。弱答案的共同点是技术架构讲得很细、运营设计一片空白。若是展示型，减少页数、把一页纸的成功标准文档放在中心，印象分更高。
备考方法 — 把 RPG 任务当面试彩排
作为对三轮都有效的练习工具，本博客备有 FDE 工程师养成 RPG。31 个现场任务全部从「太慢了」「连不上」这样的报告开始，在有限的时间、信任度、访问权限内敲定诊断——正是技术轮的缩影。提供三种用法。
- 出声解题。选择任务选项之前，像真实面试那样先用语言解释为什么选它，再点下去。这就是出声思考的直接训练。
- 换着角色解。单人救火、团队驻场、售前 PoC、交接四种角色胜利条件不同。尤其售前 PoC 角色与案例研究轮的手感重合。
- 用领域等级找短板。任务里反复卡住你的领域，就是面试前要补强的领域。用 FDE 课程路线图把那个领域的清单填满。
最后的建议 — 会说「我不知道」的人拿到 offer
FDE 面试的每一轮都被设计成必然出现你不知道的东西——毕竟陌生本身就是这份工作的本质。所以最后一个评分项是校准：把自己知与不知的边界画准，在未知区间用原理推理、并提出验证方法。把这个句式装进身体：「那部分我没有实际运维过。按原理推断应该是这样——实际操作时我会这样确认。」它发出的信号是：这个人在现场不容易做出危险的决定。而面试官找的恰恰就是这个。
到这篇为止，FDE 完全指南系列就结束了。从定义一路走到面试——如果你不是按顺序读的，请用下面的列表补上空缺。
亲手练习
- FDE 工程师养成 RPG — 31 个任务、6 个巡检场景、4 种角色、8 个领域。整个系列的练兵场。
- FDE 课程路线图 — 10 个领域 65 项技能的自检清单。
FDE 完全指南系列全篇
현재 단락 (1/25)
如果说普通软件工程师面试的中心是编码和系统设计，FDE 面试的中心就是陌生情境下的判断。Palantir、OpenAI、Anthropic 的公开职位描述共同要求的东西可以捆成两束：生产级的工程能力，...