作者 Tristan Hume，Anthropic 性能优化团队负责人之一。Tristan 设计并重新设计了这项带回家测试，它帮助 Anthropic 招聘了数十名性能工程师。

随着 AI 能力的提升，评估技术候选人变得更加困难。如今能够很好地区分人类技能水平的带回家测试，明天可能就会被模型轻松解决，从而使其失去评估价值。

自 2024 年初以来，我们的性能工程团队一直使用一项带回家测试，让候选人为一个模拟加速器优化代码。已有 1,000 多名候选人完成了这项测试，其中数十人现在在这里工作，包括启动了我们的 Trainium 集群并交付了自 Claude 3 Opus 以来每一个模型的工程师。

但每一个新的 Claude 模型都迫使我们重新设计这项测试。在给予相同时间限制的情况下，Claude Opus 4 的表现超过了大多数人类申请者。这仍然让我们能够区分出最强的候选人——但随后 Claude Opus 4.5 甚至达到了这些候选人的水平。在给予无限时间时，人类仍然可以超过模型，但在带回家测试的约束下，我们已经无法再区分顶尖候选人的产出和我们能力最强模型的产出。

我现在已经迭代了三个版本的带回家测试，试图确保它仍然具有信号价值。每一次，我都对什么能让评估在 AI 辅助下保持稳健、什么不能，有了新的认识。

本文介绍了最初的带回家设计题、每个 Claude 模型是如何攻克它的，以及为了确保我们的测试始终领先于我们顶尖模型的能力，我不得不采取的越来越不同寻常的方法。虽然我们的工作随着模型一起演进，但我们仍然需要更多优秀工程师——只是需要越来越有创意的方式来找到他们。

为此，我们将最初的带回家设计题作为公开挑战发布，因为在时间不受限制的情况下，最佳人类表现仍然超过 Claude 所能达到的水平。如果你能胜过 Opus 4.5，我们很愿意听到你的消息——详情见本文末尾。

带回家设计题的起源

2023 年 11 月，我们正准备训练并发布 Claude Opus 3。我们已经获得了新的 TPU 和 GPU 集群，庞大的 Trainium 集群也即将到位，而且我们在加速器上的投入比过去大得多，但面对新的规模，我们没有足够的性能工程师。我在 Twitter 上发帖请人们给我们发邮件，这带来了比我们通过标准面试流程所能评估的更多有潜力的候选人；而标准面试流程会耗费员工和候选人大量时间。

我们需要一种更高效地评估候选人的方式。因此，我花了两周时间设计了一项居家测试，能够充分体现该职位的要求，并识别出能力最强的申请者。

设计目标

居家测试的口碑并不好。通常它们充斥着一些通用题目，工程师会觉得无聊，而且筛选效果也不佳。我的目标不同：创造一些真正有吸引力的内容，让候选人愿意参与，并使我们能够以高分辨率捕捉他们的技术能力。

这种形式在评估性能工程技能方面也比现场面试更具优势：

更长的时间范围：工程师在编码时很少会面临不到一小时的截止期限。4 小时的时间窗口（后来缩短为 2 小时）更能反映这项工作的实际性质。它仍然比大多数真实任务更短，但我们需要在这一点与其繁重程度之间取得平衡。

真实的环境：没有人在旁观看或期待候选人口述过程。候选人在自己的编辑器中工作，不受干扰。

用于理解和工具构建的时间：性能优化需要理解现有系统，有时还需要构建调试工具。这两者都很难在常规的 50 分钟面试中进行真实评估。

与 AI 辅助的兼容性：Anthropic 的一般候选人指南要求候选人在未另行说明的情况下完成带回家任务时不得使用 AI。对于这项带回家任务，我们明确另行说明。

长期问题对 AI 来说更难完全解决，因此候选人可以使用 AI 工具（就像他们在工作中会使用的一样），同时仍需要展示自己的技能。

除了这些特定形式的目标之外，我还应用了我在设计任何面试时都会使用的相同原则来设计这项带回家完成的任务：

