FDE 面试：把项目证据转化为现场判断

FDE（Forward Deployed Engineer，前线部署工程师，也常译作前沿部署工程师）面试最有效的准备，不是背“标准答案”，而是把真实项目证据练成可追问的判断过程：如何把模糊业务问题变成可交付范围，如何在约束下做技术取舍，以及如何用证据决定上线、降级或停止。

核验日期：2026-08-19。 FDE/FDSE 的职责与招聘流程会因公司、团队、级别、地区和时间而变化。本页提供的是基于公开岗位职责的准备框架，不声称任何公司采用固定轮次或固定题型。面试前应以目标职位当日说明及招聘方通知为准。

先完成一个证据完整的作品集项目。面试时最有用的材料不是另一份话术，而是你可以打开的 Discovery Brief、ADR、评测结果、威胁模型、runbook 和交接记录。

第一步：为目标岗位建立证据矩阵

每次投递都复制一份矩阵，只使用目标岗位当前页面中的原话。不要把一个公司的职责假定为整个行业的标准。

岗位中的原句	它要求你证明的能力	最强项目证据	可讲的决策/冲突	缺口与补强动作
`[粘贴原句]`	`[例如：与客户界定问题]`	`[Discovery Brief 链接]`	`[哪项范围发生变化]`	`[补一次访谈演练]`
`[粘贴原句]`	`[例如：交付生产系统]`	`[部署、SLO、runbook]`	`[可靠性与速度的取舍]`	`[补故障演练]`
`[粘贴原句]`	`[例如：跨团队影响]`	`[决策记录、交接反馈]`	`[如何达成一致]`	`[量化结果或澄清边界]`

矩阵完成的标准不是填满，而是暴露缺口。若一项关键能力只有“我学过”，没有可指向的证据，就在投递前补一个小实验、文档或演练。

六类值得准备的能力场景

下面六类场景来自 FDE 工作本身，适合用来组织练习。它们不代表某家公司的面试安排，也不保证都会出现。

1. 项目深挖

为旗舰项目准备三个深度：

90 秒： 用户与问题、你的范围、关键决策、同口径结果、当前限制。
8 分钟： 展开从发现到交接的决策链，并能现场打开证据。
30 分钟： 接受连续追问，包括失败样本、替代方案、贡献边界和下一步。

逐项练习这些追问：

你如何知道这是值得解决的问题，而不是客户最先提出的功能？
哪个假设风险最大？你用什么最低成本的方法先验证？
你考虑过哪些方案？为什么没有选择看起来更先进的那个？
指标的分母、样本与基线是什么？结果能否复跑？
哪类用户或数据表现最差？上线时如何保护他们？
哪次反馈改变了你的范围或架构？
如果依赖服务失效、成本翻倍或答案不可用，系统会怎样？
团队中哪些决定和实现确实由你负责？

回答时把事实、判断和推测分开。你可以说“不知道，但我会先检查 X，再用 Y 决定 Z”；不要用不存在的数据补齐故事。

2. 客户发现与范围界定

找同伴扮演业务负责人，用一个模糊请求进行 25 分钟演练，例如：“我们想在四周内给客服团队做一个内部知识助手。”你的目标不是立刻画架构，而是得到可验证的下一步。

按这条顺序推进：

结果： 谁要做得更好？具体是哪项任务或决定？
当前流程： 输入来自哪里，谁操作，输出给谁，失败如何被发现？
基线： 当前耗时、成功率、返工或风险如何测量？
约束： 数据权限、敏感级别、系统依赖、预算、时限和负责人是什么？
高风险假设： 数据是否可用、用户是否采用、自动化是否被允许？
薄切范围： 第一版只覆盖哪个用户、数据源和任务？明确不做什么。
验收与停止： 什么结果允许扩大试点？什么情况必须回退或人工处理？
下一步： 谁在何时提供何种数据或确认哪项决策？

最后用两分钟复述你的理解，让“客户”纠正。演练后不要只给自己打表达分，要检查是否真的得到基线、边界、负责人和决策时间。仓库中的 templates/discovery-brief.md 可直接作为记录板。

3. 系统与 AI 设计

从业务结果向下设计，而不是从模型向上拼组件。白板时可以使用以下顺序：

定义用户、关键任务、成功指标和不可接受的失败。
画出系统边界、信任边界、数据流与人工介入点。
描述离线/在线数据路径、身份传递、租户隔离和审计。
选择最简单的基线，再说明何时需要检索、工具调用或 Agent。
定义离线评测集、发布门槛、在线监控与反馈闭环。
估算容量、延迟、成本与外部依赖；设计超时、重试、幂等和降级。
给出分阶段上线、回滚和交接方案。
明确未知项，以及先做什么实验来减少不确定性。

常见薄弱点是只画“用户 → LLM → 数据库”，没有身份、权限、错误路径、版本、评测和运营责任。用 templates/eval-plan.md 检查设计是否真的可验收。

4. 编码、集成与调试

具体形式以目标岗位通知为准。通用准备应覆盖 FDE 经常面对的工程任务，而不只是一类算法练习：

