FDE 招聘要的 API 功底，远不止简历上一个“REST”

GenLogs 的前线部署工程师（FDE）招聘启事没有写“熟悉 API”。它要求的是深入掌握 REST API、Webhook 以及 OAuth2/SAML/Auth0 流程。简历技能栏里只写一个“REST”，招聘方看不出这几项里你真正做过哪些。

GenLogs 并非个例。DataCamp、FullStack 和 Simplilearn 在介绍 FDE 岗位时，都把 API 列为基础能力。一项技能几乎出现在这个岗位的每一份描述里，简历上写出它的名字并不能让你脱颖而出；招聘方需要看到你真正打通过两个真实系统的证据。

所以，如果目标是 FDE 岗位，问题不在于简历上要不要写 API，而在于简历能否表明你经历过 API 最容易出问题的那些环节。

真实集成通常在哪里出问题？

假设你要把一家公司 CRM 里的客户列表同步到自家产品。CRM 里有 12,000 条记录，每页返回 100 条，限流为每分钟 60 次请求。

第一笔账很好算：120 次请求，至少要 2 分钟。所以代码收到 429 时必须懂得暂停并重试，而不是在第 61 页直接挂掉。

再假设 OAuth2 访问令牌有效期很短，在你同步到第 80 页时过期了。演示程序会停在这里，报出 401。真实的集成会自己刷新令牌，从第 80 页接着跑，并且不会把已经拉取的 79 页重复写一遍。

Webhook 也有自己的坑。CRM 通知某条记录发生变更时，同一个事件可能到达两次，也可能恰好在你的服务重启时到达。演示程序会忽略这些情况，真实集成则必须提前考虑。

APIBouncer 关于用 API 构建作品集的指南也是这样看的：加载状态、错误、空结果和限流，正是能体现写代码的人懂行的细节。这份指南还认为，处理不一致、分页、偶尔出错的 API 数据本身就是一项真本事，值得展示。

FDE 不只调用 API，还要设计 API

CRM 的例子只是工作的一半：调用别人 API 的那一侧。GenLogs 的招聘启事对另一半也有要求。它的 FDE 要把客户需求转化为技术需求、API 规范和数据模型设计，然后主导 GenLogs 产品与外部系统之间的集成实施。

也就是说，你既是 API 的使用者，也是决定两个系统之间契约的人。难点在于，这个决定必须在客户的环境里经得住考验。据 The Pragmatic Engineer 报道，OpenAI 的 FDE 直接在客户的基础设施上写代码，使用客户的工具，而不是在自己的沙箱里。

这也是为什么 DataCamp 把对接客户的数据、API、基础设施以及内部身份与权限系统列为日常工作，并把工程基础视为没有商量余地的要求。

FullStack 列出了把 AI 工具接入企业软件所需的全套技能：REST、GraphQL、Webhook、OAuth 和 SAML，同时强调集成中人的一面。

具体来说，人的一面就是这样的问题：谁掌握 API 密钥，谁审批访问权限，客户系统改了数据结构由谁负责。技术文档很少替你回答这些。

有些招聘启事完全不提 API

这里很容易误读市场。Databricks 于 2026 年 11 月更新的 AI FDE 招聘启事，重点是把生成式 AI 应用推向生产环境，以及评测、优化和云端部署。它的任职要求里没有点名 API。

但不提不等于不需要。很难想象一个生成式 AI 应用进入企业系统时，可以不经过认证、不调用内部服务、不接收其他系统的数据。

The Pragmatic Engineer 指出，几乎所有招聘 FDE 的公司都看重扎实的软件工程基础。API 就是这个基础的一部分，隐含在要求里，而不是明文写出。因此，只有当你证明自己超出了基础水平，这项技能才会成为优势。

招聘启事写一行，实际工作重得多

下表把招聘启事的要求、你在客户现场要做的事，以及可以写进简历的证据一一对应起来。

招聘启事写的	在客户那里意味着	简历上应有的证据
REST、GraphQL API	同步分页数据，同时应对限流	一个带重试、能从中断处续传的数据同步项目
Webhook	接收可能重复发送、或在服务宕机时到达的事件	一个从不写入重复数据、并记录遗漏事件的 Webhook 处理程序
OAuth2、SAML、Auth0	在客户的身份与权限系统中打通流程	一个支持令牌刷新和基于角色访问控制的登录流程
编写 API 规范	把客户需求转化为两个系统之间的契约	一份你写的 API 规范，附上设计取舍的理由
主导集成	与客户系统的负责人协作	一行说明你和谁合作、达成了什么共识

第一列谁都能抄到简历上。第三列只有真正做过才会有。

把技能栏变成证据

Simplilearn 的 FDE 学习路线把 REST API 设计和基础认证放在第一步，即工程基础阶段。这份路线还设定了一个具体、可检验的产出：一个带认证的 REST API 项目。

这是一个合理的起点。但对照上表第三列就能看出，只达到起点不足以脱颖而出。

把项目做上一个台阶并不复杂。用真实的 OAuth2 流程替代硬编码在源码里的 API 密钥，再加一个接收 Webhook、能应对重复事件的端点。然后写一份 README，逐一说明每种故障：被限流时怎么做，令牌过期时怎么做，API 返回空数组时怎么做。

简历上那一行也要跟着改。不要写“精通 REST API、OAuth”，而要写清楚你把哪个系统接到了哪个系统，用的是哪种认证流程，处理了哪些错误，结果如何。如果工作中做过集成，挑最难的一个来写，尤其是需要和其他组织 IT 团队协作的那种。

阅读招聘启事时，留意 API 前面搭配的动词。“使用 API”是调用 API 的层次；像 GenLogs 那样“编写 API 规范”或“主导集成”，则是设计和负责的层次，要准备好解释你做过哪些决定。

如果招聘启事没提 API，比如 Databricks，就把它当作隐含要求，按同样的方式准备。

面试前，拿自己的项目做个自测：如果 Webhook 两次通知同一条记录发生变更，恰好又赶上令牌在第 80 页过期，你的数据还正确吗？如果你能用一段真实经历而不是 OAuth 的定义来回答，你的简历就有了一个“REST”说不出来的东西。