最近准备了不少 FDE（Forward Deployed Engineer / Founding Deployment Engineer）岗位，比如Palantir，OpenAI，Anthropic，Databricks，Scale AI，Snowflake，Salesforce ，Cohere，也和几位已经在不同公司工作的朋友交流了一些经验，感觉很多人第一次接触 FDE 时都会有一个误区：以为它只是 SDE + 多和客户开会。实际上，真正的 FDE 面试考察维度比传统 SDE 更宽，很多时候技术能力反而只是进入下一轮的门票。

Coding 能力是基础，但很少是决定因素

FDE 面试当然会考 Coding，而且不少公司的要求并不低。LeetCode Medium 基本属于标配，一些岗位甚至会直接考偏工程化的问题，例如日志处理、数据转换、REST API、SQL、ETL Pipeline，或者让你快速完成一个能够运行的小系统。不过和传统互联网 SDE 不太一样的是，代码写完以后，讨论才刚刚开始。面试官往往会继续追问如果数据量扩大一百倍怎么办、如果客户的数据格式每天都在变化怎么办、如果线上部署失败应该如何恢复。因此，他们真正关注的不只是你能不能写出 AC 的代码，而是你是否具备工程思维，以及能否把代码放到真实生产环境中继续思考。

System Design 更像解决真实客户的问题

很多传统 SDE System Design 喜欢讨论 Twitter、Instagram、短链接或者秒杀系统，但 FDE 的设计题通常会更加贴近真实业务。比如设计一个企业数据同步平台、构建 AI Workflow，或者帮助客户把现有系统接入新的 AI 平台。整个讨论过程中，面试官会不断加入新的限制条件，例如数据不能离开欧洲、必须部署在客户自己的 VPC、预算有限、第三方 API 有严格 Rate Limit 等等。真正想考察的是你如何在各种现实约束下不断调整方案。

Business Understanding 往往比技术细节更加重要

这是很多纯 SDE 背景候选人最容易忽略的一点。很多客户提出的问题，表面看起来是技术问题，实际上根本原因可能完全不同。例如客户觉得模型太慢，真正的问题可能是 Prompt 写得不好、Workflow 太复杂、上下文过长，甚至只是缓存没有做好。因此，优秀的 FDE 往往不会急着开始设计系统，而是先不断澄清需求，确认真正影响业务指标的是什么。他们会询问最终 KPI、真正的用户是谁、哪些约束是必须满足的、如果只能解决一个问题最希望解决什么。很多来自 Palantir、OpenAI、Anthropic 等公司的面试反馈里，都提到面试官特别喜欢观察候选人是否有这种不断确认需求、主动发现问题的习惯。

沟通能力直接影响整体评价

FDE 面试几乎一定会包含大量开放式讨论。有时候面试官会扮演客户，不断修改需求、增加限制，甚至故意提供模糊的信息，希望看看候选人如何推进整个讨论。真正优秀的候选人不会急于给出答案，而是能够一步步确认假设，把复杂的技术概念用简单的语言解释清楚，再逐渐收敛到最终方案。很多时候，即使最后的设计方案不是唯一最优解，只要整个沟通过程逻辑清晰、能够持续验证自己的判断，整体评价依然会很高。

Ownership 是所有 FDE 岗位都会重点观察的能力

很多 FDE 项目都具有很强的不确定性。你可能需要同时和客户、产品、基础设施、数据团队甚至法务沟通，也可能没有现成的解决方案可以参考。因此，Behavioral Interview 经常围绕 Ownership 展开，例如项目失败怎么办、客户临时修改需求怎么办、上线当天出现严重 Bug 怎么办、团队意见无法统一怎么办。相比强调自己完成了多少开发工作，面试官更希望听到你如何推动事情向前发展、如何协调不同角色、如何在信息不完整的情况下做出合理决策。

AI 已经成为越来越常见的考察方向

随着越来越多企业开始落地大模型应用，许多 FDE 岗位已经把 AI 能力纳入了核心考察范围。面试中经常会讨论什么时候应该使用 RAG、什么时候适合 Fine-tuning、Agent Workflow 如何设计、为什么选择某种向量数据库、如何减少 Hallucination、如何设计 Evaluation Framework 等内容。不过，大多数公司并不会要求候选人具备顶级的 AI 研究背景，他们更关注的是，当客户希望上线一个 AI 产品时，你是否能够快速理解需求，并结合业务场景做出合理的技术取舍。像 OpenAI、Databricks、Snowflake、Scale AI 等公司的不少 FDE 岗位，都会围绕这种工程落地能力展开讨论。

最后说一句

如果一定要总结 FDE 面试到底在考察什么，我觉得它并不是单独考算法、系统设计或者沟通能力，而是在确认你是否能够独立面对一个没有标准答案的问题。从理解业务需求，到设计系统、编写代码、推动项目落地，再到和客户持续沟通，每一个环节都需要自己做判断。很多人把 FDE 理解成会写代码的售前，但真正优秀的 FDE，更像是站在客户现场的技术负责人，能够在资源有限、需求不断变化、信息并不完整的情况下，依然把事情一步步推进到最终落地。