代表真实工作：这个问题应让候选人体验这份工作实际涉及的内容。

高信号：带回家完成的任务应避免依赖单一洞见的问题，并确保候选人有许多机会展示自己的全部能力——尽可能减少偶然因素。它还应具有宽泛的评分分布，并确保有足够深度，使即使是优秀候选人也无法完成所有内容。

无需特定领域知识：基础扎实的人可以在工作中学习具体内容。要求狭窄的专业知识会不必要地限制候选人范围。

有趣：快速的开发迭代、有深度的有趣问题，以及发挥创造力的空间。

模拟机器

我为一款虚构加速器构建了一个 Python 模拟器，其特性类似于 TPU。候选人需要优化在这台机器上运行的代码，使用可热重载的 Perfetto trace 来查看每一条指令，这与我们在 Trainium 上使用的工具类似。

该机器包含一些使加速器优化变得有趣的特性：手动管理的暂存存储器（与 CPU 不同，加速器通常需要显式内存管理）、VLIW（每个周期有多个执行单元并行运行，需要高效的指令打包）、SIMD（每条指令对多个元素执行向量运算）以及多核（将工作分配到多个核心）。

这项任务是并行树遍历，刻意不带深度学习色彩，因为当时大多数性能工程师还没有从事过深度学习工作，可以在入职后学习领域相关细节。这个问题的灵感来自无分支 SIMD 决策树推理，这是一项经典的机器学习优化挑战，也是对过去的致意，之前只有少数候选人遇到过。

候选人从一个完全串行的实现开始，并逐步利用该机器的并行能力。热身环节是多核并行，然后候选人选择是处理 SIMD 向量化，还是处理 VLIW 指令打包。最初版本还包含一个错误，候选人需要先调试该错误，以考察他们构建工具的能力。

早期结果

最初的带回家测试效果很好。来自 Twitter 批次的一名候选人得分大幅高于其他所有人。他在 2 月初入职，比我们通过标准流程招聘的第一批员工晚了两周。这项测试证明具有预测性：他立即开始优化内核，并为一个阻碍发布的编译器 bug 找到了变通方案，该 bug 涉及张量索引计算溢出 32 位。

在接下来的一年半里，大约 1,000 名候选人完成了这项带回家测试，它帮助我们招聘了当前性能工程团队的大部分成员。事实证明，它对履历上经验有限的候选人尤其有价值：我们几位表现最出色的工程师都是本科毕业后直接加入的，但他们在带回家测试中展现出了足够的能力，让我们能够有信心地录用他们。

反馈是积极的。许多候选人因为乐在其中而超过了 4 小时的限制。最强的不限时提交包括完整的优化型迷你编译器，以及几种我此前没有预料到的巧妙优化。

然后 Claude Opus 4 击败了它

到 2025 年 5 月，Claude 3.7 Sonnet 已经逐渐发展到这样一个程度：超过 50% 的候选人如果完全委托 Claude Code 来完成，结果会更好。随后，我用一款预发布版本的 Claude Opus 4 测试了这道带回家完成的题目。它在 4 小时限制内给出的解法，比几乎所有人类的解法都更优化。

这并不是我的面试题第一次被 Claude 模型攻克。2023 年，我曾设计过一道现场面试题，专门是因为我们当时的问题基于一些常见任务，而早期 Claude 模型对这些任务掌握了大量知识，因此可以轻松解决。我试图设计一道相比知识更需要问题解决能力的题目，但它仍然基于我在工作中解决过的一个真实（但小众）问题。Claude 3 Opus 攻克了那道题的第 1 部分；Claude 3.5 Sonnet 攻克了第 2 部分。我们仍在使用它，因为我们的其他现场面试题也并不抗 AI。

