先看证据
停用的是一种测法，不是工程能力
Anthropic 的招聘经理 Felix Reiseberg 表示，这个月他停止要求候选人参加传统编程面试。理由是，Claude 如今在 React 小挑战和汇编题上都比人更强，因而限时完成这类题目，越来越难说明一个人是否能胜任工程工作。这是 Reiseberg 对自己招聘做法的调整，材料没有说 Anthropic 全公司已经统一取消编程面试。
这项变化值得读，不是因为它宣告了“工程师不必写代码”，而是因为它触及了招聘评估的预测能力。面试题原本用一个短任务，推断候选人进入岗位后的表现；当模型可以承担更多同类编码任务，这种推断就可能变弱。技术负责人需要重新问的，是面试究竟在测岗位真正需要的能力，还是只在测一种熟悉、方便评分的技能。
代码题的信号为何会变弱
传统编程题并非毫无价值。它可以让招聘者观察候选人如何拆解问题、组织代码，并在有限时间里给出实现。但它也把能力压缩在一个特定场景里：任务边界由出题者划定，目标通常是尽快得到可接受的答案。真实工程工作则可能从目标含混、需求冲突或用户体验不佳开始，候选人得先判断问题是什么。
模型带来的变化，是让“能否产出一段代码”与“是否能作出有价值的工程贡献”之间的距离更明显。Reiseberg 说，他见过影响力很大的构建者并不擅长这些测试。这不是系统性数据，也不能证明编程题对所有岗位都失效，却提醒团队不要把考试表现直接当作工作表现的替代指标。题目越容易被模型完成，越需要检查它是否还在区分候选人，而非区分谁更熟悉考试形式。
把评估重心移到问题选择
Reiseberg 给初级工程师的建议，可以看作对新评估重点的说明：从清空 backlog 转向业务影响。工程师受雇是为了创造业务价值，而不只是把程序写出来。因此，候选人需要理解组织正在追求什么，再提出少数几个如果成功就能显著改善结果的想法。这里考察的不是点子是否听起来宏大，而是能否把技术行动与实际目标连起来。
这也改变了“主动性”的含义。主动不只是接下更多任务，而是看见现有任务清单没有表达好的问题，并愿意为解决它承担判断责任。对初级员工来说，这种能力可能来自对产品的直接观察：他们作为用户或新加入团队的人，或许更容易注意到体验中的阻碍。Reiseberg 将这种新鲜视角视为优势，但它仍需通过具体问题和证据呈现，不能仅凭“年轻人更懂用户”这样的概括来推定。
周末原型能绕过流程，也会模糊边界
Reiseberg 建议把一个好想法在周末做成原型。他观察到，小团队或个人有时可以用一个能运行的东西，越过先写产品需求文档、争取认同、等待设计或产品资源的常规流程。原型把抽象主张变成可讨论的对象，也能让团队更早看到问题、实现路径和潜在价值。这种做法与模型降低开发成本相互呼应：当初步实现更快，想法就更容易被展示和检验。
但原型不是中性的招聘证据。它可能偏向有更多空闲时间、设备和相关背景的人，也可能把表达能力或对组织内部语境的熟悉程度，误判为工程判断力。材料没有声称这些偏差已经在 Anthropic 的招聘中出现，它们是任何团队把原型纳入面试时需要处理的风险。招聘方应明确题目范围、时间预期和评价标准，避免把范围不断扩大的无偿项目包装成“看主动性”。
好原型要收敛，招聘标准也要分层
原型的说服力不来自塞进多少功能。Reiseberg 特别提醒，初级员工容易把多个想法挤进一个作品，结果是二十个一般点子遮住了几个真正好的方向。聚焦一个想法，反而更容易看清候选人如何界定问题、选择范围，并判断什么值得继续投入。对招聘者而言，评价重点应落在这些决策及其理由，而不只是原型最终看起来有多完整。
这并不意味着所有岗位都应取消代码题，或统一改用周末项目。若工作需要调试复杂系统、理解代码约束，或审查模型生成的实现，技术基础仍然是实际能力的一部分。更稳妥的做法，是按岗位拆开评估：既看候选人能否理解问题和说明取舍，也用与工作相关的方式检查必要的技术功底。Reiseberg 的经验提供了一个重新设计信号的理由，但没有给出适用于所有团队的验证结果。模型改变了代码生产的成本，招聘者仍要为评估是否公平、是否可比、是否贴近工作负责。