在 AI 编码代理时代面试软件工程师
AI 编码助手和自主代理的兴起,造成了传统技术面试与现代开发人员日常工作的脱节。随着越来越多的候选人表示他们主要是在指挥代理而非手动编写代码,招聘经理正在调整评估策略,以区分那些缺乏基本工程技能的“依赖代理”型开发者,以及能够利用 AI 放大自身专业能力的开发者。
从语法到问题分解的转变
评估候选人分解复杂问题的能力,现在比测试他们记忆特定语言语法的能力更为关键。当 AI 处理实现细节时,核心工程技能转向了问题分解和引导。
- 提示工程作为信号: 一些面试官现在将提示工程视为核心能力。这包括给候选人一个宽泛范围的问题,观察他们在将问题输入 AI 之前如何分解它。高信号指标包括候选人是否有效引导模型,还是盲目接受 AI 的建议,以及他们根据任务需求切换模型的能力。
- “代理优先”工作流: 一些组织已转向完全以 AI 优先的招聘流程。在这些模式中,候选人被放入一个真实仓库,并被要求使用内部 AI 工具实现一个功能。成功与否通过他们的交互模式、提问方式以及在受规则和质量门禁约束的系统中最终输出的质量来衡量。
- “一次性提交”的风险: 完全依赖代理的面试可能具有不稳定性。一些经理报告称,那些在没有准备的情况下直接将任务“一次性”提交给 LLM 的候选人,往往产生结果不一致,导致一些公司回归受限环境进行初步筛选。
验证基础工程严谨性
为应对那些会提示但无法工程化问题的候选人风险,已采用多种策略来确保技术能力的最低标准。
代码审查与漏洞挖掘
与其要求候选人从零开始编写代码,一些面试官会提供一个小型且故意存在缺陷的代码库(例如,一个简单的 CRUD API),并要求候选人不使用 AI 工具进行审查。这测试了:
- 批判性思维: 识别缺失的身份验证或不良的日志记录实践。
- 沟通能力: 解释某段代码为何是错误的,模拟资深工程师对初级工程师的指导场景。
“修改与扩展”配对会话
另一种有效的方法是两阶段流程:先提交一段简单代码(例如,从 CSV 进行基本数据映射),然后进行实时配对会话。在会话中,要求候选人不使用 AI 工具修改逻辑或扩展数据集。这揭示了候选人是否真正理解他们提交代码的底层结构,还是仅仅生成代码而没有理解。
替代评估框架
许多有经验的招聘者认为,无论是否使用 AI,传统的 LeetCode 风格面试提供的信号都很有限,建议关注更高层次的职业特质。
- 基于经验的提问: 关注候选人的实际经历——深入询问简历中具体项目的情况、所作决策以及学到的教训。
- 付费工作试用: 在初步技术面试后,实施 1-2 天的付费试用期,以降低雇主和候选人的招聘风险。
- 产品思维: 优先考虑“软性”信号,如好奇心、真诚度和产品导向思维,而非计算机科学的教条主义。
面试策略概览
| 策略 | 关注点 | AI 政策 | 收集的信号 |
|---|---|---|---|
| 代码审查 | 分析与指导 | 禁用 AI | 识别错误和解释技术债的能力 |
| 代理任务 | 引导与分解 | AI 优先 | 管理 AI 以生成高质量功能的能力 |
| 配对扩展 | 理解能力 | 提交时可用 AI,扩展时禁用 AI | 验证候选人是否理解生成的代码 |
| 工作试用 | 整合与交付 | 开放 | 真实世界表现和团队契合度 |
| 简历深度挖掘 | 经验与判断 | 无 | 经历的真实性与架构推理能力 |
Sources
相关
- Dispatch
- Dispatch
- Dispatch
- Dispatch
- Dispatch