FDE 面试题库

超过五十道已反馈的前沿部署工程师面试真题，覆盖全部九种轮次类型——每题附有标准答案的结构要点，以及练习链接。

前沿部署工程师面试考察的是：你是否值得被单独托付给客户——把模糊的问题转化为有明确范围的计划、快速掌握一个陌生的系统、写出能应对需求变化的代码，并在客户、数据或你自己的公司提出异议时做出正确的判断。

题库按轮次对已反馈的题目进行分组。每道题给出的是优秀答案的结构，而非逐字稿，因为面试官评分的是你的方法和你说出的权衡取舍，而不是表达是否流畅。请大声练习并计时，对于需要现场实操的轮次，请使用配套的实验和挑战。

问题拆解轮——已反馈的题目

• 城市出租车车队
• “分析一个城市的出租车数据以改进车队。” 开场先问：用户是谁——司机、调度员还是城市？要改变什么决策？然后是约束条件（有哪些数据、数据归谁所有），接着列出 3 个按优先级排序的子问题，最后深入其中一个。练习此题
• 911 响应时间
• “你会如何缩短 911 的响应时间？” 陷阱：一上来就提出路线优化。正确做法： 先定义“响应时间”（从呼叫到派单？从派单到到达？），找出时间实际消耗在哪里，然后攻克最大的那一段。练习此题
• 跨 5 个系统的欺诈检测
• “统一分散在五个系统中的欺诈信号。” 将其框定为实体解析 + 延迟预算 + 误报成本。询问分析师目前的工作流程，以及漏掉一个案例与一次误报各自的代价。练习此题
• 网约车平台
• “为一个网约车平台设计一个系统。” 先问平台的哪一方、哪个指标、什么时间范围。平台类问题考察的是你能否选定一方并为其辩护。练习此题
• 医院再入院率
• “一家医院想用 AI 降低再入院率。” 先问谁会根据预测结果采取行动、何时行动。一个在出院窗口期内无人能据此行动的模型毫无价值。先定义干预措施，再谈模型。
• 两周，而非几个季度
• “如果只有两周而不是两个季度，你会如何界定范围？” 这才是真正的问题。说出唯一的工作流、唯一的指标、唯一的用户，以及你会砍掉的四件事。说明你会从中获得什么能改变计划的认识。

快速学习轮

• 无文档的库
• “这是一个没有文档的内部库——用它实现 X。” 方法：先浏览整体结构，把你的理解模型说出来，针对真正含糊的部分提出一个精确的问题，然后动手使用。练习此题
• Palantir：包安装器
• 已反馈的 Palantir 变体：一个涉及并发问题的自定义包安装器。 注意顺序保证和共享状态。说出你尚未理解的部分——在这一轮中，不懂装懂是最快的失败方式。
• 复述讲解
• “把你刚读的内容解释给我听。” 回答结构：目的、两三个关键抽象、让你惊讶的一点，以及在依赖它之前你会检查什么。
• 快速上手新领域
• “你如何在陌生领域快速进入状态？” 具体方法胜过热情：阅读团队已有的产出物，跟随某个人观察一天，建立术语表，然后讲给领域专家听，让他们纠正你。手册

渐进式编程 —— 逐步升级的约束

• 缓存 → LRU → 线程
• “实现一个缓存 → 改成 LRU → 加上容量限制 → 改成线程安全。” 先写出简单且可扩展的版本。重构之前先说明哪些地方会出问题。练习它
• Anthropic：LRU 系列
• 据反馈，Anthropic 的题目系列：LRU、调用栈操作、去重。 每一步都会推翻前一种解法结构。无法吸收下一个约束的压缩式聪明解法就是陷阱。练习它
• Sierra：电子表格
• 据反馈，Sierra 的题目：对公式电子表格求值 → 然后检测循环。 先做拓扑排序求值，再做环检测。把第一版设计成图结构显式可见，这样第二阶段只是一个小改动。相关练习
• 现在数据量扩大 10 倍
• “现在让它能处理 10 倍的数据量。” 先问清楚是内存还是延迟更重要，然后只改一处并说明原因。流式处理、批处理或索引——三选一，不要全上。

调试与重构

