Ask HN：后 AI 时代，你们怎么面试开发者？
文章摘要
这是一则 Ask HN 讨论帖，发帖人 mdwelsh 抛出了一个当下几乎所有招聘方都在头疼的问题：在 AI 编程助手普及之后，该怎么面试开发者？帖子获得 47 分。
他观察到，自从 AI 编程助手兴起以来，他面试的开发者候选人中大约有 80% 会告诉他：自己已经不怎么亲手写代码了，而是在指挥 agent 写。这让他”深感不安”——虽然他也承认，这也许只是自己太老派了。他仍然希望确认团队里的开发者真的能自己写代码，并且在系统设计方面清楚自己在做什么。但由于 AI 工具演进得如此之快，这件事正变得越来越难以判断。
他想了解其他人在后 AI 时代的招聘中都看到了什么，以及面对那些说自己在开发流程上已经”完全 agent 化”（fully agent-pilled）的候选人时，大家是怎么处理的。具体来说他在纠结两条路：是继续做传统的 LeetCode 算法题和系统设计面试？还是干脆放弃，接受”无论如何每个人都会用 Claude Code”这个现实？
这个问题背后其实有几层张力：面试考察的究竟应该是”不借助 AI 的底层能力”，还是”驾驭 AI 产出高质量结果的能力”？如果候选人入职后本来就会用 AI 写大部分代码，那么禁止 AI 的面试还有意义吗？反过来，如果完全放开 AI，面试官又如何分辨候选人是真正理解问题，还是只是把题目整个丢给模型？评论区给出了来自一线招聘者、求职者的多种做法，形成了一份颇有参考价值的”面试方法清单”。
HN 评论精华
帖子有 42 条评论，讨论质量不错，大致形成了几种路线：回归”聊项目、看理解”，改考代码审查，给小题再要求现场扩展，以及完全拥抱 AI、考察驾驭 agent 的能力。同时也有不少人对”agent 化开发”本身表达了疲惫与抵触。
先写小程序，再不借 AI 现场扩展。 status_quo69 的做法最具体，也最能说明问题：先让候选人提交一个非常简单的程序——给一个 3 列 10 行的 CSV，做些基本的映射、结构化和数据建模，大概只需要一个类或结构体，外加单元测试，能在终端运行，最长的提交也不过一百来行 Java，多数人一两个小时就完成了。随后是结对面试：修改其中一条规则、把 CSV 扩展 5 行，让候选人在工程师陪同下扩展自己的程序，可以查 Google、用 AI 查库和语法，但会明确告诉候选人，如果让 Claude 直接生成答案，面试官就无法判断他们如何思考。他说自己已经面试了几十人，”每一个用 AI 生成提交的候选人都失败了，因为他们完全不知道从哪里下手”——不是不熟悉代码结构，而是”连口头拆解问题都做不到”，无论简历多么光鲜。而通过这套流程招进来的工程师，无论有没有 AI 工具都表现出色。
改考代码审查。 mnembrini 为招聘 Java/Spring Boot 高级开发，专门写了一个小小的待办事项 REST API，故意埋了许多错误，有明显的也有隐蔽的：缺少认证、没有测试、用 System.out 打日志等等，让候选人在不提供 AI 工具的电脑上审查代码。候选人指出问题后，他会扮演初级工程师，让对方解释为什么这是错误，借此观察他们如何向理解水平不同的人讲解技术问题。他并不要求找出全部问题，但一个都找不到就是危险信号。整个环节约 20 到 25 分钟，效果很好。unknownsky 说他在 AI 之前就喜欢让候选人审查 PR，”如今 AI 生成的代码都需要审查，这一点就更重要了”。jd7h 的思路很巧妙：过去他就会在技术题里故意留下歧义和缺失细节，看候选人会不会主动提问澄清，还是自作主张做错东西；现在他还会在题目中埋一个”不该做的事”或一个荒谬的决定，看候选人会不会反驳——因为 LLM 被过度训练去满足一切请求，编程助手大概会欣然照做。他推荐从 BullshitBench 这个基准中找灵感。
回归对话与项目经历。 Oras 认为 LeetCode 只能说明对方背过一套题和答案，他更愿意围绕简历提问：”讲讲你在 Y 公司做的项目 X，你做了什么、用了什么、为什么、学到了什么。”他还认为 LLM 和那些过度设计、把事情复杂化的开发者没什么两样，只要引导得当并理解公司整体系统，就能让它们做出好东西。pllbnk 说 AI 对他的面试毫无影响，只影响简历筛选——明显由 LLM 生成、毫无实质的简历会被直接标记。他也放弃了白板架构设计题，因为自己坐在候选人那边时才意识到那有多紧张、多难进入”表演设计”状态；现在他只做自然的对话，按候选人的水平问技术问题。hbrn 和 karmakaze 的看法类似：看对方是否有趣、有热情、有好奇心、有主见、有产品思维，”下班后你愿意和他一起玩吗”——这些比 LeetCode 更能预测成功；karmakaze 称之为”一场延长版的交互式图灵测试”。
付费试工。 paulddraper 的流程是传统技术面试（数据结构算法、白板架构）加上 1 到 2 天的付费试工，”有意思的是，没有人拒绝过试工”，因为候选人同样想降低自己的决策风险。jdlshore 和 mathgeek 指出，这对已经在职的人很不友好，可能涉及法律和时间安排问题，会把求职者池子缩小到只剩待业者；bayarearefugee 补充说，已经在职本身在统计上就是一种正面的社会证明，排除他们未必对公司有利。
完全拥抱 AI 的做法。 linesofcode 认为时代已变，应该直接问与 agent 编程相关的问题：让候选人搭一个 harness、解释什么是 skills，甚至把”自己实现一个 Claude Code”作为家庭作业。RomanKornev 说关键是”提示词、提示词、提示词”：给一个时间紧、范围大的难题，看候选人在交给 AI 之前如何拆解问题，前两条提示词就能提供很强的信号——他们是能有效引导模型，还是随波逐流接受 AI 的每个建议？是否了解各模型的局限、能否按任务切换工具？ram-bv 建议让候选人用任何编程 agent 做一个复杂的东西，然后逐一解释每个部分为什么这样做、有哪些替代方案、如何考虑可扩展性。fbrncci 所在的公司只招”AI 优先”的开发者，面试时把候选人丢进任意一个陌生仓库，要求只能通过内部 harness 用 AI 完成项目管理中规划好的一个较大功能，禁止手写代码，按他们与 AI 的交互和解决问题的模式、提问方式、提示词写法打分；即便如此仍会拒掉约 80% 的人。Serenacula 从求职者角度分享了一次愉快的经历：一个不要求写代码的家庭作业，题目是做一个把图片拆解成组成颜色的工具，AI 完全允许甚至被期待使用，但面试时要证明自己理解了问题和自己做的东西，”比传统面试好得多，它让我展示了工作的真实质量和思考，而不是一道美化过的逻辑谜题”。
但 agent 面试并不总是奏效。 smashburger 试验各种面试形式两年多，对比了两种一小时的技术面试：一种是给代码库和 Docker 镜像，让候选人用任意语言写一个新的辅助服务，禁止 agent 但其他资源随便用——这是他们最成功的方式；另一种是提前一两周把一个全栈 TypeScript 代码库给候选人，面试时任意使用 agent 实现一个工单——结果差异极大，很多人不做任何准备，直接把整张工单一次性丢给 Claude，于是他们停掉了这种面试。Terr_ 提醒，让候选人在自己电脑上运行公司提供的代码有安全风险，如今利用这点入侵求职者电脑的骗局越来越多，Docker 也挡不住恶意代码。
对 agent 化开发的疲惫。 latentsea 说自己”认真搞了一年 agent 工程”，现在越来越失望：如果家庭作业是实现一个 Claude Code，他会直接放弃这个机会，”看着人们的技能和判断力萎缩，让我明白我更看重与能独立思考的人共事”。他把 agent 工程比作新一轮的微服务热潮：人人都在做，有些人会做得极其糟糕；有些人仍会认真思考，有些人则交出认知控制权，”如果你是前者，长期和后者共事会让人筋疲力尽”。platevoltage 看完 RomanKornev 的方法后说”我得换个行业了，这简直是噩梦”；cyclopeanutopia 评价 fbrncci 的公司”听起来像开发者的地狱”。zerr 提出了相反的烦恼：怎样才能找到不强迫开发者变成提示词工程师的公司？sibeliuss 则从求职者角度坦言尴尬：他已经近两年没手写代码，过去一年用 AI 产出了大量结构良好的 Python 代码，可他从没亲手写过一行 Python，”如果重新找工作，这该是多么尴尬的对话”。mvk666 的一句话让人唏嘘：看到大家还在讨论面试方法感觉很不真实，他投了 8 个月简历，连一次面试都没拿到。