engineering-hiring-rubric

工程师招聘评估标准

为评估特定岗位和职级的软件工程师，制定一套完整的招聘评估标准和面试评分表。评估标准必须足够具体，确保两位从未交流过评估意见的面试官对同一位候选人的评分相差不超过一个等级。为此，需要：明确的行为锚点（针对每项能力，说明“强烈推荐录用”与“推荐录用”的表现有何不同）、经过校准的技术问题及书面评估标准，以及能够揭示真实信号而非受近因偏差影响的结构化复盘形式。还需加入校准说明，帮助面试官识别并纠正常见的评估偏差。

必填信息

如果尚未提供，请询问以下信息：

• 岗位 — 后端、前端、全栈、SRE/平台、数据、ML 或移动工程师
• 职级 — 初级（L3/IC2）、中级（L4/IC3）、高级（L5/IC4）或 Staff（L6/IC5）；如果公司的职级命名不同，请说明
• 团队背景 — 团队的产品或服务、团队规模，以及该岗位入职第一年要解决的问题
• 技术栈 — 用于技术问题的主要语言和框架；请明确列出技术栈
• 面试形式 — 使用哪些面试环节（电话初筛、编程、系统设计、行为面试、带回家完成的作业）；如果未指定，请提供建议的面试形式

输出格式

---

工程师招聘评估标准：[岗位] — [职级]

岗位： [例如：高级后端工程师] 对应职级： [例如：L5 / IC4 / 高级] 团队： [团队名称及一句话描述团队的工作内容] 技术栈： [语言和框架] 面试流程： [按顺序列出各轮面试]

---

1. 岗位定义与职级预期

岗位职责

[用 2–3 句话描述工作范围：负责哪些系统、要解决哪些问题，以及与哪些人协作。请根据提供的团队背景具体说明。]

职级标准

定义该职级获得“推荐录用”建议的最低标准。这不是理想候选人的描述，而是最低要求。

维度	[职级]最低要求	低一个职级（不推荐录用）	高一个职级（超出预期）
技术范围	[例如：“几乎不需要指导，即可端到端负责一项服务或重要功能领域”]	[例如：“能够完成定义明确的任务；在确定范围和方案时需要指导”]	[例如：“主导跨团队技术项目；制定技术方向”]
问题解决能力	[例如：“能够独立将模糊的问题拆解为具体的子问题”]	[例如：“能够很好地解决定义明确的问题；难以应对模糊的问题”]	[例如：“能发现他人忽略的问题；能梳理组织层面的技术难题”]
代码质量	[例如：“编写可用于生产环境的代码；考虑边缘情况；代码易于审查，无需大幅返工”]	[例如：“编写可运行的代码，但需要大量审查反馈”]	[例如：“制定代码质量标准；设计并推广他人采用的可复用抽象”]
沟通能力	[例如：“向同事和利益相关方清楚地说明技术决策”]	[例如：“能够与直接团队成员顺畅沟通；跨团队沟通或与利益相关方沟通时有困难”]	[例如：“推动跨团队达成技术共识；撰写供他人参考的文档”]
责任担当	[例如：“推动工作上线；部署后持续监控；主动跟进问题”]	[例如：“交付分配的工作；会升级问题，但不会推动问题解决”]	[例如：“对跨团队的结果负责；改进团队流程和系统，超出自身工作范围”]

2. 面试流程结构

轮次	形式	时长	面试官	评估能力
电话初筛	视频通话、技术问题	45 分钟	[招聘经理或高级工程师]	问题解决、沟通、基础技术深度
编码面试 1	实时编码 — [平台]	60 分钟	[工程师]	编码、数据结构、代码质量
编码面试 2	实时编码 — [平台]	60 分钟	[工程师]	算法、调试、代码质量
系统设计	白板 / 共享文档	60 分钟	[高级工程师/资深工程师]	系统设计、可扩展性、技术沟通
行为面试	结构化面试	45 分钟	[招聘经理]	主动担当、协作、成长心态
[可选] 居家作业	异步项目	[X 小时]	[评审人]	代码质量、全面性、实际问题解决