对于带回家完成的题目，有一个直接的修正办法。这个问题的深度远远超过任何人在 4 小时内所能探索的范围，因此我用 Claude Opus 4 来确定它从哪里开始遇到困难。那就成了第 2 版的新起点。我编写了更整洁的起始代码，增加了新的机器特性以提供更深的探索空间，并移除了多核部分（Claude 已经解决了这一点，而且它只会拖慢开发循环，却不会增加有效信号）。

我还把时间限制从 4 小时缩短到了 2 小时。我最初选择 4 小时，是基于候选人的反馈：他们更希望降低因一时卡在 bug 或理解困惑上而彻底受挫的风险，但排期上的开销正在导致我们的流程出现数周的延迟。2 小时更容易安排在一个周末里。

第 2 版更强调巧妙的优化洞察，而不是调试和代码量。它很好地服务了我们——持续了几个月。

然后 Claude Opus 4.5 攻克了它。

当我测试一个预发布的 Claude Opus 4.5 checkpoint 时，我看着 Claude Code 在这个问题上工作了 2 小时，并逐步改进其解决方案。它解决了最初的瓶颈，实现了所有常见的微优化，并在不到一小时内达到了我们的通过阈值。

然后它停了下来，确信自己遇到了无法逾越的内存带宽瓶颈。大多数人也会得出同样的结论。但有一些巧妙技巧可以利用问题结构来绕过这个瓶颈。当我告诉 Claude 可以达到的周期数时，它思考了一会儿并找到了这个技巧。随后它继续调试、调优并实现了进一步优化。到 2 小时时，它的分数已经达到该时间限制内最佳人类表现的水平——而那个人类还大量使用了经过引导的 Claude 4。

为了更严谨，我们在内部测试时计算框架中试用了它，并确认它既能在 2 小时内击败人类，也能随着时间继续提升。发布后，我们甚至以一种通用方式改进了我们的框架，并取得了更高的分数。

我遇到了一个问题。我们即将发布一个模型，而在我们的带回家测试中，最佳策略会是委托给 Claude Code。

考虑各种选项

一些同事建议禁止使用 AI 辅助。我不想这么做。除了执行上的挑战之外，我还隐约觉得，既然人们在我们的工作中仍然发挥着至关重要的作用，我应该能想出某种方式，让他们在有 AI 的环境中脱颖而出——就像他们在工作中那样。我还不想接受这样一种观点：人类只在耗时超过几个小时的任务上才有优势。

另一些人建议把标准提高到“显著超过 Claude Code 单独完成时的表现”。这里的担忧在于 Claude 工作速度很快。人类通常会把 2 小时中的一半时间用于阅读和理解问题，然后才开始优化。一个试图引导 Claude 的人很可能会一直落后，只能在事后才理解 Claude 做了什么。占优策略可能会变成袖手旁观。

如今，Anthropic 的性能工程师仍有大量工作要做，但这些工作更像是艰难的调试、系统设计、性能分析、弄清楚如何验证我们系统的正确性，以及弄清楚如何让 Claude 的代码更简单、更优雅。不幸的是，如果没有大量时间或共同背景，这些事情很难以客观方式进行测试。设计能够代表实际工作的面试一直很难，但现在比以往任何时候都更难。

但我也担心，如果我投入精力设计一份新的带回家完成的题目，要么 Claude Opus 4.5 也会把它解出来，要么它会变得过于困难，以至于人类不可能在两小时内完成。

尝试 1：一个不同的优化问题

我意识到，Claude 可以帮助我快速实现我设计的任何东西，这促使我尝试开发一份更难的带回家题目。我选择了一个问题，基于我在 Anthropic 做过的一个更棘手的内核优化：在避免 bank conflicts 的同时，对 2D TPU 寄存器上的数据进行高效转置。我把它提炼成一个在模拟机器上的更简单问题，并让 Claude 在不到一天的时间里实现了这些改动。

Claude Opus 4.5 找到了一个我甚至都没想到的绝佳优化。通过细致分析，它意识到可以转置整个计算过程，而不是去弄清楚如何转置数据，并据此重写了整个程序。

