LLM 工程师招聘：面试究竟该测试什么

大多数招聘 LLM 岗位的工程团队进行的面试大同小异：两轮 LeetCode，一个系统设计问题，可能还有一个关于 Transformer 内部机制的小测验。他们考核的重点不对 —— 而且他们自己也知道。那些在这些筛选中表现优异的候选人往往难以交付实际可用的 AI 功能，而那些在二叉搜索上栽跟头的候选人却能从零开始构建一个评估套件，并在一个下午内调试好一个产生幻觉的流水线。

能预示在 LLM 工程领域取得成功的技能，与传统机器学习或软件面试所测试的内容几乎没有交集。尚未更新招聘流程的招聘经理正在产生大量的漏选（false negatives）—— 拒绝了本可以成功的工程师 —— 而误选者（false positives）则带着扎实的 LeetCode 分数步入公司，却对模型何时在自信地胡说八道毫无直觉。

为什么标准筛选在此失效

传统机器学习面试优化的是数学记忆和算法编码。你能从零开始推导注意力机制吗？你知道什么时候该用精确率（precision）还是召回率（recall）吗？你能用 15 分钟实现二叉树遍历吗？

这些技能对构建模型的研发人员很重要。对于部署模型的工程师来说，它们几乎无关紧要。

LLM 工程主要是一门关于选择、评估和集成的学科。你不是在训练模型；你是在配置模型，测量它的失效模式，并决定这些失效在给定成本下的生产环境中是否可以接受。核心竞争力是不确定性下的判断力 —— 具体而言，就是对概率性输出进行推理、为模糊的规范设计测试，以及在不需要穷举的情况下，培养出模型会在哪里崩溃的直觉。

一个能详细解释多头注意力的候选人，如果从未写过评估框架（eval harness），从未调试过在边缘情况下退化的提示词，且对成本估算毫无直觉，那么他还没准备好胜任这项工作。然而，这样的候选人却能轻松通过大多数招聘门槛。

真正能预示成功的三个技能

剥离掉资历杂音后，有三种能力可以将交付实际 AI 产品的工程师与那些不断做原型却从未达到生产信心标准的工程师区分开来。

评估设计直觉。 候选人能否将模糊的业务语言规范 —— “模型应该准确地总结支持票据” —— 转化为具体、可衡量的评估套件？这需要理解“准确”在操作层面意味着什么，知道要覆盖哪些失效模式（幻觉出的解决方案、错误的票据类别、不完整的提取），并决定在拥有数千个带标签的数据对之前，多少个样本足以获取信号。缺乏这种直觉的工程师交付的 AI 功能从未经过任何系统性标准的测试。他们靠的是“感觉”（vibes）。

失效模式直觉。 LLM 的失效方式在结构上与确定性软件不同。它们会表现得“自信地错误”。它们在你测试过的案例中表现良好，但在相邻的案例中表现糟糕。它们会在输入分布发生变化时，以不明显的方式退化。一名优秀的 LLM 工程师已经建立了一套关于这些失效模式的心理图谱 —— 提示词注入、上下文窗口边界效应、多步任务中的指令遵循崩坏、对接近知识截止期查询的过度自信 —— 并且会在没有人告知的情况下主动去探测这些问题。这种直觉来自于构建过在生产中失败过的系统，而不是从论文中读到过失效模式。

提示词调试技能。 给定一个提示词和一组未达质量标准的输出，候选人能否诊断出原因并提出针对性的修复方案？这听起来比实际操作要难。糟糕的调试看起来像是随机扰动 —— 修改词语、增加指令，期待能有所改善。好的调试看起来像是假设根本原因，设计一个最小化测试来确认它，并进行精准的修改。当你观察某人工作时，这种差异是立竿见影的。

面试真正应该测试什么

最具启发性的面试形式是围绕三个练习展开的 90 分钟实践环节。没有问答题。没有理论背诵。只有作为实际工作代理的任务。

练习 1：从模糊规范构建小型评估。 给候选人一个关于功能的两句话描述 —— 例如，“一个将客户反馈分类为错误报告、功能需求或一般问题的 LLM” —— 以及一打未标记的示例。要求他们设计一个评估方案：他们会创建哪些案例，如何衡量成功，在信任该指标之前需要多少个示例，以及如何处理不属于这三个类别的边缘情况。这里没有标准答案。你要考察的是他们是否提出澄清性的问题，是否不对称地考虑误选和漏选的成本（将错误报告误分类为功能需求可能与反过来的情况大不相同），以及他们是否理解测试集中覆盖率（coverage）和精确率（precision）的区别。

练习 2：调试产生幻觉的提示词。 提供一个提示词、一份上下文文档和五个输出样本 —— 其中一些是正确的，一些是幻觉。要求他们识别哪些输出是有问题的，假设原因，并提出提示词修改建议。观察他们的推理方式。在形成观点之前，他们是否仔细阅读了源文档？他们是否注意到模型引用了上下文中不存在的信息？他们是提出具体的、可测试的更改，还是因为不习惯针对性诊断而重写整个提示词？调试过程比最终答案更能说明问题。