面试覆盖矩阵： 每个能力维度都必须由至少 2 位独立面试官评估。

能力	电话初筛	编码 1	编码 2	系统设计	行为面试
编码	○	●	●	○
系统设计	○			●
问题解决	●	●	●	●
代码质量		●	●
沟通	●	●	●	●	●
主动担当	○			○	●
调试		●	●

● = 主要信号 ○ = 次要信号

---

3. 编码面试指南

问题选择

每轮编码面试选择 1–2 道题。题目应能在 30–40 分钟内完成，剩余时间用于讨论和追问。优先选择有多个解决方案层级的题目，以便观察候选人能将思路推进到什么程度。

问题模板

问题：[标题]

提示词（读给候选人听）：

[问题陈述——请具体说明。包括约束条件（输入大小、取值范围）。避免出现考查读题而非解题的歧义。]

示例：

给定一个整数列表，表示某个交易日每分钟的股票价格，返回通过恰好买入和卖出各一次所能获得的最大利润。不得先卖出再买入。

优秀候选人会提出的澄清问题：

• [例如：“列表可以为空吗？”／“所有值都是正数吗？”／“利润可能为负数吗——也就是说，如果无法获利，我们是否应该返回 0？”]

解决方案分级：

级别	方法	时间复杂度	空间复杂度	体现出的能力
基础	[暴力求解——O(n²) 嵌套循环]	O(n²)	O(1)	能解决问题；理解正确性
预期	[单次遍历，跟踪截至目前见过的最低价格]	O(n)	O(1)	解题能力强；能解释权衡
优秀	[推广到 k 笔交易，或无需提示就扩展到带冷却期的变体]	O(n)	O(1)	具备 Staff 级别的推广思维

后续问题：

• [例如：“如果最多可以进行 k 笔交易呢？”]
• [例如：“你会如何测试这个函数？请写出 3 个测试用例。”]
• [例如：“请像在代码审查中讲解一样，带我了解你的代码。”]

此问题的评估标准：

信号	强烈建议录用	建议录用	不建议录用
问题理解	立即提出 1–2 个澄清问题；编码前指出边界情况	经 1 次提示后理解问题；遗漏 1–2 个边界情况	误解问题或需要反复澄清
解决方案质量	O(n) 解决方案；代码整洁；处理所有边界情况	在提示下完成 O(n) 方案；代码易读但有小问题	在提示下完成 O(n²) 方案，或解决方案正确但存在重大问题
代码质量	变量命名清晰；结构合理；通过代码审查	功能正常，但冗长或命名不一致	难以理解；需要大量审查反馈
沟通	全程讲述思路；解释复杂度；能够自我纠正	被问及时解释方案；能很好地回答后续问题	编码时沉默；无法解释自己的方法
后续问题	自信地扩展解决方案；指出进一步的改进	在适度提示下处理后续问题	无法扩展方案或解释权衡

---

4. 系统设计面试指南

符合 [Level] 级别的设计范围

在 [Level] 级别，预期候选人能够：

• [例如：高级：“设计完整系统，包括容量估算、组件拆分，并讨论故障模式”]
• [例如：中级：“设计系统的核心组件；可能需要提示才能考虑可扩展性和故障处理”]
• [例如：初级：“设计简单的客户端-服务端系统；重点考查思路是否清晰，而非对分布式系统知识的全面掌握”]

示例设计题

问题：“设计 [URL 缩短器／速率限制器／通知服务／行程匹配系统——选择一个与团队领域相关的题目]。”

评估维度：

