工程师面试开始考你怎样怀疑 AI 写的代码

Tristan Hume 在 Anthropic 的工程博客上写道，每出一个新的 Claude 模型，公司就不得不重新设计一次工程师招聘测试。

原因是模型的表现已经和最强的候选人不相上下。即便如此，Anthropic 并没有禁止使用 AI。性能工程方向的居家测试题明确写着：候选人可以使用 AI 工具，就像在实际工作中一样。

这并非某一家实验室的做法。Meta 和 Google 也有允许使用 AI 的编程面试轮次。据一份面试指南介绍，OpenAI 的部分前线部署工程师（FDE）面试轮次同样如此。在这些轮次中，评分重心正从写代码的能力转向评判代码的能力。

来自 Anthropic 和 Meta 的证据针对的是整体工程师招聘，并不专指 FDE。但对于正在做或想做 FDE 的人来说，这一点更加重要，因为他们的工作就是把代码放进客户的真实系统，在真实数据上运行。

在那里，一段看似正确实则有错的 Agent 代码会带来真实的后果，而不只是面试丢一分。

机器能写代码了，还剩什么可考？

techinterview.org 上的一篇分析解释了公司为什么要改变评分方式：面试官把门槛移到了模型无法替你完成的那件事上，即判断它的输出到底好不好。

LeadDev 发表的一篇文章中，一位 Meta 的演讲者把公司的新面试称为“AI 原生”编程轮次，考查的是适应能力而不是记忆。按这位演讲者的说法，被测试的技能已经从熟悉框架转向发现 AI 的幻觉。

因此，懂得多已不再是最大的优势。优势在于：即使眼前的东西看起来很有说服力，你也能察觉它是错的。

被考查的行为比你想的简单

据 techinterview.org 介绍，Meta 把这种行为称为“批判性验证”（critical verification）。观察方法很简单：你会不会在运行 AI 生成的代码之前先读一遍？

谈到 Meta 和 Google 允许使用 AI 的编程轮次时，该网站认为验证占了大部分分数。你把 AI 的建议粘进编辑器的那一刻，面试官就在看你接下来做什么。

文章这样描述优秀的候选人：他们把 AI 当作一个手脚快、很自信但偶尔出错的实习生。在面试中发现它的错误，算作一个好信号。这些轮次要找的高级别信号是：恰恰在答案看起来没问题时，候选人变得更加警惕。

各家公司的描述不同，但把这些面试轮次放在一起看，它们是从不同角度考查同一项技能：

面试轮次	是否允许 AI？	考查什么	面试官观察什么
Anthropic 性能工程居家测试	允许，题目说明中写明，与实际工作一致	除了提交的代码，还看你如何决定在工具上投入什么	你在哪些工具上花力气，以及为什么
Meta 的“AI 原生”编程轮次（据 LeadDev），以及 Meta 和 Google 允许 AI 的轮次（据 techinterview.org）	允许	适应能力、发现幻觉；验证占大部分分数	是否先读代码再运行，粘贴建议后做了什么，是否会怀疑看起来很整齐的答案
OpenAI 的 FDE 面试轮次（据 Aced 指南）	部分轮次允许，包括使用 Codex	对借助 AI 写出的代码进行推理和验证	共享屏幕、边想边说、解释时间和内存开销

OpenAI 的 FDE 面试要听你说清开销

Aced（原名 Exponent）上一份关于 OpenAI FDE 面试的指南提到，部分编程轮次允许使用 AI。考查的是你能否对借助 AI 写出的代码进行推理和验证。

在使用 Codex 的筛选轮次中，候选人要共享屏幕、边想边说，并解释工具所写每段代码的时间和内存开销。

要理解这在实践中意味着什么，不妨设想一道练习。一家物流客户交给你一份 200 万行的订单文件，要求按邮箱合并重复的客户记录。Agent 立刻写出一个函数，用两层嵌套 for 循环两两比较。你在 10 行样例数据上运行，结果完全正确。

只会按运行键的候选人到这里就停了。有判断力的候选人会读代码，并指出两个问题。

第一，在 200 万行数据上两两比较，大约需要两万亿次比较。复杂度是 O(n²)，这个函数无法在可接受的时间内跑完。

第二，邮箱比较区分大小写，于是“[email protected]”和“[email protected]”被当成两个不同的客户。

修复并不难。先对每个邮箱做规范化处理，去掉空白并转成小写，再用哈希表对记录分组。时间降到 O(n)，代价是 O(n) 的内存，因为每个键都得保存在内存里。

这正是指南中所说的“解释开销”。这个假设的例子还说明了另一点：10 行样例数据通常是干净的，客户数据却很少如此，所以样例上测试通过什么也证明不了。

Anthropic 也考你怎样选择工具

据 Hume 的文章，Anthropic 把候选人如何决定在工具上投入，视为招聘信号的一部分。在让 Agent 做优化之前，你会停下来写一个基准测试脚本或一小套测试吗？还是任由它盲目修改，寄希望于结果变好？

FDE 在客户现场的第一周面对的正是这个问题。时间有限，你必须在两者之间做选择：现在手动把活干完，还是做一个工具，让接下来一个月的验证更快。从这个角度看，Anthropic 的居家测试比一道 LeetCode 题更接近真实工作。

测试必须随每个新模型而改变，这本身也是一个提示：机器能完成的技能，很可能会从考查清单上消失。投资于分辨对错的能力，比再背一个框架更稳妥。

下次面试前怎样练习

最有效的练习，就是演练面试官观察的那些行为。

每次 Agent 生成代码，在信任它之前走完五个步骤：运行前逐行阅读；大声说出代码要做什么；主动寻找能让它出错的输入；说明时间和内存开销；最后依据测试或测量结果，决定保留、修改还是丢弃。

完成前四步之前，不要按运行。第五步则是向面试官展示你的决定依据什么。

阅读 FDE 岗位描述或面试准备材料时，留意这样的措辞：AI-enabled coding round、允许使用 Copilot 或 Codex、共享屏幕并解释你的思路。它们表明这家公司会考查判断力，这时你应该多花时间练习边说边写代码，而不是一味刷题。

在简历上，“使用 AI 提升效率”这句话几乎没有向招聘方传达任何信息。更有价值的写法是描述一次具体经历：Agent 生成了什么代码，你在它进入生产环境前发现了什么 bug，用了哪项测试或测量来验证。

新的面试轮次既不找信任 AI 的人，也不找排斥 AI 的人。它们要的是懂得在 Agent 的代码看起来最完美时去怀疑它的人。在客户现场，这也正是你最有价值的时候。