Scale AI 的 FDE 面试：两轮 HackerRank、一个出了 bug 的代码库，以及真正考查的能力

打开 HackerRank 链接，60 分钟倒计时开始，题目不是翻转二叉树，而是一个必须能跑起来的小项目。根据 Aced（原名 Exponent）的一份指南，Scale AI 前线部署工程师（FDE）岗位的在线测评就是这个样子：只有一道项目式编码题，难度被描述为“难”。

这只是进入现场面试前要通过的两轮 HackerRank 之一。Final Round AI 认为测评时长是 50 分钟，并指出并非所有候选人都按同样的顺序走流程，所以关于时长和顺序的描述都只能当作参考。

仔细读各轮面试的描述，会发现它们与 FDE 每周的工作一一对应：接手别人写的系统，让它跑起来，再向别人解释它为什么坏了。为这些任务做准备，也就是在练习这份工作本身。

每一轮都在模拟客户现场的一天

据 techinterview.org 介绍，虚拟现场面试有四到五轮：两轮编码、一轮系统设计、一轮调试和一轮行为面试。调试轮会给你一个从没见过的代码库，外加一个失败的测试或一段症状描述，你有大约 45 分钟找到并修复问题。

据 Aced 介绍，招聘经理（hiring manager）这一轮是行为面试，内容与 credo（价值观）轮相近。techinterview.org 称，这轮谈话主要围绕 Scale 的价值观展开：担当（ownership），以及在周围一切不断变化时依然快速推进。

从招聘启事就能看出这些面试轮次为什么贴合工作。Scale 的 GenAI FDE 招聘启事要求快速实验、持续迭代以满足客户需求，并且能向技术和非技术人员解释复杂的技术概念。

没有沟通轮，因为每一轮都是沟通轮

Aced 明确表示，沟通能力在整个流程中都会考查，没有专门的一轮。Aced 的另一个页面建议候选人在技术轮中讲清自己的思路和决策。techinterview.org 说得更直白：一声不吭地调试，看起来就像在瞎猜。

由此可以推出：一个默默修好三个 bug 的候选人，给人的印象可能不如修好两个、但清楚说明第三个 bug 在哪、打算怎么处理的候选人。后者展示的，正是客户在系统出故障时最想看到的东西。

设想面对陌生代码库的 45 分钟

假设调试题是一个计算标注员之间一致率的脚本，这类工作与标注数据关系非常紧密。下面的代码片段是虚构的练习示例，不是真实面试题：

def agreement_rate(rows, labels_by_task={}):
    for r in rows:
        labels_by_task.setdefault(r["task_id"], []).append(r["label"])
    agreed = 0
    for task_id, labels in labels_by_task.items():
        if len(set(labels)) == 1:
            agreed += 1
    return agreed / len(rows)

不要逐行阅读去找 bug，而是先构造一个三行的输入：任务 A 有两个“cat”标签，任务 B 有一个“dog”标签。函数返回 2/3，约 0.667。如果约定只统计至少有两名标注员的任务，正确答案是 1/1；如果所有任务都算，正确答案是 2/2。无论怎么理解需求，都得不出 0.667。

这个错误的数字直接指向三个 bug。分母统计的是行数而不是任务数；只有一个标签的任务被算作一致。最危险的是，labels_by_task={} 是可变默认参数：用不同数据第二次调用这个函数时，上一次调用的标签还留在字典里，结果就被带偏了。

修复顺序本身也是答案的一部分。可变默认参数会在多次运行之间悄悄污染数据，所以排第一。分母排第二。单标签的情况其实是个业务问题，应该向面试官询问约定，而不是自己猜。

做题时按稳定的节奏把思路说出来：用一个小输入复现，期望 1.0 却得到 0.667，怀疑是分母的问题，修复，再跑一遍。

如果时间用完时还有 bug 没修，就说明它在哪里、你会加哪个测试来捕获它。这样，“没做完”就变成了有担当的证据。

LLM 在基础设施中处于什么位置？

Scale 的 GenAI FDE 招聘启事要求为客户快速实验，并向非技术人员清楚解释。所以自己练习系统设计时，可以出一些涉及 LLM 的题目，并练习向这两类听众讲解设计。

常见的陷阱是在中间画一个写着“LLM”的方框就停下。Sundeep Teki 的 FDE 面试指南认为，最常见的错误是一个澄清问题都不问就直接给出方案。

以这道题为例：客户想用 LLM 给工单分类。动笔之前，先问清楚工单是批量到达还是流式到达、标错一个标签的代价有多大、输出给谁用。这三点明确后再开始画。

工单进入队列，worker 调用模型时带重试和超时，低置信度的结果转给人工审核。每次修改 prompt 或更换模型，都要跑一遍带标准标签的小型评测集，这也呼应了招聘启事里提到的快速迭代。

还要说明模型 API 宕机时的兜底方案，因为这正是直接与客户打交道的 FDE 会遇到的事故。

用几周时间怎么练

Final Round AI 观察到，HackerRank 测评并不奖励慢工出细活的答题者。所以把一半刷 LeetCode 的时间换成限时 60 分钟的项目式练习：读取 CSV 文件，调用模拟 API，写出结果，并附上测试。

在陌生的代码仓库上练调试，每次计时，并把自己讲解的过程录下来。回放时立刻就能听出哪里沉默太久了。

针对行为面试和招聘经理轮，准备两类故事：一次你主动承担了工作中最难的部分，一次你在需求不断变化时必须快速推进。每个故事都要有具体的决策和可衡量的结果。还要准备好“为什么想做 FDE”的清晰回答。

简历也要用同样的语言。像“接手另一个团队的数据管道，找到并修复了导致报表数据错误的 bug，并向客户解释了根本原因”这样的一句话，比任何框架列表都更贴合招聘启事。无论在哪里读 FDE 的岗位描述，都留意一下“强编码能力”和“沟通能力”是否并列出现。

让强候选人栽跟头的陷阱

一个容易踩的坑，是在调试轮试图修完所有 bug，结果做到一半时间耗尽，什么也没解释。另一个是回答系统设计时默认 LLM 永远正确、永远在线，漏掉评测和兜底方案。讲行为故事时只说“团队做了什么”，不讲清自己负责的部分，也会让回答打折扣。

最隐蔽的陷阱，是把招聘经理这一轮当成走过场。

说到底，Scale AI 的 FDE 面试就是客户现场一周的缩影。准备时要像准备那一周，而不是准备进考场。