维度	评估内容	强烈推荐	推荐	不推荐
需求澄清	候选人是否会在设计前提问？	在开始绘图前询问范围、规模、SLA 和关键用例	会提出一些问题；可能忽略规模或 SLA	不做澄清就立即开始设计
高层设计	能否描述主要组件？	组件划分清晰，选择有理有据；涵盖数据流	划分合理；可能过于复杂或过于简单	缺少关键组件，或无法解释数据流
数据模型	能否为系统设计架构或数据结构？	对核心实体建模，并讨论规范化与反规范化之间的权衡	架构合理；可能忽略索引或分区需求	无法为数据建模，或设计出明显错误的架构
可扩展性	能否识别并解决瓶颈？	主动识别瓶颈；视情况提出水平扩展、缓存或分片方案	经提示后会讨论扩展；解决方案合理	无法识别瓶颈，或提出的方案与规模不匹配
故障处理	是否考虑系统出问题时会发生什么？	主动讨论故障模式：单点故障、重试逻辑、幂等性	经提示后会讨论故障；能识别一些故障模式	不考虑故障；假定一切顺利
沟通能力	是否能清晰地讲解设计？	能与真实公司的工程师团队顺畅地主持这场会议	讲解清楚，能够跟上；但有些地方不够完善	难以理解；面试官无法理解其设计

设计追问

候选人介绍设计后，可使用以下问题深入探查：

• “请逐步说明峰值负载下收到写入请求时会发生什么——每秒 10,000 个请求。”
• “你的主数据库刚刚故障。系统会发生什么？”
• “你估算的 QPS 是 X。如果需要处理 100× 的流量，你会如何调整设计？”
• “这个系统在负载下最先会在哪个环节崩溃？”
• “你会如何在生产环境中监控这个系统？你的值班手册会包含哪些内容？”

---

5. 行为面试问题库

将每个问题映射到一项能力。每轮行为面试使用 STAR 格式（情境、任务、行动、结果）提问 4–6 个问题。不要提带有引导性的问题。

能力：主人翁意识与交付

1. “请讲讲你曾端到端负责的一件事——从设计到生产监控。上线后出问题时，你做了什么？”

   • 积极信号： 描述了主动设置监控、自己发现的具体事件，以及做出的改进
   • 消极信号： 只提到编写代码并移交；没有讨论生产环境中的表现

2. “请描述一个严重延期或失败的项目。你在其中承担什么角色？你为哪些事情负责？”

   • 积极信号： 直接承担自己对项目失败的责任；具体说明了工作方式上的改进
   • 消极信号： 将所有延期归咎于外部因素；没有反思自己的行为

能力：技术判断

3. “请讲讲你做过的一项重要技术决策。你考虑了哪些选项，又是如何做出决定的？”

   • 积极信号： 明确列出备选方案及其利弊；说明咨询过哪些人；反思如果是现在，是否还会做出同样的决定
   • 消极信号： 只说“我知道 X 是正确答案”，却没有描述决策过程

4. “请描述一次你不得不对某项技术方向提出异议的经历——无论这个方向来自管理层还是同事。后来发生了什么？”

   • 积极信号： 基于证据表达不同意见；沟通具有建设性；即使争论中没占上风，决策做出后仍愿意全力支持
   • 消极信号： 从不提出异议，或提出异议时情绪化且缺乏依据

能力：协作与沟通

5. “请讲讲你曾向非技术利益相关者解释复杂技术概念的经历。你是如何处理的？”

   • 积极信号： 使用类比或简化模型；确认对方理解；根据受众调整表达
   • 消极信号： “我用技术术语解释了一遍，然后告诉他们相信我就行”

6. “请描述一次你与同事在某种方案上存在严重分歧的情况。最后是如何解决的？”

   • 积极信号： 寻求第三方意见或数据；关注正确的结果，而不是证明自己正确；维持良好关系
   • 消极信号： 立即升级处理，或未充分沟通就让步

能力：成长与学习

7. “过去两年里，你犯过什么重要的技术错误？从中学到了什么？”

   • 积极信号： 错误具体明确；清晰分析原因；之后采取了具体的行为改变
   • 消极信号： 说不出具体错误；为了避免暴露弱点，只描述小问题

