# FDE 面试里，敢说“我猜错了”反而加分

> 一句四段式表达，让面试官听清客户中途抛出新事实时，你如何调整方向。

原文: https://fdetimes.net/zh/guides/fde-interview-think-aloud-hypotheses/

你进了终面。面试官扮演客户，一开口就是一句含糊的抱怨。十秒后，你脑子里已经有了一个假设。被打分的不只是这个假设对不对，还有你是否把它说出来，以及五分钟后，你是否愿意承认它错了。

这种场景并不少见。Aced 的面试指南提到，Cognition 的终面就是现场模拟客户，比如向高管做演示，或者进行一场案例分析通话。

Techinterview.org 解释说，前线部署工程师（FDE）的面试模拟的是客户工作中的模糊状态，所以大部分时间在交谈，而不是写代码。这类面试考察的一项能力，就是在情况还不明朗时能否出声推理。

如果你习惯了 LeetCode 式面试，只看最终答案，那么你会在最意想不到的地方丢分。Aced 说得很直白：面试官评的是你如何一步步接近方案，而不是你是否得出某个特定答案。你要做的，是让打分的人听得到这条路径。

## 为什么猜错也能得分？

不妨把这一轮当成一次调试。据 techinterview.org 介绍，FDE 面试看重系统化的调试循环：复现问题、提出假设、缩小范围、验证修复。

Google 的 SRE 一书描述的故障排查正是这个节奏：反复提出可能的原因并加以检验，用实验的方法保留或排除每一个假设。

在这个循环里，排除一个假设和提出一个假设一样，都是在向前推进。SRE 一书还提醒，不要死抓着过去见过的原因不放。在面试现场，证明你没有这个毛病最简单的方式，就是让面试官听到你放弃一个起初深信的想法。

所以 Aced 建议把第一个答案当作草稿，随着新信息到来不断修改，并强调回头修正之前的判断是正面信号，而不是弱点。

Techinterview.org 指出，在 Palantir 式的问题拆解面试中，面试官会故意在中途加一个需求，看你的设计是能弯还是会断。所以要准备好迎接新事实，而不是指望它不来。

**要点:** 面试官评的是你得出方案的路径，而不只是最终答案。

## 一场示例通话，逐句拆解

设想这样一道题。“客户”是一家配送公司的运营负责人，他说：“看板显示，从周一开始延迟配送率翻了一倍。我需要马上知道怎么回事。”没有需求文档，没有数据结构，只有一个让人担心的数字。

较弱的候选人会沉默三十秒，然后提议重写数据管道。较强的候选人会把假设说出来，并标明这是假设，正如 Aced 建议的那样：

“先说明，这只是一个假设。订单可能并没有真的变晚，而是‘延迟’的计算方式变了，比如某次部署改了时区。如果是这样，终端客户的投诉不会比平时多。我想问一下：从周一到现在，有人改过报表系统吗？”

客户回避了问题：“我不知道工程团队在干什么。不过这周呼叫中心的投诉多了很多。”

这一刻最能体现你如何得出方案。较强的候选人不会悄悄换方向，而是明确说出来：“那我们放弃显示错误这个假设。如果只是计算错误，终端客户不会打电话到呼叫中心。”

接着说：“现在我更倾向于订单确实晚了。有两个分支：某个区域变慢，或者整个系统变慢。我会先按区域查，因为如果是这样，修复范围会小得多。”

最后这句话遵循了 techinterview.org 的建议：遇到分岔时，说明你为什么选这条分支。

然后面试官抛出一个新需求：“我老板周五前要一份报告。”较强的候选人出声更新计划：今天先按区域缩小范围，用一批具体订单确认原因；根因修复可以等报告交了再做。

## 写在白板上，让面试官跟得上

SRE 一书建议记录下你想到过哪些思路、做过哪些检验、看到了什么结果。在面试现场，这些记录能让面试官看到并追溯你推理的每一步。上面那场通话的白板是这样的：

