招聘工程师：从一次面试到可验证的协作能力

招聘最难的不是在一小时里问倒候选人，而是判断双方能否长期合作。岗位需要的能力、面试观察到的行为和入职后的评价标准，应当尽量一致。

本文重写自《招聘与工程师文化》，去掉个人求职经历和当年的项目计划，保留对招聘方式及人才培养的思考。

先定义工作，再选择题目

算法题能观察抽象、推导和编码能力，但不能单独证明需求理解、维护意识和团队合作。反过来，做过某个热门框架的项目，也不能直接证明基本功扎实。

设计面试之前，先列出岗位中反复发生的任务：是在既有系统中定位问题，交付新功能，设计数据模型，还是协调多个团队。然后为这些任务选择能观察到相关能力的环节。

同一道题也可以有不同的观察重点。除了答案是否正确，还可以看候选人是否澄清条件、是否主动检查边界，以及收到新信息后能否修正方案。

博客、开源代码和长期作品能呈现一个人的思考过程，原文因此提出用公开积累补充短时面试。这个方向有价值，但公开作品并不是人人都有的条件。

有人长期处理内部系统，成果无法公开；有人承担了大量不显眼的维护工作。没有 GitHub 活跃记录，不等于没有能力。更合适的做法是让候选人选择能够分享的材料，也允许用匿名化案例或现场讨论替代。

阅读作品时，重点问取舍、限制和修改过程。漂亮的最终结果未必能说明谁完成了什么，解释一次失败和后续改进，往往提供更多信息。

贴近工作的小任务可以补充问答，但范围必须明确。不要把公司真实需求包装成免费试做，也不要用数天作业消耗候选人的时间。

例如给一个小模块和测试，让候选人解释问题、修复一个边界条件，再讨论扩展方式。提前告知预期时间、可使用的资料与工具、评价标准。如果考察的是推理过程，就允许把不确定之处讲出来，而不是只接受一个标准答案。

评价应尽可能记录行为证据：“补充了空输入测试”比“很细心”具体，“没有说明数据来源”比“缺乏业务感”更容易讨论。

如果面试要求严谨测试，入职后却从不安排测试时间，招聘标准很快就会失去意义。团队应把岗位期待延续到入职任务、代码评审和阶段反馈中。

内部学习材料可以从真实的高频问题整理：怎样运行项目，怎样定位失败，怎样提一个可评审的修改。材料成熟后再考虑公开分享，而不是先建设一个宏大的课程平台。

招聘提供的是一个有限证据下的判断。把标准写清楚，把反馈持续收集起来，才有机会知道面试到底筛选出了什么，又遗漏了什么。