8. “你如何跟进 [相关技术领域] 的最新发展？请举一个你最近学到并应用的具体例子。”

   • 积极信号： 说出具体信息来源；在具体项目中应用所学，并取得明确成果
   • 消极信号： 只说“我会读博客”，却没有具体细节；没有应用实例

---

6. 完整面试评分表

每轮面试填写一份评分表。汇报讨论前收齐所有评分表。

INTERVIEW SCORECARD
===================
Candidate:         ______________________
Interviewer:       ______________________
Round:             ______________________
Date:              ______________________
Interview format:  ______________________

COMPETENCY RATINGS
Rate each dimension independently. Do not average.
Scale: 1 = Strong No Hire | 2 = No Hire | 3 = Hire | 4 = Strong Hire

                          1    2    3    4    Notes
Coding / Technical skill  [ ]  [ ]  [ ]  [ ]  ___________________________
Problem solving           [ ]  [ ]  [ ]  [ ]  ___________________________
System design             [ ]  [ ]  [ ]  [ ]  ___________________________  
Code quality              [ ]  [ ]  [ ]  [ ]  ___________________________
Debugging                 [ ]  [ ]  [ ]  [ ]  ___________________________
Communication             [ ]  [ ]  [ ]  [ ]  ___________________________
Ownership                 [ ]  [ ]  [ ]  [ ]  ___________________________
Collaboration             [ ]  [ ]  [ ]  [ ]  ___________________________

SPECIFIC EVIDENCE
What did the candidate do or say that drove your rating?
(Required — write observable behaviors, not impressions)

Strongest signal (positive):
___________________________________________________________________________

Strongest concern or gap:
___________________________________________________________________________

OVERALL RECOMMENDATION
[ ] Strong Hire    [ ] Hire    [ ] No Hire    [ ] Strong No Hire

OVERALL RECOMMENDATION RATIONALE
(Required — 3–5 sentences minimum. State your recommendation, the evidence
that supports it, and the specific gap or risk if not a Strong Hire)
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________

Level signal: This candidate demonstrated [ L_ / L_ ] level behaviors.

SHOULD INTERVIEWERS DISCUSS BEFORE DEBRIEF? 
[ ] No — I have a clear independent signal
[ ] Yes — I need context on [specific area] to complete my assessment

---

7. 招聘建议框架

建议	含义	适用情况
强烈录用	确信候选人将超出该级别的要求，并成为团队中的高绩效成员	在 3 项或更多能力上都有高于要求的表现；没有重大顾虑
录用	确信候选人符合该级别的要求，能够胜任工作	所有必备能力均达到要求；最多有 1 项有待提升
不录用	未达到该级别的要求	至少 1 项必备能力低于要求，或能力差距过大，无法在短期内弥补
强烈不录用	明显不匹配——表现远低于要求，或出现明确的淘汰性信号	多项能力存在重大差距，或在价值观／行为方面存在顾虑

[角色] 在 [级别] 的必备能力： [列出 3–4 项能力，其中任何一项被评为“不录用”，都意味着总体建议必须为“不录用”，无论候选人在其他方面表现如何。例如：“高级后端工程师的必备能力包括编码和系统设计。行为维度的出色表现无法弥补编码能力被评为‘不录用’。”]

汇报讨论规则： 只有满足以下条件时，“强烈录用”才能推翻一项“不录用”评价：(a) 该“不录用”评价针对的不是必备能力；且 (b) 给出“强烈录用”评价的面试官能够清楚说明为何这一顾虑不构成淘汰理由。“强烈不录用”不得推翻——应提交招聘经理处理。

---

8. 汇报讨论议程

口头分享评分表之前，先进行汇报讨论。所有人都必须先提交书面评分表。

DEBRIEF AGENDA — [Candidate Name]
Duration: 45 minutes
Facilitator: [Hiring Manager]

