在 AI 编码助手时代招聘软件工程师

AI 编码助手的兴起在技术招聘中造成了分歧：一些管理者担心基础编码技能的丧失，而另一些人则拥抱“以 AI 为先”的工作流。核心挑战在于区分那些能够设计系统架构的开发者，与那些仅凭复制粘贴 AI 建议却不懂底层逻辑的开发者。

信号的转变：从语法到分解

传统的 LeetCode 和语法密集型面试正逐渐失效，因为 AI 可以瞬间解决大多数标准算法难题。如今最有效的信号来自于评估候选人在编写任何代码之前如何分解复杂问题。

评估 AI 引导与提示技巧

对于采用代理式工作流的组织，面试的重点在于与 AI 的互动，而非输出结果。评估的关键指标包括：

• 问题分解：候选人能否将一个大范围的问题拆解为可管理的提示？
• 引导 vs. 盲从：候选人是否主动引导模型，还是盲目接受每一个 AI 建议？
• 工具选择：候选人能否根据任务的具体需求，在不同模型或工具（如 Claude、Cursor、Codex）之间切换？
• 工作流构建：一些公司现在会测试候选人是否能构建自己的内部工作流或自动化质量门禁和标准。

“以 AI 为先”的招聘模型

一些组织已完全放弃手动编码，转而采用集成 AI 的评估方式。一种 reported 的方法是将候选人放入一个真实仓库中，分配一个项目管理工单，并允许他们仅使用 AI。成功与否通过其解决问题的模式以及在大型、陌生代码库中使用 AI 工具导航的能力来衡量，前提是输出结果通过严格的内部质量门禁。

验证基础能力的策略

为应对“依赖代理”型候选人——即没有辅助就无法编码——的潜在风险，已涌现出多种验证策略：

“破损代码”审查

与其让候选人编写代码，一些面试官会提供一个小型、故意有缺陷的代码库（例如，一个缺少认证和日志记录的简单 CRUD API）。候选人必须在不使用 AI 工具的情况下审查代码并解释错误。这测试了他们阅读代码、识别缺陷以及向他人传达技术问题的能力。

配对扩展

为防止候选人使用 AI 伪造远程任务，一些团队采用两步流程：

1. 简单提交：提交一个基础编码任务（例如，映射一个小的 CSV 文件）。
2. 实时扩展：在配对会话中，面试官要求候选人修改规则或扩展数据。

"迄今为止提交 AI 生成内容的每一位候选人都失败了，因为他们根本不知道该往哪里走……他们甚至无法口头分解问题。"

替代评估框架

许多有经验的招聘者认为，最可靠的信号仍然是以人为本、基于项目的，而非基于工具的。

基于经验的探究

聚焦候选人的实际作品往往比人工谜题更有效。这包括深入探讨简历中列出的具体项目：构建了什么、为何选择特定技术，以及学到了哪些经验。这相当于一种“互动图灵测试”，用以验证候选人是否真正完成了其所声称的工作。

付费工作试用

一些公司正在转向在传统技术面试后进行为期 1-2 天的付费工作试用。这使得雇主和候选人都能通过观察真实工作环境中的表现来降低招聘决策的风险。

产品思维评估

对“软性”技术技能的重视日益增加，这些技能 AI 无法复制：产品思维、好奇心、真实性，以及用简单方式解释复杂概念的能力。这些特质正被视为比在压力下解决逻辑谜题更能预测长期成功的因素。