第 15 章　求职与面试：判断公司，也让公司判断你

15.1 先看目标函数，再看职位名称

FDE 在国内仍有多种名称。同样叫 FDE，有的负责业务发现到生产采用，有的只做售前 POC，还有的本质是长期驻场开发。

阅读 JD 时，先看公司希望这个岗位拿到什么结果。是否直接面对用户，是否编写或负责生产系统，考核看验收还是业务采用，现场经验能否回到产品。

职位名称可以包装，组织归属、日常责任和考核方式更难伪装。

简历不应把过去经历强行改名为 FDE，也不要堆砌“熟悉 RAG、Agent、MCP”等词汇。

更有效的写法是说明场景、责任、行动和结果。例如，不只写“负责客服系统开发”，而是说明为哪类用户解决什么问题，自己参与了需求澄清、系统接入还是上线运营，最终改善了什么指标。

没有直接业务数据时，可以写交付周期、稳定性、错误率、采用范围或复用情况，但不要编造 ROI。能够清楚说明结果边界，比一个无法核实的巨大数字更可信。

转型作品应单独突出，因为它能证明你正在把旧能力与 AI 交付连接起来。

FDE 面试常给出一句不完整的问题，例如“医院希望用 AI 缩短患者等待时间”。面试官通常不期待你立即画出架构，而是在观察你怎样处理不确定性。

回答顺序可以从用户与结果开始：患者在哪个环节等待，谁在管理流程，当前基线是什么。然后确定边界、数据和风险：哪些数据可用，哪些判断必须由医护人员完成，错误后果是什么。

最后才提出验证方式：先选择哪个窄场景，最大假设是什么，怎样用小范围试点和指标证明价值。

好的回答会公开自己的假设，并在获得新信息后调整；差的回答通常在问题尚未定义时就决定模型和技术栈。

系统设计题不仅考查组件，还会关注数据流、权限、评测、监控、成本和故障恢复。候选人应能解释为什么采用某种组合，以及哪些部分保持确定性控制。

现场故障题可能从“回答突然变差”“某部门看到了不该看的资料”或“模型调用成本飙升”开始。处理时先控制影响，再确认版本和范围，随后根据日志区分数据、检索、模型、工具和权限问题。

不要在证据不足时迅速归因，也不要只修当前样本。说明怎样补充监控、评测或流程，防止同类故障再次出现。

FDE 的行为面常关注承担责任、艰难取舍、客户冲突和失败复盘。准备经历时，应选择真正发生过的事件，讲清当时信息、个人责任、具体行动和结果。

失败故事不必包装成完美成功。能够说明自己错在哪里、怎样发现、如何降低影响以及后来改变了什么，更能体现判断力。

不要把所有困难都归咎于客户或同事。FDE 经常处在多方之间，面试官会判断你能否尊重不同目标，同时推动事实和决策向前。

面试也是候选人调查岗位的过程。可以询问：FDE 的代码进入哪个仓库；团队属于产品、工程、销售还是交付；项目成功看哪些指标；现场需求如何进入产品路线；上线后谁维护；项目范围失控时谁能决策；出差、驻场和 on-call 的实际比例是多少。

还可以请对方描述最近一个项目从发现到上线的过程，以及沉淀了什么可复用资产。真实细节比抽象口号更有判断价值。

如果公司要求你对结果负责，却不给数据访问、技术决策和产品支持，这份工作可能只有责任，没有授权。

FDE 可能因为复合能力、客户压力和出差要求获得更高薪酬，但数字必须结合地区、行业、公司阶段和职责理解。海外岗位待遇不能直接外推到国内。

还要计算隐性成本：驻场频率、工作时间、出差、上线支持、项目稳定性和能力是否可复用。一份高薪岗位如果长期按人天救火，可能很难积累产品和行业资产。

好的早期岗位未必名称最标准，但应让你更接近真实问题、生产系统和结果反馈。

求职 FDE 不能只匹配关键词。候选人要用真实经历和作品证明闭环能力，也要穿过职位名称，判断公司的目标函数、授权、产品回流和工作代价。

除了加入一家公司，FDE 能力也可以被用于副业、自由职业或创业。但独立面对市场时，技术之外的责任会更多。