0:00 – 0:05  SCORECARD REVIEW
  Each interviewer states their overall recommendation only (no rationale yet).
  Facilitator notes alignment and disagreements on whiteboard/doc.

0:05 – 0:15  EVIDENCE ROUND
  Go around the table. Each interviewer shares:
    - Their strongest positive signal (observable behavior, not impression)
    - Their biggest concern (observable behavior, not impression)
  No discussion yet — just evidence gathering.

0:15 – 0:30  DISCUSS DISAGREEMENTS
  Address only the competency dimensions where interviewers disagree.
  Anchor discussion on: "What did you observe?" not "What do you think?"
  If interviewers assessed different competencies, disagreement may reflect
  insufficient signal — note this.

0:30 – 0:40  DECISION
  Reach a decision on overall recommendation.
  If consensus: state the recommendation and rationale.
  If not consensus: hiring manager makes the call and states why.

0:40 – 0:45  PROCESS NOTES
  - Were any questions unclear or hard to compare across candidates?
  - Any bias signals observed during the debrief? (see Section 9)
  - Feedback to improve the process for next time.

---

9. 校准与减少偏见的说明

在面试官首次为该职位开展面试前，向每位面试官简要说明以下内容。

偏见	表现形式	应对措施
光环效应	第 1 轮的出色表现影响第 2 轮的评分	先提交评分表，再阅读其他人的评分；独立评估每项能力
相似性偏见	“我喜欢这个候选人”与“他们的想法和我一样”相关联	要求每项评分都有可观察到的证据；自问：“这是其能力的信号，还是其与我的相似之处？”
近因偏见	最后的印象主导整体评分	面试期间做笔记；结束后立即记录证据；复盘依据书面证据，而非记忆
期望锚定	第一位面试官的意见左右其他所有人	复盘前，面试官之间不得口头讨论；复盘开始前必须提交书面评分表
以文化契合度为掩饰	声称“文化不契合”，却没有具体的行为证据	“文化契合度”不是此评分表上的有效维度；应基于证据评估协作与沟通能力
资历偏见	学历或过往雇主对评分的影响过大	面试前简报文件中不得列出教育背景；应关注已展现的行为
自信 ≠ 能力	无论答案是否正确，表达流利的候选人得分都更高	评估答案质量，而非表达风格；每道题都使用书面评分标准

---

质量检查

• 职级标准表为该职级设定了具体的最低要求，而非理想化特质，并与低一级和高一级的要求进行了比较
• 每个行为类问题都明确说明了强烈推荐录用和不推荐／不予录用的信号，而非仅列出问题文本
• 编码题包含不同层级的解法及其时间和空间复杂度，并为每道题提供带有行为锚点的评分标准
• 系统设计评分标准至少评估：需求澄清、组件设计、数据模型、可扩展性和故障处理
• 评分表采用可观察行为字段（“候选人做了什么或说了什么”），而非印象类字段
• 明确列出该职位和职级的必须满足能力
• 复盘议程要求先提交书面评分表，再进行口头讨论，以避免锚定效应

反面模式

• 不要为每项能力只设定一种行为锚点描述——必须分别定义强烈推荐录用和不予录用的表现，否则面试官无法校准评分
• 不要将“文化契合度”作为独立的评估维度——它会掩盖相似性偏见；所有判断都必须基于可观察到的行为证据
• 不要让面试官在复盘前分享评分表反馈——复盘前的口头讨论会让所有人都受到第一个表达的意见影响
• 不要为所有工程职位设置相同的必须满足能力清单——高级后端工程师和前端工程师有不同的硬性能力要求
• 不要跳过校准偏见说明部分——从未接受过光环效应、近因偏见和资历偏见简报的面试官，会在每一轮面试中重现这些偏见

示例触发语

• “创建一份面试评分标准。”
• “设计一套招聘流程。”
• “制作一份技术评分表。”