Cerebras的AI原生工程面试

2026年7月9日

为AI原生世界招聘工程师

作者：Sebastian Duerr 和 Hagay Lupesko

Cerebras的工程师在日常工作中使用AI，因此技术面试应当反映这一现实。在整个工程组织中，我们采用了现实的多步骤练习，允许候选人使用AI，同时面试官评估问题框架、验证、判断、沟通和所有权。候选人可用的工具已经改变，但优秀工程的标准并未改变。

AI编码代理，包括Codex-Spark和Cognition基于Cerebras的更快编码系统，正在迅速改变软件工程师的工作方式，为优秀的工程师提供了加速实现、调试、测试和探索的新途径。这篇博文分享了我们在调整技术面试以纳入AI使用和技能评估过程中的经验与洞见。

软件工程正在快速变化。如今，工程师们经常使用AI来探索不熟悉的代码、生成初始实现、调试失败、编写测试、比较设计选项以及自动化重复性工作。在Cerebras，这些工具是我们构建产品的一部分。然而，传统的技术面试往往要求候选人在人工环境中工作：没有AI工具，缺乏上下文，重点是时间压力下回忆熟悉的算法或晦涩的语言语法。

这种差距至关重要。面试应帮助我们了解一个人在实际工作中的表现，而不是他们模仿正在消失的工作方式的能力。

过去几个月，Cerebras工程团队的多个小组围绕一个简单的理念重新设计了部分面试流程：如果AI是工作的一部分，那么它也应该成为评估工作的一部分。这并不意味着降低对候选人的要求。相反，AI辅助面试让我们能够提出更多要求。我们可以超越语法回忆和小型编码谜题，转向现实的工程任务。我们不仅能观察候选人是否得出答案，还能看到他们如何构建问题、指导AI工具、检查输出、从错误中恢复以及做出合理的权衡。

"构建AI原生组织不仅是为团队提供新工具，还意味着培养正确使用这些工具的判断力。我们的招聘流程应帮助识别那些能将技术深度与这种新型杠杆相结合的工程师。"——Hagay Lupesko，工程高级副总裁

以下是具体的变化及其经验。

面试更接近实际工程

面试不再围绕孤立的算法展开，而是增加了类似工程师加入团队后面临的工作。候选人可能需要探索小型代码库、向现有服务添加功能、调查运营数据集、改进开发者工具或将不完整的请求转化为可工作的原型。虽然环境和细节因角色而异，但有效的练习通常共享几个特点：需要多个步骤、包含足够的模糊性以要求判断、奖励规划、测试和迭代。我们通常从具体目标开始，让每位候选人有清晰的切入点，然后开放讨论：你会改进什么？你会重新审视哪些假设？在投入生产前需要改变什么？这种递进过程展示了工程能力的不同维度：具体任务测试执行力，开放部分揭示产品直觉、优先级、沟通和设计判断，生产讨论则展现候选人是否能看到原型之外的可信性、安全性、可观测性、可扩展性和可维护性。

候选人被期望使用AI

在指定的AI辅助编码轮次中，候选人需提前知晓允许并鼓励使用AI。这种清晰性很重要，我们不希望有些候选人悄悄使用工具而其他人以为不能使用。我们并非根据是否使用特定提示公式来评分，而是评估候选人如何有效地与强大但不完美的工具协作，作为更广泛工程任务的一部分。

我们将AI协作作为一项技能来评估

在AI辅助面试中，我们不仅评估最终代码，还评估候选人如何与AI本身协作。这包括如何构建请求、提供有用的上下文、将工作分解为可验证的步骤、识别答案何时不完整或错误，以及决定何时依赖工具、何时质疑它。这些本身就是日益重要的工程技能。我们不将熟悉特定界面或提示风格作为目标，关键在于候选人是否能深思熟虑地使用AI、验证其输出并对结果负责。

我们寻找的信号包括：候选人在分派问题之前是否理解问题？是否能提供有用的上下文和约束？是否检查生成的代码而不是自动信任？是否能解释、更改和调试结果？是否测试包括边界情况在内的关键行为？最好的候选人保留对解决方案的所有权，他们使用AI提高杠杆，而不是外包判断。

