# HackerRank 的 FDE 不造产品，只配置、调试和讲解

> 伦敦和班加罗尔的招聘只要求够用的 Ruby 或 Python 脚本，真正的难点是在试点期间当着客户的面把事做成。

原文: https://fdetimes.net/zh/analysis/hackerrank-fde-job-configure-debug-explain/

HackerRank 的一则前线部署工程师（FDE）招聘启事，并不是要找人从零构建产品。公司要的是一位站在客户面前的技术负责人，具备足够的全栈功底，能配置、调试和讲清 Web 应用。

伦敦和班加罗尔同一岗位的招聘启事也指向同一方向。其中描述的技术工作包括在需要时用 Ruby 或 Python 针对 API 编写脚本：做够用的集成，而不是搭一套新系统。

不想去 HackerRank 工作，也能从中有所收获。这些招聘启事展示了一家已有产品的公司里 FDE 的样子：主要工作是让产品在客户那边跑起来。如果你是想转向 FDE 的软件工程师，技术部分并不遥远；真正需要练的是站到客户面前。

## 用三个动词代替“构建”

仔细读技术要求：配置、调试、讲清。里面没有提“系统设计”，也没有提“从零构建”。但别把这理解成门槛低。在别人的系统里、顶着试点的压力把这三件事做好，比很多人想的更难。

设想一个假设案例：客户希望自动化候选人测评的结果，能流入它现有的申请人追踪系统（ATS）。

在配置阶段，你要读双方的 API 文档，映射数据字段，也许还要写一个小 Python 脚本做同步。到了调试阶段，你发现分数没有显示，原因是某个 webhook 返回了认证错误，而谁都看不到这个错误。

讲清阶段决定试点的成败。客户的招聘负责人不需要知道 token 如何过期。他们需要知道：上周的候选人数据有没有丢，系统什么时候恢复运行，以后还会不会再出这种事。

这个例子并非随手挑的。在“Even better if you have”一栏，HackerRank 优先考虑在 HR 科技、ATS 平台、IDE 或开发者工具领域做过软件、解决方案或售前工程师的人。这是加分项，不是硬性要求，但集成过 HR 软件的人一眼就能认出这个场景。

**要点:** 在产品成熟的公司，招 FDE 是为了让产品在客户那里用起来，而不是重写它。

## 讲解时，谁在场？

伦敦和班加罗尔的招聘启事都写明，FDE 要在现场与客户、工程师、招聘人员和业务负责人一起工作。因此听众是混合的：在上面的 webhook 案例里，你要给客户的集成工程师一种讲法，给招聘负责人另一种讲法。

列出的职责本身也围绕面向客户展开。FDE 主导客户合作，包括需求调研、试点和演示；伦敦的招聘启事一字不差地重复了这段表述，说明各地对这个岗位的描述是一致的。

其余部分靠执行纪律。HackerRank 希望看到你有把项目从范围界定带到交付的记录，并要求 FDE 通过主动同步进展，确保客户项目不偏航。如果你只有在拿到清晰需求文档时才觉得踏实，就要把这当作需要认真考虑的信号。

## 把客户的声音带回来

有一项职责容易被一眼带过：FDE 要与 Product、Engineering 和 GTM 合作，让客户的声音更有分量。你在客户那边看到的情况，必须变成公司的输入，而不是止于一张关闭的工单。

回到 webhook 的例子。好的 FDE 不会只为一个客户修好它。他们会意识到，静默的认证失败在下一个客户那里还会重演，于是向产品团队提议增加一个管理员可见的告警。面试时，这类故事能说明你像产品构建者一样思考，而不只是救火队员。

HackerRank 也在招聘一位 Director, Forward Deployed Engineering，这个人要能与工程师讨论架构，并与销售、产品和客户方负责人对齐结果。到了这个级别，面向技术和非技术听众都能讲好，被单独写成了一项要求。

Director 岗位的加分项提到了做过 FDE、Solutions Engineer 或 Technical Consultant 的经历，以及开发者工具、HR 科技或以 API 为核心的 SaaS 背景。这和 FDE 招聘启事偏好的背景很接近，所以你今天练出的沟通能力，会随着岗位成长继续保值。

## 像读考题一样读招聘启事

把招聘启事的各行拼在一起，就是一份相当详细的任务说明。下表把每条要求转换成客户那边的实际工作，以及在简历上证明它的方式。

| 招聘启事中的条目 | 客户那边的实际工作 | 如何在简历上证明 |
|---|---|---|
| 主导需求调研、试点、演示 | 问对问题，弄清客户需要什么；在小范围内试用；展示结果 | 一个你从第一次会议带到客户正式使用的项目 |
| 配置、调试和讲清 Web 应用；用 Ruby 或 Python 编写 API 脚本 | 与客户现有系统集成，在你无法掌控的环境里找 bug | 一个你发现的具体集成 bug，以及你为修复它写的脚本或配置 |
| 与工程师、招聘人员、业务负责人现场协作 | 同一个故障，对不同听众用不同方式讲 | 一份面向非技术听众的文档或演示 |
| 从范围界定到交付，主动同步进展 | 客户改需求时，仍让进度保持正轨 | 一个里程碑清晰、由你负责汇报进展的项目 |
| 把客户声音带给 Product、Engineering、GTM | 把一个客户的问题变成面向整个产品的提案 | 一个源自你带回的反馈的功能或修复 |

最后一列最重要。罗列框架的简历会淹没在众多简历里；而能证明你曾站在技术故障和焦虑的客户之间的简历，恰好契合这则招聘启事要找的人。

## 怎样投好这份简历

如果你是软件工程师，别抹掉过去的经历，把自己包装成销售。用这三个动词重讲你的项目：上一次你帮别的团队用上你的 API 时，你配置了什么，调试了什么，又向谁讲清了它？

如果你是解决方案工程师或售前工程师，这则招聘启事说明你的背景是算数的。你需要补的是技术证据：某次你亲自看日志、写脚本或修配置，而不是把工单转给工程团队。

这则招聘启事不问你从零构建过什么。它问的是：你有没有让别人构建的东西在客户手里跑起来，能不能把它讲到对方听懂。

**本周动手试试:**

- 随便打开三则 FDE 招聘启事，每则拆成两栏：岗位职责和优先背景，再标出你已有证据的条目
- 按这个模板改写一条简历：客户遇到了什么问题，你如何调试，你向谁讲清了结果
- 把你修过的一个集成 bug 练习讲两遍：一版讲给工程师，一版讲给非技术听众

## 信源

- [Forward Deployed Engineer - HackerRank | Built In](https://builtin.com/job/forward-deployed-engineer/8112251)

- [Forward Deployed Engineer - HackerRank | Built In](https://builtin.com/job/forward-deployed-engineer/9652020)

- [Forward Deployed Engineer (HackerRank, London) | Built In London](https://builtinlondon.uk/job/forward-deployed-engineer/9368242)

- [Director, Forward Deployed Engineering - HackerRank (PitchMeAI)](https://pitchmeai.com/companies/hackerrank-careers/jobs/director-forward-deployed-engineering-hybrid-in-santa-clara-ca-66052)