在我的真实案例中，这种方法本来行不通，所以我修补了这个问题，以排除那种做法。随后 Claude 有了进展，但没能找到最高效的解决方案。看起来我已经有了新问题，现在只需要希望人类候选人能足够快地解决它。但我仍有些挥之不去的疑虑，于是使用 Claude Code 的“ultrathink”功能并设置更长的思考预算进行了复查……结果它解决了。它甚至知道修复 bank conflicts 的技巧。

事后看来，这并不是一个适合尝试的问题。许多平台上的工程师都曾为数据转置和 bank conflicts 所困扰，因此 Claude 有大量训练数据可供借鉴。虽然我是从第一性原理找到解决方案的，但 Claude 可以利用更大的经验工具箱。

尝试 2：变得更奇特

我需要一个人类推理能够胜过 Claude 更大经验库的问题：某种足够超出分布的问题。遗憾的是，这与我希望它能被清楚识别为类似工作内容的目标相冲突。

我思考了自己喜欢过的最不同寻常的优化问题，最终想到了 Zachtronics 游戏。这些编程解谜游戏使用不同寻常、限制极强的指令集，迫使你以非常规方式编程。例如，在 Shenzhen I/O 中，程序被拆分到多个相互通信的芯片上，每个芯片只能容纳大约 10 条指令，并带有一两个状态寄存器。巧妙的优化通常涉及将状态编码到指令指针或分支标志中。

我设计了一套新的带回家完成的题目，由一些使用微型且高度受限的指令集的谜题组成，目标是将解法优化到最少指令数。我实现了一个中高难度的谜题，并在 Claude Opus 4.5 上进行了测试。它失败了。我又补充了更多谜题，并让同事验证：即使是不如我这样深度熟悉该问题的人，仍然能够胜过 Claude。

与 Zachtronics 游戏不同，我有意不提供可视化或调试工具。初始代码只检查解法是否有效。构建调试工具是测试内容的一部分：你既可以插入精心设计的打印语句，也可以让编码模型在几分钟内生成一个交互式调试器。如何判断在工具建设上投入多少，也是信号的一部分。

我对新的带回家测试还算满意。它的方差可能比原版更低，因为它由更多相互独立的子问题组成。早期结果很有希望：分数与候选人过往工作的水准高度相关，而我一位最有能力的同事的得分高于迄今为止任何候选人。

我仍然为放弃原版的真实性和多样化深度而感到遗憾。但真实性或许已是我们不再拥有的奢侈品。原版之所以有效，是因为它类似真实工作。替代版本之所以有效，是因为它模拟新颖工作。

一个开放挑战

我们将发布原版带回家测试，供任何人不限时间尝试。在足够长的时间跨度下，人类专家相较于当前模型仍保有优势。迄今提交过的最快人类解法，显著超过了 Claude 即便使用大量测试时计算所能达到的水平。

发布版本从零开始（类似版本 1），但使用版本 2 的指令集和单核设计，因此周期计数可与版本 2 相比较。

性能基准测试（以模拟机器的时钟周期数衡量）：

• 2164 个周期：Claude Opus 4 在测试时计算框架中运行多小时后的结果
• 1790 个周期：Claude Opus 4.5 在一次随意的 Claude Code 会话中的结果，大致相当于人类在 2 小时内的最佳表现
• 1579 个周期：Claude Opus 4.5 在我们的测试时计算框架中运行 2 小时后
• 1548 个周期：Claude Sonnet 4.5 经过远超 2 小时的测试时计算后
• 1487 个周期：Claude Opus 4.5 在该框架中运行 11.5 小时后
• 1363 个周期：Claude Opus 4.5 在改进的测试时计算框架中运行多小时后

在 GitHub 上下载它。如果你能优化到低于 1487 个周期，超过 Claude 发布时的最佳性能，请将你的代码和简历发送至 performance-recruiting@anthropic.com。

或者你可以通过我们的常规流程申请，该流程使用我们（目前）能抵抗 Claude 的居家测试。我们很好奇它能持续多久。