"最优秀的候选人不把AI当作聊天机器人。他们用它来加快速度，但保持清晰的系统心理模型，验证变化，并对结果负责。"——Seb Duerr，技术人员

这一区别至关重要。生成代码变得越来越容易，但决定应该构建什么、识别答案何时错误以及将有前途的原型转化为可靠的软件仍然困难。

我们学到的经验

工作软件更早出现

当候选人可以使用现代工具时，他们往往能更早地在面试中达到可工作的第一版本。这并非评估的终点，而是更有趣评估的开端。一旦基本实现存在，对话可以转向更好地反映真实工程的问题：这能解决正确的用户问题吗？哪些部分应首先测试？设计在负载下表现如何？存在哪些安全或隐私风险？如何使系统对下一位工程师更友好？这影响了我们对难度的思考。好的AI时代面试问题不应因为需要晦涩的技巧而困难，而是要求一系列合理的决策。

验证成为首要技能

AI工具常常产生令人信服但细微错误的输出。因此，验证已成为面试中最强的信号之一。优秀的候选人会尽早运行代码、阅读错误消息、在选择表示形式前检查数据、要求测试并评估这些测试是否有意义、注意生成的代码何时更改接口、忽略约束、仅处理快乐路径或增加了问题不需要的复杂性。这并非新的工程技能——代码审查、测试、调试和怀疑精神一直都很重要，AI只是让它们更加显眼。能够捕捉并纠正看似完美的错误的候选人，往往比产生大量代码但未展示理解的候选人给出更强的信号。

面试设计比工具选择更重要

将AI助手添加到传统面试中并不自动使其更好。如果一个问题可以通过将提示粘贴到工具中并接受第一个答案来完成，那么该问题可能没有衡量我们关心的内容。练习本身必须为工程判断留出空间，这可以来自不完整的需求、不熟悉的代码库、嘈杂的数据、操作约束、相互竞争的优先级或第一版本有效后发生变化的要求。面试官也需要做好准备：评估AI辅助工作不仅仅需要计算完成的测试用例。面试官需要共享的评分标准、强弱协作模式的示例，以及关于不同经验水平应有何区别的校准。对于早期职业候选人，范围明确的任务和快速学习能力可能是正确的信号；对于高级候选人，我们期望更强的问题框架、更清晰的权衡以及对长期系统行为的更多关注。AI为候选人提供了另一种展示水平的方式。

人类对工作负责

我们对工程判断的标准并未改变。"允许AI并不降低招聘门槛，而是让我们检查更多重要的工作：候选人如何处理模糊性、评估权衡、沟通决策以及将初稿转化为可靠软件。"——Neeraj Khanna，工程总监

候选人仍然需要清晰推理、沟通方法、理解提交的代码以及建设性地应对失败。基础能力之所以重要，是因为它们使工程师能够评估生成的答案。系统设计和行为面试继续考察编码助手无法替代的维度：领导力、协作、所有权、技术深度以及根据上下文做出决策的能力。面试官依然至关重要。AI可以帮助总结活动或建议探究领域，但招聘是重要的人力决策。面试官负责理解证据、提出后续问题并一致地应用评分标准。

最重要的是，目标不变：识别能够与团队共同完成卓越工作的人。

在面试中使用AI

将AI引入招聘常被理解为允许与否的问题：候选人是否可以使用AI？我们认为更有用的问题是：什么能力将使优秀工程师在AI原生组织中脱颖而出？我们的答案包括许多一直重要的能力：好奇心、严谨、品味、沟通和所有权，以及有效和负责任地使用AI的能力。工程师需要知道何时加速、何时减速、何时委派以及何时质疑面前的答案。随着我们推行这些变革，我们看到了令人鼓舞的迹象：我们招聘的候选人提高了AI原生工程能力，引入了新的工作流程，同时加强了整个组织所重视的判断、验证和所有权。随着AI继续改变软件工程，我们相信我们的候选人评估流程将继续演进，以确保我们的工程组织能够最大化利用这一转变。AI可能写出更多初稿，但工程师最终对交付的产品负责。