• 重复计数
• “这个聚合逻辑重复计数了。找出原因。” 经典的植入 bug：以可变字段或非唯一字段作为字典/HashMap 的键。方法：复现，缩小到最小失败输入，然后阅读代码。练习它
• 分页遗漏
• “这个分页循环漏掉了记录。” 游标差一错误，或 token 刷新后重新读取第 1 页。通过统计不重复的 id 数量来验证，而不是页数。相关练习
• 图遍历结果错误
• “这个图遍历报告的分布结果不对。” visited 集合放在了递归调用之后而不是之前，或者该用集合的地方用了队列。练习它
• 三个植入的 bug
• “这个代码库里植入了三个 bug。把它们找出来。” 评分看方法而非速度：完整阅读，提出假设，添加最小的检测手段，修复，验证，然后检查同类问题是否出现在别处。每一步都要讲述出来。Sierra 循环
• 只在生产环境变慢
• “为什么这个集成只在生产环境慢？” 询问数据量、网络出口流量，以及重试是否在叠加。只在生产环境出现意味着是环境问题：数据形态、延迟或并发。

带回家作业与答辩

• 为什么选这个结构？
• “为什么选这个结构而不是显而易见的替代方案？” 在构建过程中就写下三个权衡。说出你否决的替代方案就是答案。实战手册
• 你没有构建的部分
• “你决定不构建什么，为什么？” 这是整轮面试中得分最高的问题。README 中明确列出“不构建清单”可以提前回答它。
• 你怎么知道的？
• “你怎么知道它是正确的？” 为硬性属性编写测试，为模糊输出准备一个有明确指标和目标的评测。“它能用”却拿不出证据，是你能做出的最无力的主张。评测
• 中途超时
• “如果这个调用中途超时会怎样？” 用幂等性、带抖动的重试机制，以及用户会看到什么来回答。演练
• 你在哪里使用了 AI
• “你在哪里使用了 AI，又拒绝了什么？” 在允许使用 AI 的地方保持透明度能加分。绝不要把决策归因于某个工具来解释——成果是你自己的。Distyl 规则
• 再多两天
• “如果再多给你两天，你会做什么？” 这个问题把每个缺口从疏忽转化为明确的权衡取舍。务必在书面材料中包含它。

客户角色扮演与案例

• 错误的功能需求
• “客户想要一个你知道无法解决其问题的功能。” 先问他们想要达成什么结果，坦率指出不匹配之处，再提供一条能达成结果的路。绝不要一味顺从，也绝不要直接拒绝。练习
• 现场演示失败
• “你的演示在他们的 CTO 面前现场失败了。接下来的六十秒怎么办？” 点明问题、界定范围（“这是数据接入路径的问题，不是模型的问题”）、承诺一个时间，然后继续演示其余部分。处理得当，它比一场完美无瑕的演示更能建立信任。练习
• 被安全团队阻塞
• “安全团队阻止了你访问数据，两周过去了。” 展示你在被阻塞时仍能保持进展：合成数据、不需要访问权限的部分，以及一次有明确责任人和截止日期的并行升级。手册
• 暗中破坏者
• “一位中层经理在暗中破坏项目推进。” 假设对方有合理的利益诉求，而非恶意——通常是编制或功劳。找出他们能从中得到什么。先升级上报才是失败之举。练习
• 一个你给不出的数字
• “高管想要一个你目前无法诚实给出的数字。” 给出你能站得住脚的数字、你何时能拿到真实数字，以及什么因素会改变它。绝不要编造精确度。
• 衡量成功
• “你会如何衡量这次部署是否成功？” 采用率（谁每周在使用它）、工作流指标（时间或错误率），以及在留出集上的评测质量。三者都要准备好。手册

价值观与判断力

• 一个坏主意用例
• “一位客户想把系统用于你认为是个坏主意的用途。” 具体的过往案例胜过原则。说出你提出异议付出了什么代价。Anthropic 循环
• 犯了错，而且影响重大
• “讲一次你犯了错且影响重大的经历。” 要有真实的错误、错误的机制，以及你之后在结构上做出的改变。“我学会了更好地沟通”不算答案。
• 拒绝上线
• “什么会让你拒绝交付某个东西？” 要有一个明确的底线，以及一个你实际执行过这条底线的故事。没有具体例子的空泛道德表态是这一轮最常见的失败模式。
• 向上提出异议
• “你如何处理与自己公司立场不一致的情况？” 展示你实际使用过的升级路径，并说明你最终无论结果如何都坚定执行了某个决定。
• 一个带来麻烦的风险
• “描述一个你标记过的、令人为难的风险。” 好的判断力故事都附带代价：一次延期、一场艰难的对话、一单丢失的交易。

带客户色彩的系统设计