练习 3：估算所述流水线的成本。 勾勒一个功能：“每天有 50,000 封客户支持电子邮件，我们希望使用 LLM 提取根本原因、分配优先级并建议响应模板。”要求他们估算每日的 Token 成本，识别最大的成本驱动因素，并提出两项优化方案。这测试了他们是否已将“生产环境中的 AI 是一个经济学问题，而不仅仅是准确性问题”这一观念内化。优秀的候选人会立即开始推理输入长度、缓存机会、模型分级选择（是否所有 50,000 封邮件都需要最强大的模型？），以及先运行更便宜的分类、仅对模糊案例进行升级的选项。缺乏这种直觉的候选人构建出的架构在技术上是正确的，但在经济上是无法交付的。

标准面试无法察觉的红线

除非你在设计面试时专门挖掘，否则有些失败模式在某人正式加入团队之前是不可见的。

视模型为魔法。 仅通过便利封装（convenience wrappers）使用过 LLM 的工程师，通常对 prompt 失败时的底层逻辑缺乏认知模型。他们期望模型在处理新输入时能“直接奏效”。当模型失效时，他们的调试策略是不断尝试不同的措辞，直到撞大运成功。这产生的 prompt 极其脆弱，且没人明白其背后的逻辑。

缺乏评估基础设施（Eval infrastructure）经验。 直接提问：描述你构建的上一个 eval 测试框架（eval harness）。你测量了什么？你是如何处理主观性的？什么让你感到意外？在生产环境中交付过 AI 功能的工程师在这里总会有故事。这些故事通常关于“犯错”——比如发现他们信任的某个指标与用户真正关心的东西并不相关，或者总准确率掩盖了特定输入模式下的灾难性失败。讲不出这些故事的候选人，说明他们没有交付过产品。

混淆机器学习（ML）数学造诣与 LLM 工程能力。 花了三年时间微调 BERT 分类器的候选人拥有可迁移的技能，但这些技能并不等同。LLM 工程的工作单元是 prompt、eval 和部署配置——而不是训练运行（training run）。一些强大的传统 ML 工程师能快速完成转型；而另一些人则会发现这种概率性的、由规范驱动（specification-driven）的工作性质令人无所适从。面试应探测候选人是否真的以此模式操作过，而不仅仅是学习过。

过度迷信基准测试（Benchmarks）。 将基准测试分数作为模型选择主要依据的候选人，释放了一个信号：他们还没遇到过生产环境下的分布偏移（distribution shift）。基准测试测量的是在精选数据集上的表现，这些数据可能无法代表你的实际输入。优秀的候选人会将基准测试结果视为先验指标，然后描述在正式投入使用前，他们会如何在自己的数据上进行验证。

你真正应该招聘的是什么

一个有用的思维转变是：你不是在招聘一个人去理解 LLM；你是在招聘一个人，利用 LLM 构建出可靠的产品，尽管 LLM 本身并不可靠。这种定位改变了哪些信号更重要。

作品集证据胜过证书。 在这个领域没有真正有意义的认证。看看候选人实际构建了什么。请他们带你回顾一个首选方案失败的项目。失败分析的质量比对成功结果的描述更能告诉你真实水平。

有主见的模型选择反映了真实经验。 资深的 LLM 工程师对于何时使用更小、更便宜的模型，以及何时不能使用，都有自己的见解。他们对哪些模型系列在哪些方面会失败总结出了启发式方法。对于托管 API 与自托管模型之间的权衡，他们有自己的看法，而不是照搬博客文章。如果候选人回答“这取决于具体用例”，却无法具体说明取决于什么以及为什么，这表明他们在真实约束下做出的决策还不够多。

数据素养被低估了。 资深 LLM 工程的大部分工作是检查示例、发现分布模式，并诊断模型为何在一类输入上表现不同。这需要对数据保持细致的关注——能够发现标注示例中的不一致，注意到 eval 集合何时存在结构性偏差，并在指标看起来过于完美时保持恰当的怀疑。那些跳过这一步直接先去修改模型的工程师，会不断地解决错误的问题。

调整针对真正稀缺能力的门槛

关于人才校准的一个务实提醒：LLM 工程的候选人池中充斥着看过教程、运行过 notebook，但从未在生产环境中经历过系统失效、诊断并修复的人。“我有 LLM 经验”的门槛太低，已失去参考价值。

上述实操练习会刷掉那些只会刷教程的人。这正是目的所在。你希望面试在核心环节上保持高难度——不是为了刁难，而是因为这些练习是实际工作的缩影。一个能从模糊的规范中设计出有意义的 eval、能系统地调试幻觉 prompt，并能从管线经济效益（pipeline economics）角度思考的工程师，才为这份工作做好了准备。而一个能解释反向传播（backpropagation）但从未编写过 eval harness 的工程师，则不行。

采用这种筛选机制可能意味着面试更多候选人却发出更少的 offer。这没关系。在 LLM 工程领域，一个能交付可用系统的工程师，顶得上好几个只能流利做原型的人。针对真正困难的事情来优化你的招聘标准。

---

这里描述的三个练习对中级和资深职位的招聘都有效。对于资深职位，可以增加第四个：给他们一个失效的系统（真实的或构造的），请他们提出调试计划并确定优先级。资深程度体现在他们如何分诊和处理问题（triage），而不仅仅在于他们知道多少。