读取不可靠的外部 API，处理分页、超时、限流、重试与幂等。
清洗并验证有缺失、重复或类型漂移的数据。
写出小而清晰的接口边界、自动化测试和可定位问题的结构化日志。
在信息不完整时复现故障，提出假设，用观测结果逐步排除。
避免把令牌、个人数据或完整模型输入输出写进日志。

练习时保留终端记录或简短复盘：最初假设是什么、哪条证据推翻了它、修复如何防回归。这比只保留最终正确代码更接近真实交付。

5. 评测、安全与运营

准备回答“你凭什么允许它上线”：

评测数据来自哪里，是否代表高价值与高风险切片？
指标如何计算，阈值是谁基于什么风险批准的？
LLM 评审是否与人工校准？不一致如何裁决？
越权、提示注入、敏感信息和危险工具调用如何测试？
哪些门槛是 stop-ship，哪些可以带补救措施试点？
发布后监控什么，谁响应，如何降级、回滚和更新回归集？

不要把“没有看到错误”当成可靠性。准备一个你主动阻止发布、缩小范围或加入人工复核的例子，也能展示成熟判断。

6. 客户协作与行为故事

至少准备六个真实故事，每个故事都要包含你当时掌握的信息、采取的动作、结果证据与复盘：

将模糊请求改写为可验收问题；
与客户或内部伙伴就范围、优先级或风险产生分歧；
在时间压力下砍掉功能并守住关键结果；
技术方案或上线出现失败，你如何响应并修复机制；
说服非直属团队配合数据、权限或流程改变；
完成交接，让系统不依赖你个人才能运行。

避免把所有冲突写成“我解释后对方同意”。强故事会说明对方的合理目标、共同证据、你做出的让步，以及最终如何验证选择。

一张项目面试卡

每个项目只写一页，现场前快速复习：

项目：
用户与关键任务：
原流程与同口径基线：
我的个人责任边界：
最大的不确定性：
我比较过的方案：
关键决策及代价：
交付的最小范围：
质量 / 业务 / 延迟 / 成本 / 安全结果：
最重要的失败样本：
一次范围或方案变化：
上线、降级、回滚与交接：
仍未解决的限制：
可以现场打开的 3 个证据链接：

卡片是事实索引，不是逐字稿。模拟面试时让同伴从任意一行连续追问三次，检查你是否能回到证据。

14 天准备节奏

时间	任务	完成证据
第 1 天	拆目标 JD，建立证据矩阵	每条核心职责有证据或补强计划
第 2–4 天	修复旗舰项目并做三档讲解	链接可访问；90 秒和 8 分钟不过时
第 5–6 天	两次客户发现角色扮演	Discovery Brief 与同伴评分
第 7–8 天	两次系统/AI 设计	有权限、评测、故障、上线与取舍
第 9–10 天	编码、集成和调试练习	测试、日志及复盘记录
第 11 天	评测、安全与运营深挖	能解释阈值、失败和 stop-ship 条件
第 12 天	整理六个协作故事	事实、行动、结果、反思均可追问
第 13 天	一次完整模拟，录音复盘	问题清单与按优先级修复项
第 14 天	轻量复习和环境检查	本地/线上演示、备份、链接与时区无误

两周是冲刺安排，不是能力养成承诺。若作品集还没有 L2 证据，先回到项目补齐，不要用重复模拟掩盖材料缺口。

反向判断岗位是否适合你

面试也是尽调。根据对话自然选择问题，不必全部问：

这个岗位前 90 天应交付什么结果？由谁判断成功？
FDE、产品、销售、研究/模型团队和客户工程团队如何划分决策权？
项目从发现、试点到生产通常有哪些批准门槛？
当客户速度要求与安全、可靠性冲突时，团队如何决策？
生产系统的值班、长期维护和交接由谁负责？
客户现场、出差、时区和并行项目的实际预期是什么？
团队最近一次缩小范围或停止项目的原因是什么？

具体答案比“节奏很快、影响很大”更能帮助你判断岗位。面试结束后立即记录新事实、未回答问题和你暴露出的证据缺口，再决定是否继续及如何补强。

最终检查

我能区分真实客户、试点、同伴测试和模拟场景。
我不会虚构指标、用户反馈、生产规模或个人贡献。
每个关键数字都知道口径、样本、基线、版本和限制。
我能展示失败路径，而不只演示一次成功运行。
我能从用户结果讲到代码，也能从故障讲回业务影响。
我知道何时应拒绝自动化、缩小范围或要求人工复核。
我的问题能帮助双方判断工作方式，而不是复述官网即可找到的内容。

面试复盘暴露出项目证据缺口时，回到学习路线选择对应阶段补强；已经具备完整证据链时，就以本页的项目面试卡持续演练，无需重复堆新项目。

来源与边界

Palantir — Forward Deployed Software Engineer：用于识别客户发现、项目深挖、工程实现与协作故事需要证明的能力。
Palantir — Forward Deployed AI Engineer：用于识别 AI 系统设计、评测与客户工作流结合方面的准备重点。
OpenAI — Forward Deployed Engineer：用于识别企业部署、可靠性和客户反馈闭环方面可被追问的能力。
Anthropic — Forward Deployed Engineer：用于识别客户技术协作、生产实施与安全边界方面的准备重点。

这些来源用于校准职责范围，不用于推断未公开的面试题、轮次或录用门槛。