• 每天 20 万个 webhook
• “设计一个每天处理 20 万个 webhook、且允许 2 小时故障窗口的接入系统。” 队列 + 幂等键 + 死信队列 + 重放。说明你离开之后由谁来运维。设计
• 银行租户隔离
• “一家银行不愿意共享数据库。设计多租户隔离方案。” 隔离级别及其成本曲线：行级 → schema 级 → 数据库级 → 部署级。选定一种，并针对合规要求为其辩护。设计
• 监管机构审计追踪
• “他们需要一个监管机构认可的审计追踪。” 只追加写入、防篡改、谁在何时看过什么、保留策略，以及导出功能。设计
• 本地部署、无互联网
• “模型必须在本地运行且无法访问互联网。” 权重交付、更新路径、许可授权，以及无出站流量情况下的可观测性。设计
• 机密数据 RAG
• “为他们的机密文档库设计 RAG 系统。” 权限控制要在检索时生效，而不仅仅在索引时——这是企业 RAG 最常见的失败点。设计

行为层面的担当

• 交付了，但没人采用
• “讲讲你交付过但没人采用的东西。” 这是最典型的 FDE 面试问题。要坦率地承认诊断结果：问题错了、用户错了，还是时机错了——以及你本可以更早发现什么。
• 对客户说不
• “你什么时候对客户说过不？” 要包括这段关系最终如何变得更牢固。糟糕地拒绝很容易；这一轮考察的是如何拒绝得好。
• 端到端的部署
• “带我完整走一遍一次部署的全过程。” 探索 → 范围 → 构建 → 集成 → 部署 → 衡量 → 交接，并包含一个具体数字和一个犯过的错误。反复演练，直到能在四分钟内讲完。
• 最难搞的利益相关者
• “描述你共事过的最难搞的利益相关者。” 不要把对方妖魔化。描述他们的动机、你尝试过什么、什么奏效了，以及你会有哪些不同做法。
• 换一种做法
• “你犯过什么错误，如果重来会怎么做？” 要准备一个代价真正惨重的例子。给出一个“安全的无失误”回答的候选人，会被认为缺乏实战检验。
• 为什么选择 FDE？
• “为什么选择 FDE 而不是产品工程？” 因为你想要完整的全过程——从问题到生产再到有人真正使用它——而且客户这一半让你充满能量，而不是消耗你。对比

你要问他们的问题

• 写代码的时间占比
• “我预计有多少比例的时间是在写代码？” 这能区分真正的构建者型 FDE 岗位和顶着这个头衔的准售前岗位。
• 产品中的 FDE 工作
• “给我看一个 FDE 上个季度构建的、现在已经进入产品的东西。” 这是最强的单一反服务陷阱信号。一个具体的回答是强烈的买入信号。
• 利用率目标
• “我的考核是否有任何部分与利用率或计费小时挂钩？” 如果是，你时间上的激励机制就已经倒置了。为什么这很重要
• 出差，白纸黑字
• “出差的预期是什么，能否白纸黑字写下来？” 这是无补偿的成本。要在签字之前弄清楚，而不是之后。
• 交接之后
• “一个项目如何结束，交接之后谁负责值班？” 这既定义了你的职责范围，也定义了你的夜晚。
• 谁来定义成功
• “谁来定义一次部署的成功，并且是否事先写下来？” 一个无法回答这个问题的组织，会用一个不断变动的目标来评判你。

方法套路

一个逐分钟拆解的回答

1. Clarify (2 min):     who is the user, what decision changes, how will we measure it?
2. Constraints (1 min): data available, who owns it, timeline, compliance
3. Break down (3 min):  three sub-problems, ranked by value and feasibility
4. Go deep (10 min):    design the top one end to end, naming each trade-off
5. Close (2 min):       what you would build first, what you would learn, what would change the plan

面试官对顺序的评分和对内容的评分一样重要：先澄清再解决、先排序再深入，正是这一轮所寻找的信号。

带有 FDE 变体的 STAR 故事（实操示例）

Situation:  a logistics customer's dispatchers ignored our routing tool
Task:       raise weekly use from 2 of 30 dispatchers to most of them
Action:     shadowed two shifts, found the tool hid the one field they needed, shipped a fix in four days
Result:     24 of 30 dispatchers using it weekly within a month
Lesson:     adoption problems are usually workflow problems, so I now shadow users before building

变体在最后一行：FDE 面试官想听你之后做出的结构性改变，而一个具体的数字能让故事可信。

五分钟内为 take-home 答辩

1. The problem in one sentence, and who it is for
2. What you built, shown working on a real input
3. Three trade-offs, each with the alternative you rejected
4. What you deliberately did not build, and why
5. How you know it works: tests, an eval, the numbers
6. What you would do with two more days