| 假设 | 检验 | 结果 |
|---|---|---|
| “延迟”的计算方式变了，订单并没有真的变晚 | 询问系统是否有改动，以及终端客户是否在投诉 | 已排除：呼叫中心收到的投诉增多 |
| 某个区域的订单确实延迟 | 按区域或仓库拆分延迟率 | 等待数据 |
| 整个系统都变慢 | 仅在第二个假设不成立时检查 | 尚未检验 |

“已排除”这一行和“等待数据”那一行同样有价值。它表明你靠证据排除，而不是凭直觉。

## 四段式句子及练习方法

你说出的每个假设都应包含四个部分：“我的假设是 X，因为 Y。如果 X 成立，我们会看到 Z。为了验证，我需要问一下或看一下 W。”其中 Z 最关键。缺了它，你的假设就无法被证伪，面试官也不知道你会在什么时候改变想法。

当证据指向另一边时，用三段式来排除：“这排除了 X，因为它和 Z 矛盾。转向下一个假设。我先选它，是因为……”这句话很短，却让面试官同时看到了证据、灵活性和你排定优先级的理由。

Techinterview.org 给出了一个具体的练习方法：找朋友扮演一个不肯给清晰需求、说话躲躲闪闪的利益相关方，出声完成一轮问题拆解。让朋友故意提供与你第一个假设相矛盾的信息，并在第十分钟时加一个额外需求。

## 让强候选人翻车的错误

最常见的错误是闷头思考。Aced 认为，在问题拆解面试中沉默是负面信号，因为面试官听不到的推理没法打分。你也许想得完全正确，但在评分表上仍然是一片空白。

第二个错误是悄悄换方向：开始谈一个新假设，却没说你已经放弃了旧的。在听的人看来，你是在东跳西跳，而不是在逐一排除。第三个错误是修正想法时道歉，仿佛这是一种失败，而 Aced 恰恰把回头修正之前的判断算作加分项。

最后一个错误更隐蔽：死抓着一个熟悉的原因不放，比如“上次也是缓存的问题”，然后把每个新事实都硬套进去。这正是 SRE 一书警告的陷阱。

## 把这项能力写进简历

这项能力不只用来过面试。在真实客户那里，需求同样模糊，清楚地说出你在排除什么，能让会上每个人都跟得上你。

写简历或准备行为面试的故事时，用上面的三栏来讲一次事故：你最先怀疑什么，哪项检验排除了它，什么证据把你引向了真正的原因。

像“利用呼叫中心数据排除了显示错误，两小时内把事故范围缩小到一个区域”这样的简历条目，比“积极主动”“思维能力强”之类的词更能让读者看清你的工作方式。

下次某个假设在面试官面前崩塌时，不要急着遮掩。说清楚它错在哪里、你接下来往哪个方向走，因为这条路径正是被打分的内容。

**本周动手试试:**

- 请朋友扮演一个不肯给清晰需求、说话躲闪的客户，完成一场 20 分钟的模拟并录音。
- 回放录音，数一数你有几次换了方向，却没说自己放弃了哪个假设。
- 把你处理过的一次事故改写成假设、检验、结果三栏，再把精简版写进简历。

## 信源

- [What the forward deployed engineer interview really tests (techinterview.org)](https://www.techinterview.org/post/3233477236/forward-deployed-engineer-interview/?format=md)

- [How to Answer Decomposition Interview Questions: The Definitive Guide (2026) – Aced (formerly Exponent)](https://www.aced.io/blog/how-to-answer-decomposition-interview-questions-the-definitive-guide-2026)

- [Inside the Palantir engineering interview loop (techinterview.org)](https://www.techinterview.org/post/3233476805/palantir-interview-process/?format=md)

- [Effective Troubleshooting – Google SRE Book, Chapter 12](https://sre.google/sre-book/effective-troubleshooting/)

- [Cognition Forward Deployed Engineer Interview Guide | Sample Questions (2026) - Aced (formerly Exponent)](https://www.aced.io/guides/cognition-forward-deployed-engineer-interview)