当 AI 替我们写代码时，我们如何招聘工程师
-----------------
2026 年 2 月 25 日
作者：Dan Federman (AI助手Tolan的创始人)
大多数技术面试的流程在根子上就有问题。
它们要么考你背诵一些你在工作中根本用不上的算法，要么考你对面试官认为“你应该倒背如流”的某个 API 的记忆力。
我在 Airbnb 工作时，曾经非常努力地推动把现场面试里的算法题移除掉。有一道特别离谱的题，要求工程师模拟水如何在一个由二维数组表示的地形中流动。我希望我们的面试考察的是：未来的同事能否写出逻辑严谨、易于维护的代码；我并不在乎他们在高压计时环境下递归写得多熟，或者能不能避免 off-by-one 这类边界错误。
但移除算法题只是战斗的一半。我们仍然需要设计一种面试流程来考察实用能力！这一直都很难把握：我想看到候选人如何处理具有真实世界规模的问题，但我能与候选人相处的时间又很短。面试不应该变成工程师打字速度的替代测试。
不过，过去那些很耗时的工程问题，如今不再耗时：AI 极大压缩了从零到可用功能所需的时间。在 Tolan 设计我们的面试流程时，我意识到：通过鼓励候选人使用 AI，我们可以更充分地获取他们在完整能力范围上的信号。既然我现在把要上线到生产环境的大部分代码都交给 AI 来写，那把 AI 纳入面试流程就非常合理。
所以我们从零开始设计面试流程，让它尽可能贴近我们日常工作的样子：如果我给你一份产品规格，你能不能快速把它做出来？你能不能指出其中的漏洞？你能不能推理权衡取舍？你知道什么时候东西还没准备好上线吗？你知道什么时候它已经准备好让别人评审，并且能够被另一个人维护吗？
候选人会在上午来到我们旧金山的办公室。我会给你一个小问题——一个我们自己已经做过的题目——通常来源于一个极简的 Figma 文件或一段简短的规格说明。它可能是一个简单流程或一个轻量功能，正常情况下大概要一两天才能做完并上线。但在这个练习里，你只有几个小时——这点时间不足以做出一个精致的产品。我想看的是你如何在约束下工作。
我们鼓励你用 AI 来解决问题。作为员工你会想用什么工具，面试时就用什么。需要的话，我们可以提供 Claude、Codex、Cursor 或 Gemini 的授权。我想看你如何在 LLM 生成的代码与自己的判断之间取得平衡。
但别搞错了——即便代码不是你亲手写的，你也要对最终结果负责。我想看到你如何切入问题、如何组织方案、如何思考约束、以及你如何决定哪些事情真正重要。
午饭前，我们会坐下来聊 20–30 分钟，谈谈你做出来的东西；我也会问：如果你还有更多时间，你会改进什么？在你把它发给我做评审之前你会改什么？在我们真正上线之前你又会改什么？我想招聘的是：知道自己作品何时还不够好、并且知道如何把它做得更好的人。
然后我们去吃饭。
几点建议
----当候选人用 LLM 去“替自己思考该怎么完成项目”时，我会有点坐立不安。仅仅把 Figma 截图、上传到 Claude Code，再让它把问题解决掉，这不够。你是懂架构的。让我看到你的能力！
----真正优秀的候选人会在规格不清晰时提出质疑。他们会澄清问题陈述、探索边界情况、考虑最终用户。他们能识别取舍。当某些地方有点怪、或者感觉不太对劲时，他们会指出来。
----在一个“实现越来越容易”的世界里，我要看的其实是判断力。你没有足够时间做出精致的产品——既然如此，我想看你愿意牺牲什么。以及当你无法把所有细节都做到看起来、用起来都刚刚好时：到底是什么会让你抓狂？
----最好的候选人会用创造力给我惊喜。我刚招到一位工程师，他做了一个小游戏，让用户在等待 LLM 回复很久的时候也能被娱乐到。太棒了！
----“能跑起来的代码”不是终点。我见过候选人说：“我还不太确定这部分到底做什么”，然后又说他们在人类评审之前也不会改任何东西。糟糕！这种候选人是过不了的。
----如果你不理解自己的代码，它就还没准备好让另一个工程师评审；也还没准备好被维护，更不可能准备好上生产。
AI 的确改变了工程师能产出多少代码，但它并没有改变“什么样的工程师才算优秀”。即便在我们把代码库“克劳德化”（全面引入 Claude）之前，我也一直在招那些能够推理、沟通、并做出明智判断的人。