技术面试与团队招聘：技术 Leader 选人方法论

技术面试与团队招聘，是技术 Leader 最容易被低估、却最能决定团队上限的一项硬技能。招错一个人，后面半年的协作、代码质量和士气都要买单；招对人，团队会自己长出战斗力。很多工程师走上管理岗后才发现，写代码靠自己，带团队却要靠”选人”。本文把招聘拆成可落地的步骤，从能力模型到入职闭环一次讲清。

为什么技术 Leader 要亲自懂招聘

招聘不是 HR 的活，技术判断只能技术人做。HR 能筛学历、查背景、控流程，但”这个人能不能写出在生产环境扛住流量的代码””遇到模糊需求是会追问还是瞎猜”，只有同行能在面试里试出来。把技术面交给不熟悉业务的人，等于把团队的命交给陌生人。这也是为什么技术骨干到 Tech Lead 的第一课，往往不是架构，而是怎么看人（延伸阅读：技术骨干到 Tech Lead 的转身）。

先定义”我们要什么样的人”：能力模型

动面试前先写清能力模型，否则每个面试官凭感觉打分，结论无法对齐。下面这张评分卡是我们团队用了两年、按实际离职/晋升数据回测过的权重，可作为起点：

权重不是死的：初创团队把”学习与韧性”往上提，因为变化快；平台团队把”系统设计”提到 35%，因为一错影响面大。关键是有权重，而不是”聊得挺投缘”。我们曾经招过一位算法题满分、但系统设计面试里完全不考虑故障预案的工程师，入职后第一个需求就因为没有降级方案在流量高峰炸了。从那以后，故障预案在评分卡里从可选变成了必答项。这件事也提醒我们：面试题考什么，团队就会长成什么样子——你用什么标准选人，就注定了团队未来能扛住什么样的仗。

简历初筛：三个被低估的信号

简历阶段就能过滤掉一半不匹配，别把筛选全推给面试。看这三件事：

• “我”和”我们”的比例：能分清自己贡献、不把团队成果全说成个人的人，协作更靠谱。
• 技术深度信号：是否写清”为什么选 A 不选 B”。只列技术栈名字的，通常没踩过坑。
• 稳定性信号：频繁短跳要追问动机，但不一票否决——有些人前几段是试错，后面就稳了。

面试流程设计：分阶段聚焦

流程乱，等于每个面试官都在重复考同一题。分阶段、每阶段只盯一个目标，既省候选人时间，也省团队精力：

系统设计怎么出题，直接决定你招到的是”会做题的”还是”会做系统的”。评分卡比题目本身更重要：

interview_rubric:
  problem: "设计一个短链服务，估算 QPS 与存储"
  dimensions:
    - name: 需求澄清
      weight: 0.2
      signals: [主动问量纲, 问 SLA 与降级]
    - name: 方案权衡
      weight: 0.3
      signals: [选型有理由, 提缓存与分库]
    - name: 边界与故障
      weight: 0.3
      signals: [讲重试与幂等, 给限流降级]
    - name: 表达
      weight: 0.2
  pass_line: 0.7

行为面试：看协作与韧性

代码好但协作差的人，进团队是负债。行为面不是闲聊，用结构化问题逼出真实样本（STAR 法则：情境-任务-行动-结果）：

questions:
  - "讲一次你推动、却被反对的技术方案，后来怎样？"
  - "最近一次线上事故你扮演什么角色，复盘写了什么？"
  - "你怎么带一个比你资深的同事？"
red_flags:
  - 把团队成果全说成个人
  - 对失败避而不谈或甩锅他人
  - 只谈技术、从不考虑业务影响

行为面的答案，能和代码评审文化互相印证：一个平时认真 review 别人代码的人，面试里讲协作会更具体（延伸阅读：代码评审文化怎么建）。同样，技术方案评审里暴露的”只给结论不给权衡”毛病，在面试设计题里也会重现（延伸阅读：技术方案评审实战）。

决策与反馈：避免群体思维

面试结束最忌”大家感觉都不错就发 offer”。我们强制先做独立打分、再开对齐会：每人先匿名写维度分，同步到大屏后才开口讨论。这样能避免锚定效应——第一个说话的人定了调，后面的人跟着附和。给候选人的反馈也要结构化，哪怕拒信也写清”哪几个维度没达标”，这既是体面，也让团队招人标准越用越准。招聘质量本身，也是研发效能度量里常被忽略的前置指标（延伸阅读：用 DORA 指标驱动团队提速）。

入职前 90 天：招聘的闭环

很多人以为发 offer 就结束了，其实招聘的闭环在入职后。前两周就和新人对齐”什么叫干得好”，别只丢需求清单；设 30/60/90 天检查点，把面试时承诺的成长路径兑现成真实的带教和授权。一个在 90 天里快速进入状态的新人，比再面十场更省成本。招人时讲清的技术决策逻辑，也该和日常技术选型训练一致（延伸阅读：技术选型实战：决策矩阵）；而面试里看重的工程判断力，落到代码上就是少欠技术债（延伸阅读：技术债怎么管）。

常见反模式

• 只考算法刷题：刷得溜不等于能设计系统，漏掉最贵的能力维度。
• 用”像我”当标准：mirror bias 让团队越来越同质，反而失去互补。
• 高压 puzzle 题：考的是表演型临场，不是真实工程判断。
• 多人重复考同题：流程没分工，候选人被同一道题问五遍，体验差且浪费。

小结

技术面试与团队招聘，本质是”用结构化方法把不确定性降到最低”。先写能力模型，再分阶段聚焦，用评分卡而不是感觉打分，最后把闭环延伸到入职 90 天。招对人，团队会替你解决大部分问题；招错人，你后面所有的管理动作都是在还债。把招聘当成一个需要持续打磨的工程能力，它会反过来定义你的团队能走多远。