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

> Anthropic、Meta 以及 OpenAI 的部分 FDE 面试轮次，已经允许候选人在招聘测试中使用 AI。如今，相当一部分分数取决于你把机器给出的代码粘进编辑器之后做了什么。

原文: https://fdetimes.net/zh/analysis/ai-interviews-grade-verifying-ai-code/

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²)，这个函数无法在可接受的时间内跑完。

第二，邮箱比较区分大小写，于是“An@x.com”和“an@x.com”被当成两个不同的客户。

修复并不难。先对每个邮箱做规范化处理，去掉空白并转成小写，再用哈希表对记录分组。时间降到 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 的代码看起来最完美时去怀疑它的人。在客户现场，这也正是你最有价值的时候。

**本周动手试试:**

- 用 Agent 解一道编程题并录屏。之后回看：你是否在按下运行前读过代码，是否说明了时间和内存开销。
- 让 Agent 写一个处理客户数据的函数。在运行测试之前，自己至少找出一个边界情况 bug 和一个复杂度问题。
- 改写简历中的一条要点，写清 Agent 生成了什么代码、你发现了什么 bug，以及你如何验证。

## 信源

- [Designing AI-resistant technical evaluations (Anthropic Engineering, Tristan Hume)](https://www.anthropic.com/engineering/AI-resistant-technical-evaluations)

- [AI killed the coding interviews. Here's what Meta built instead (LeadDev)](https://leaddev.com/hiring/ai-killed-the-coding-interviews-heres-what-meta-built-instead)

- [What interviewers grade when they hand you Copilot (techinterview.org)](https://www.techinterview.org/post/3233476832/what-interviewers-grade-when-you-can-use-copilot/)

- [What Meta and Google's AI-enabled coding rounds actually test (techinterview.org)](https://www.techinterview.org/post/3233477234/meta-google-ai-enabled-coding-interview/)

- [OpenAI Forward Deployed Engineer (FDE) Interview Guide | Sample Questions (2026) - Aced (formerly Exponent)](https://www.aced.io/guides/openai-forward-deployed-engineer-interview)