第 3 点和第 4 点是大多数候选人最薄弱、也是面试官提问最多的地方，所以要在构建过程中就记下来，而不是事后。

权衡与局限

每一行都是用一点短期的光鲜，换取这一轮所评分的信号：你独自面对客户时会展现出的判断力。

常见错误

• 先解决后澄清。 面对 911 提示直接跳到路由算法，跳过了被评分的部分：定义指标并找出时间都花在了哪里。
• 第一部分写炫技代码。 在约束递增的环节中，一个无法吸收下一个需求的压缩式解法，损失的时间比它节省的还多。先写朴素、可扩展的版本。
• 在学习环节虚张声势。 假装理解一个不熟悉的库是最快的失败方式。把你的心智模型说出来，并明确指出你还没理解的部分。
• 一个安全的“无错”故事。 一个没有付出任何代价的失败故事，读起来就像没经过实战检验。带一个有真实代价的失败，以及你事后做出的结构性改变。
• 在利益相关者故事里塑造反派。 把一个难缠的人描述成问题本身，暗示你遇到冲突会先选择升级上报。描述对方的动机，以及你尝试过什么。
• 没有关于岗位的问题。 不问编码时间、利用率目标和交接流程，你就无法分辨这是一个真正的构建者角色，还是顶着这个头衔的售前岗位。

自我检验

分解题提示：“一家连锁杂货店想用 AI 减少食物浪费。”你在前两分钟会做什么？

先澄清，正如第一个配方的第一步所说：用户是谁（下单的门店经理、中央采购员、可持续发展团队）、哪个决策会改变（订货量、降价时机），以及如今浪费如何衡量、基线是多少。然后是约束条件、三个按优先级排序的子问题，并对其中一个深入展开。一上来就谈需求预测模型，又掉进了 911 陷阱。

增量式编码：第一部分是“构建一个缓存”，面试官说后面还会有更多部分。你会怎么写？

一个接口清晰的普通缓存，

get

/

put

把存储和淘汰顺序分开，这样后续加入 LRU、容量上限和锁都不需要重写。大声说出每个可能的下一个约束会破坏什么（

）。一行炫技式的实现正是 Anthropic 那一行警告的陷阱。

客户角色扮演：“CFO 明天要向董事会提交一个 ROI 数字。你只有一个团队两周的试点数据。”你会怎么说？

遵循给不出的数字：给出你能站得住脚的数字，明确限定在该团队和这两周内，说明你何时能给出全公司范围的估算，以及哪些因素可能改变它。把一个团队的结果当作确定无疑地外推到整个公司，正是那一行所禁止的虚构精确性。

带回家作业答辩：“你为什么没用数据库？”你是故意不用的。最有力的回答结构是什么？

说出被否决的备选方案和权衡（为什么选择这个结构？）：内存存储让你把时间集中在核心问题上。说明没有数据库会带来什么问题（持久化、并发写入）、你什么时候会加数据库，并指向 README 中的“不构建清单”（你没有构建什么、再多两天）。

关于 The FDE Interview Question Bank 的问题

什么是前沿部署工程师？

前沿部署工程师是一种直接与客户合作、让产品在客户环境中部署落地并产生价值的软件工程师。这一角色由 Palantir 推广开来，如今在 AI 公司中很常见。日常工作包括与用户进行需求挖掘、编写生产代码和集成、让产品适应杂乱的真实数据，并把客户的需求反馈给产品团队。它与咨询的区别在于，这项工作的目的是让产品对每一个客户都变得更好，而不是提供一次性的服务。

我该如何准备 FDE 面试？

每一轮面试要分别准备。练习口头拆解开放式的商业问题，从澄清性问题开始。演练需求中途变化的渐进式编程题，比如一个缓存先变成 LRU 缓存、再变成线程安全的缓存，并写出易于扩展的代码。有条理地调试不熟悉的代码。准备四五个关于客户、失败、分歧和说“不”的具体故事，每个故事都要有一个数字和一个教训。最后，准备一些关于该职位有多少比例是写代码、以及项目如何收尾的问题，因为这些答案能揭示这份工作的真实面貌。

FDE 和解决方案工程师有什么区别？

解决方案工程师或售前工程师主要支持销售：在合同签署前进行需求调研电话、演示、技术答疑和概念验证。前沿部署工程师则主要在售后工作，驻扎在客户现场构建、集成和部署生产级软件，通常要写大量代码，并对采用率等结果负责。不同公司的边界各不相同，有些 FDE 岗位实际上做的是售前工作，所以候选人应该询问写代码的时间占比，以及上一位 FDE 上个季度交付了什么。