“编程面试已死”,死掉的究竟是什么?
2026年10月,Anthropic工程经理Felix Rieseberg在社交平台上写下一句话:“编程面试已经死了,至少对我的团队而言。”他负责的团队曾主导Claude.ai、Cowork和Claude Code Desktop的工程开发,而在这个月,他把传统编程面试从招聘流程中正式移除了。理由直白得近乎残酷:当Claude已经能轻松完成小型React挑战,甚至处理底层汇编问题,继续用这类题目筛选工程师,就像在2026年考问候选人会不会手写汇编一样,衡量的早已不是人的能力。
这条消息在中文程序员社区迅速发酵,标题被提炼为“编程面试已死”,但真正值得追问的不是一个耸动的判断,而是它背后那根信号链条的断裂:如果面试题不再能区分谁更有可能成为一个好工程师,那么招聘应该看什么?一个没有资历、没有人脉、没有话语权的初级开发者,又该拿什么证明自己?
一、一道React小题为什么不再有信号
传统编程面试的逻辑建立在一个隐含假设之上:一个人在高压下独立写出正确代码的能力,与他在真实工作中的工程表现正相关。这个假设曾经大体成立。Rieseberg本人也承认,过去一道React小题或一个小型编程挑战,虽然无法完整衡量一名工程师,但多少能反映候选人定义问题、快速寻找解决方案的水平。
问题在于,AI把这条相关性曲线压平了。当Claude能够以稳定水准完成绝大多数面试级别的编程题时,继续让候选人做题,测出来的首先是“这道题本身有多难”,其次才是“候选人比Claude差多少”。Rieseberg的观察更尖锐:团队中创造最大价值的工程师,之所以成功,与他们是否擅长这类测试无关。面试成绩与工作表现之间的统计关联一旦弱到无法支撑招聘决策,这道题就失去了作为“信号”的资格。它不是变得不公平了,而是变得不相关了。
这也解释了为什么“编程面试已死”不能简单理解为“编程能力不重要了”。编程能力仍然重要,只是它不再稀缺到足以充当筛选门槛。当一项能力的供给端被AI大幅拉平,用它来区分人,就像用“会不会用键盘”来筛选程序员一样,不是错,而是浪费了一次宝贵的判断机会。
二、“饥饿胜过资历”:Rieseberg到底在说什么
Rieseberg给初级开发者最重要的一句话,浓缩在他那篇博客的标题里:Hunger beats tenure,饥饿胜过资历。这不是一句励志口号,而是他对AI时代工程价值分配方式变化的一个判断。
过去,工程师的职业壁垒有很大一部分建立在“知道怎么做”之上:熟悉框架、记住API、积累踩坑经验、掌握某套工具链的细节。这些知识需要时间才能获得,资历因此天然构成优势。但AI正在降低这种知识积累对执行速度的限制。Rieseberg看到的是,一些入行时间不长的工程师,借助AI快速超过了编程基础更好、从业时间更长的同行。差距不再主要产生于“谁能写出来”,而开始产生于“谁选对了要写什么”。
他给出的操作路径只有四步,每一步都指向同一个目标:用可运行的东西替代不可验证的言辞。
第一步,优先考虑业务价值,而非积压工作。 Rieseberg引用Patrick McKenzie 2011年的一句话:雇用工程师是为了创造商业价值,而不是为了编写程序。他建议初级工程师先弄清楚自己所在的团队、部门乃至上级的上级真正想达成什么目标,然后围绕这个目标寻找可以显著改善结果的机会。这听起来像常识,但大多数初级工程师的默认行为是埋头消化待办清单,把“完成任务”误认为“创造价值”。
第二步,提出一个大胆的想法。 不是十个微小的改进,而是一个如果做成、能够明显提高组织达成目标概率的想法。
第三步,利用一个周末把它做出来。 传统路径需要写PRD、争取经理支持、协调产品经理和设计师、排队等待工程资源。Rieseberg观察到,一些小团队甚至单枪匹马的工程师跳过了这些环节,直接用AI搭出可运行的原型。原型的作用不是“完美”,而是让决策者能够点击、运行、体验,从而让一个新人的想法不再完全依赖职位和内部人脉来获得注意。
第四步,专注于一个好点子。 他特别警告初级工程师常犯的错误:把多个想法塞进同一个原型,结果让二十个平庸的点子掩盖了其中三个真正出色的。一个好的原型首先承担沟通功能,它要让管理层迅速理解机会在哪里,同时意识到“你就是那个有能力把这件事继续做下去的人”。
这套建议的底层逻辑并不复杂:当执行成本大幅下降,组织对“能把事情做出来的人”的识别成本也随之下降。你不需要先获得许可再证明自己,你可以先做出一个可运行的东西,用它来争取许可。Rieseberg在Anthropic内部举的例子颇具说服力:两名入职时间不长的工程师Anthony Morris和Alice Zhao用一个周末做出了Claude Code图形界面的可工作原型,大约八天后第一个公开版本发布,这个界面后来成为相当受欢迎的产品。这条路在过去需要经历需求讨论、PRD、设计协调和资源排队,而AI让一个小团队可以先完成产品,再用成品证明需求存在。
三、不考编程题了,那考什么?
Rieseberg的坦率之处在于,他公开承认自己还没有找到完美答案。目前他在筛选简历和作品集时,会特别留意那些能够体现审美判断力、共情能力和原则性思维的小型原型作品。换句话说,评估的重心从“你能不能写出正确代码”转向了“你选择做什么、为什么这样选择、你做出的东西让不让人愿意使用”。
这种转向并非Anthropic独有。Google从2026年下半年开始,在部分软件工程师面试的“代码理解”环节允许候选人使用Gemini,评分维度从单纯的编码结果扩展到提示词设计、输出核验和调试能力。Canva则明确要求候选人在技术面试中使用Copilot、Cursor或Claude,并把问题设计得更复杂、更模糊、更像真实产品开发,因为传统计算机基础题“AI几秒钟就能给出正确且带有完整解释的答案”。Shopify的2026年工程面试中也出现了AI辅助编码环节,候选人自带IDE和AI工具,在一个空仓库中工作,被评估的是如何指挥工具以及如何清理它的输出。
这些实践的共性在于:面试正在从“闭卷考试”变成“开卷的真实工作模拟”。考的不再是记忆和熟练度,而是在AI已经能提供大量候选方案的前提下,人如何判断、选择、修正和负责。
但这条路上有一个尚未解决的硬问题。Rieseberg的帖子下就有开发者直言:传统编程面试确实失去了信号,问题是一场60分钟的面试里目前还没有找到更好的替代指标。更尖锐的质疑在于,当评估依赖“作品集”和“原型”时,那些没有时间、没有资源、没有余裕在业余做side project的候选人,是否会面临新的不公平?以及,一个能做出漂亮原型的候选人,是否就一定能成为好的团队成员?这些质疑没有被Rieseberg的乐观叙事完全消解,也不应该被消解。
四、谁的机会,谁的焦虑
“编程面试已死”对不同位置的人,意味着完全不同的东西。
对于已经入行的资深工程师,这条消息更多是一个信号:面试形式会变,但竞争不会消失。当编程题不再能替他们挡住涌入者,他们需要在一个更接近真实工作的评估场域中证明自己的判断力和协作能力。过去那种“刷三个月题、拿一个offer、然后慢慢学”的路径正在收窄。
对于初级开发者,Rieseberg的判断之所以值得认真对待,恰恰因为它不是简单的“AI会取代你”或“AI会拯救你”。他指出的机会有具体的结构:新人拥有一种老员工已经磨损掉的东西——对“什么不合理”的敏感。他回忆自己加入Stripe时,创始人Patrick Collison提醒新员工留意那些让自己觉得奇怪的事情;在Notion面试时,他被要求设计一套团队普遍认为“不可能”的离线模式,而恰恰因为他不知道这条“潜规则”,才开口问了那个已经被老员工停止追问的问题。他自己后来也成了那个告诉新人“别折腾了”的老员工,直到一个新同事重新把电视装进了办公室。
这种“无知的力量”有一个残酷的前提:没人关心你的想法,除非你能把它变成可运行的东西。Rieseberg的文章标题里其实藏着一层不那么温和的意思。初级工程师的确拥有新人视角,但组织不会因为你有视角就给你资源。AI之所以可能改变这一点,不是因为组织变得慷慨了,而是因为展示成本被压到了足够低——低到一个周末的原型就足以替代一场层层审批的说服。
但这同时也意味着,那些只把AI当作“更快完成待办事项的工具”、而不去主动寻找业务突破口的新人,并不会自动获得这份红利。Rieseberg的观察是,很多公司对初级员工的期待仍然停留在“利用AI更快完成手头任务”,而不是“围绕业务目标主动寻找突破口”。机会存在于预期之外,而不是预期之内。
结语:死的不是编程,是“用编程证明自己”的旧通道
“编程面试已死”这个标题容易制造一种错觉,仿佛编程能力本身贬值了。更准确的读法是:用编程题来分配职业机会的那套信号系统,正在失去效力。这不是Anthropic一家公司的实验,Google、Canva、Shopify的动向指向同一个方向;但它也远未成为全行业的既成事实,大量传统企业仍然会继续使用算法和代码测试,Anthropic自己官网也仍显示部分技术岗位会进行Live Coding。
真正的变化发生在更深的层面。软件工程已经经历过多次抽象层级的上移:从汇编到高级语言,从手写基础代码到调用框架和云服务,每一次都让“会写某种代码”从核心竞争力降格为基础能力。AI正在推动又一次上移。在这一次上移中,程序员需要证明的不再是“我能写出这段逻辑”,而是“我知道该让AI写什么、我能看出它哪里不对、我做的事和业务结果之间有一条说得通的路”。
对于初级开发者,这既不是末日,也不是免费午餐。Rieseberg给出的建议可以压缩成一句话:不要再试图用“我很会写代码”来敲门,用一个周末做一个真正有人愿意用的东西,让作品替你说话。 这比刷一百道LeetCode题更难,因为它没有标准答案;但它也更诚实,因为它考的正是工作本身。
若内容若侵犯到您的权益,请发送邮件至:platform_service@jienda.com我们将第一时间处理!
所有资源仅限于参考和学习,版权归JienDa作者所有,更多请访问JienDa首页。





