# FDE 面试：90 秒内讲好一个“坏消息”故事

> 项目哪里出了问题，面试官并不太在意。他们更关心的是，你发现问题后的几个小时里做了什么。

原文: https://fdetimes.net/zh/guides/fde-interview-bad-news-story-90-seconds/

你刚在白板上画完一张数据管道图，面试官放下笔：“讲一次你不得不向客户传达坏消息的经历。”你只有不到 90 秒，脑子里却还是代码。

90 秒这个时长有依据。ClavePrep 是一个专注 FDE 岗位的面试练习网站，它建议每个行为面试故事控制在 90 秒以内，排练时控制在 75–90 秒左右。Residency Advisor 的行为面试通用指南把目标定在 60–90 秒，并认为超过 2 分钟的回答都有问题。

这类问题也不会只被问一次。Aced 的 Palantir 面试指南提到，行为题几乎出现在每一轮面试中，而不是集中在某一轮专门考察。因此，这个故事必须精炼到能在技术面试中途讲完。

## 他们打分的是你发现问题之后做了什么

对前线部署工程师（FDE）来说，这道题让面试官提前看到真实工作的样子：部署延期、脏数据、双方预期不一致。Aced 建议把失败类问题当作对自我认知的考察。你需要给出具体的例子，并清楚说明之后改变了什么。

当客户的预期与现实出现偏差时，ClavePrep 推荐的做法是尽早说出来，并附上具体的替代方案。项目经理们的看法也差不多：Alison Sigmon 在 MPUG 上写道，拖得越久，事情失控的风险就越大。

所以，一个好的回答要回应面试官从不明说的三个问题：你多早发现了问题？你承担了自己那部分责任，还是推给了别人？你只带来了坏消息，还是同时带来了供相关方决策的选项？

**要点:** 面试官打分的不是你遇到的事故，而是你得知坏消息之后立刻做了什么。

## 拆解一个示范回答

常用的讲述框架是 STAR：情境（Situation）、任务（Task）、行动（Action）、结果（Result）。情境和任务只需交代到让听者理解背景即可。大部分时间应该留给行动，讲清你本人的贡献及其结果。

90 秒的一种分配方式：情境约 15 秒，任务 10 秒，行动 40 秒，结果和教训 20 秒。合计 85 秒，稳稳落在 75–90 秒的排练区间内。

假设有一位候选人，之前在一家物流客户那里担任 FDE。下面是一个假设场景，按候选人在面试现场的实际说法写成：

**情境。**“我是现场唯一的 FDE，负责把客户的仓库管理系统接入预测平台。我向运营负责人承诺，四周内交付生产环境版本。”

**任务。**“我的任务是兑现这个承诺。到第二周，我发现历史数据里大约三分之一的商品编码有重复，或者中途被改过。”

**行动。**“我先承认了自己的失误：我在做数据剖析之前就承诺了日期。当天我写了一个脚本，精确统计每个仓库有多少条坏记录，然后找运营负责人要了 20 分钟，而不是等每周例会。”

“在那次沟通里，我摆出了三个选项：用数据干净的那一半仓库按原日期上线；推迟两周，全部仓库一起上；或者由他们的团队手工修正编码，保持原日期。我也直说了，估算失误在我。”

**结果。**“客户选择先用一半仓库上线。从那以后，我在承诺任何日期之前，都会先在头三天做数据剖析。”

这个回答能拿分，原因有三。失误是真实的，而且说得很准：没检查数据就承诺了日期。坏消息在发现当天就传达了。而且它被转化成了一个决策，给客户三个选项去选。

最值得注意的一步，是写脚本按仓库统计错误数。这对应 MPUG 介绍的 SED 方法中的“评估”步骤：在传达消息之前，先整理信息、筛出相关内容、找到可选方案。技术面试官会从中看到一种习惯：把“数据有问题”变成一个数字，再变成一个决策。

结果并不完美，项目只在一半仓库上线。这没关系。自我认知的考察恰恰需要这样的收尾：一个你从此一直保持的数据剖析习惯。

## 如何打磨你自己的故事？

先把所有你不得不告诉别人不想听的事情列出来：错过的截止日期、砍掉的功能、没达到承诺的数字、估错的工期。如果你从未直接对接过客户，PM、其他团队或你的上级同样算作相关方。

挑一个你确实负有部分责任的故事，然后写下你得知问题的确切时间点。准备好应对一个大概率会来的追问：从知道到说出来，你花了多久？如果间隔很长，就直接承认，并把它变成教训。

接下来，用你自己的动词写行动部分。辛辛那提大学（University of Cincinnati）建议聚焦个人贡献，用“我”代替“我们”。“我们决定推迟截止日期”对面试官了解你毫无帮助，“我摆出了三个选项，并推荐了第一个”才有用。

然后计时、删减。初稿通常在背景上花了太多时间，而真正得分的是行动部分。ClavePrep 建议围绕五个核心主题各准备一个有力的故事，坏消息故事应该是其中之一。

一个好故事还能应对换了问法的问题。Aced 提供的 Palantir 示例题中有一道是“讲一次你拒绝客户需求的经历”。上面的物流仓库例子同样能回答这道题，只要把重点转到你拒绝维持四周日期的那一刻。

## 让好故事变成弱回答的几种错误

最糟糕的错误是怪别人。哪怕客户确实错了，这也会让你在自我认知这一项上直接失分。你可以说他们的数据很脏，但下一句应该是你自己本该怎样做得不同。

其次是故事太顺：你发现了问题，你解决了问题，皆大欢喜。这听起来像是贴着失败标签的成绩，也没给“你改变了什么”这个问题留下空间。

最后一个错误是讲得太长。如果回答超过 2 分钟，你几乎肯定是在描述背景，而不是你做了什么。

这个故事在面试之外也有用。在简历上，像“第二周发现数据缺陷，提出分阶段上线方案，一半范围按原日期交付”这样一句话，比任何形容沟通能力的词都更能证明你与相关方协作的能力。

最好的坏消息故事，不是让你显得最好的那个，而是能说明你之后如何改变工作方式的那个。在有人问之前，先把它写下来。

**本周动手试试:**

- 写下一次你不得不向客户或 PM 传达坏消息的经历：你什么时候得知有问题，以及你提出（或本该提出）的三个选项。
- 大声讲一遍并计时。不断删减，直到控制在 75–90 秒以内，并且行动部分约占一半。
- 回听录音，数一数你说了多少次“我们”，再把每一次都换成你自己做的一件具体的事。

## 信源

- [Forward Deployed Engineer Behavioral Interview: STAR Stories That Actually Work](https://claveprep.com/blog/forward-deployed-engineer-behavioral-interview)

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

- [How Long Should a Strong Behavioral Interview Answer Actually Be?](https://residencyadvisor.com/resources/behavioral-interview-questions/how-long-should-a-strong-behavioral-interview-answer-actually-be)

- [STAR Method for Behavioral Interviews (University of Cincinnati)](https://www.uc.edu/campus-life/career-co-op-support/interviews/biginterview/star-method-behavioral-interview.html)

- [Using the STAR Method for Your Next Behavioral Interview](https://guarinigrad.dartmouth.edu/resources/using-the-star-method-for-your-next-behavioral-interview/)

- [How to Tell Stakeholders the Bad News (MPUG, Alison Sigmon)](https://mpug.com/articles/how-to-tell-stakeholders-the-bad-news/)