hiring

招聘

开始之前

先检查是否有 EM 背景信息。如果 .agents/em-context.md 存在，请先阅读。

如果 .agents/em-context.md 不存在，请先询问最简经理档案，并在给出详细建议前将其保存：职位/头衔、团队规模、团队使命或负责领域，以及当前挑战或优先事项。

如果对话中某个特定人员是核心人物，且 .agents/reports/[name].md 不存在，请先询问该人员的最简档案，并在给出详细建议前将其保存：职位/级别、任职时长、优势，以及当前挑战或成长领域。

如果后续对话揭示了持久的新背景信息，请自动更新 .agents/em-context.md 或 .agents/reports/[name].md。保存稳定的事实和模式，不要保存猜测、一时的挫败情绪或尚未厘清的解读。

回复风格

第一条回复应简洁且有用。除非用户要求深入讨论，否则不要一口气罗列完整框架。

默认：

• 先说明可能的诊断或建议
• 只有在缺失的背景信息会改变建议时，才提出最多 2–3 个有针对性的问题
• 给出下一步具体行动；适用时，提供经理可以直接使用的确切措辞
• 简要提及相关框架，但不要解释每个部分
• 先直接回答，再提出可提供更深入的版本

---

如何使用此技能

先识别情境：

• 设计面试流程或决定是否安排工作样题 → 参阅《先做工作，再招聘》
• 校准职级 / 考虑招聘初级员工 → 参阅《为什么应该招聘初级员工》
• 担心文化偏见影响评估 → 参阅《啤酒测试偏见》
• 在管理岗位的内部晋升和外部招聘之间做选择 → 参阅《内部晋升还是外部招聘》
• 新员工未达到预期，正在考虑是否采取行动 → 参阅《为新员工建立客观评估机制》

---

默认回复结构

在提供招聘建议时，将建议转化为招聘方案：

1. 招聘目标： 这个岗位或新员工必须解决什么问题。
2. 门槛 / 证据： 哪些证据应能证明候选人有能力胜任。
3. 流程： 面试流程、工作样题、复盘或 30/60/90 天计划。
4. 偏见检查： 哪些因素可能导致决策受到相似性、紧迫感或沉没成本的影响。
5. 决策措辞： 简明建议：录用、拒绝、校准或收集更多证据。

对于新员工相关问题，应将重点从候选人评估转为客观的 30/60/90 天成功标准。

---

为新员工建立客观评估机制

新任经理最常见的错误，是因为表现不佳的员工正在进步，就继续容忍他们。解决办法要从第一天开始。

提前定义成功标准。 在员工入职前，写下具体预期：

• 他们多久能在没有帮助的情况下完成代码仓库 X 中的任务？
• 你期望他们在入职 30/60/90 天时完成什么类型、什么规模的任务？
• 他们应何时开始参与值班？何时开始参与技术设计？
• 对高级员工：你期望他们提供哪些意见并主动采取哪些行动？

如果没有这些标准，你就会逐渐放宽要求。由于没有可供参照的标准，即使只是小幅进步，也会让你觉得已经成功。

设置“今天还会录用吗？”检查点。 在入职 30 天时（以及 60 天和 90 天时），问自己一个问题：“基于我现在掌握的信息，我还会录用这个人吗？”

• 如果会：告诉他们。这能建立真正的信任。
• 如果不会：采取行动。每多等一天，你对团队和他们造成的伤害就更大。
• 如果觉得“还需要更多时间”：诚实面对自己。通常 30 天时你就已经知道答案。3 个月几乎总是足够的。

不要问“有他们在，我是不是比没有他们时更好？” 这个问题会让你受沉没成本影响——培训时间、双方关系，以及重新招聘的麻烦。应改问面向未来的问题。

为什么你应该招聘初级开发者

大多数公司都有借口不招聘初级开发者——团队太小，无暇指导；发展太快；基础设施太复杂。这些理由大多都是胡扯。

抱负、品格和头脑与经验关系不大。有些开发者不到 3 年就成了高级开发者。经验带来的收益会递减：你能看出 1 年和 5 年经验的区别；但 10 年和 15 年之间，恐怕就看不出来了。

下一次招聘时，雇用优秀初级开发者的 5 个理由

1. 候选人范围更广。 当你需要“精通全栈，拥有 5 年以上 Python 和 3 年以上 React 经验”的人选时，选择会少得多，而且你可能不得不妥协。放宽条件，意味着你有机会接触到绝对顶尖的人才。

2. 充满活力。 初级开发者渴望学习，也有证明自己的动力。他们的热情会感染他人。团队里的高级开发者喜欢和聪明、积极的人共事，也有机会指导他人——如果团队全是高级开发者，他们可能就没有这样的机会。

3. 不会受限于已有知识。 他们不会试图沿用之前任职公司的技术或模式，而是能不受固有经验束缚地解决问题。

4. 更灵活。 他们更愿意接触新技术，对任务也不那么挑剔。这并不意味着只给他们分配烦人的 Bug，但确实能让你有更大的灵活性。

5. 更容易培养。 优秀的初级开发者渴望获得反馈，也会主动寻求进步。他们想知道你如何评价自己的工作。

实习的优势

初级开发者通常通过学生或实习生岗位进入团队。这意味着你可以在提供全职职位之前评估他们的能力——招聘高级开发者时，你可没有这样的机会。

团队应该像河流，而不是湖泊

把团队想象成一条河，而不是一个湖。湖水会停滞——滋生平庸与自满。河流则奔流不息、不断变化，充满活力。河流依赖人员的流动：新鲜血液、新领导者，以及准备迎接新挑战的资深成员。如果你从不招聘初级开发者，团队就会停滞不前。

根据技能，而非资历付薪

招聘初级开发者，并不是为了获得不断轮换的廉价劳动力。初期给初级开发者较低的薪酬是合理的——你需要投入时间和精力培养他们。但优秀的初级开发者证明自己之后（通常只需一年），就应该根据他们的技能，而不是工作年限来付薪。否则，他们就会去其他公司担任中级或高级职位，而且这完全合情合理。

确实需要高级开发者时

有时，你需要特定领域的专业知识：首次开发 iOS 应用、解决大规模性能问题，或驾驭真正复杂的业务领域。在这些情况下，就招聘高级开发者。对于大多数开发标准 SaaS 产品的团队来说，初级与高级开发者的比例可以相当高。

---

啤酒测试偏见

“我愿意和这个人一起喝杯啤酒吗？”——或类似的问题——是招聘中最常见的非正式筛选标准之一。它看起来像是在考察文化契合度，实际作用却是筛选出与面试官相似的人。长此以往，团队的多样性会降低，已有的盲点也会进一步加深。

这种偏见会影响双方。你可能会低估真正出色的人，只因为他们的沟通方式不同、背景不同，或者在 30 分钟的对话中没有立刻赢得你的好感。

比较优势论。 招聘的目标不是找一个你愿意与之交朋友的人，而是找一个优势能够弥补团队短板的人。全员都与现有团队相似的队伍，不如拥有多样化思维方式、经历和视角的队伍强大。

克服这一偏见的 5 个步骤：

1. 明确审视自己的偏见。 在复盘前，问问自己：“我给这个人的评分较低，是因为实质性的理由，还是因为他们与我不同？”
2. 关注优势，而非缺点的缺失。 这个人有哪些擅长之处是团队其他人都不具备的？这个问题能改变决策。
3. 提前规划面试对话。 不要即兴发挥。即兴对话容易转向让人感到自在的话题——你熟悉的内容、你能识别的风格。
4. 征求对你招聘流程的反馈。 请一位没有参与招聘流程的同事审阅你的复盘记录。他们看到了哪些规律？
5. 根据候选人调整你的方式。 来自初创公司的资深工程师，与来自大型科技公司的资深工程师，沟通方式会有所不同。两者没有优劣之分。你的流程应该能展现两者的特点。

这不是要降低标准，而是确保标准衡量的正是你认为它在衡量的东西。

---

内部晋升与外部招聘：为什么应优先内部晋升

管理岗位空缺时，人们的第一反应通常是向外招聘。外部候选人能带来经验和新视角，也没有历史包袱。这看起来像是稳妥、专业的选择。

但实际情况是：

内部晋升短期内更困难——这位员工没有管理经验，团队中的其他人可能觉得自己被越过了，你的 VP 可能需要提供更多支持，而且这位员工还得摸索如何管理曾经的同级同事。

但从长远来看，内部晋升的理由很充分：

• 他们在过渡期间仍能做出技术贡献
• 他们真正了解哪些方面需要改进
• 他们熟悉代码库、团队成员和客户
• 对于投资培养自己的公司，他们更有可能保持忠诚

如果团队中没人想尝试管理工作，这一点值得探究。这可能意味着大家看不到发展路径，也可能意味着在他们看来，管理工作缺乏吸引力。

你的职责是帮助团队成员走出舒适区、实现成长——如果他们有兴趣，也包括走上管理岗位。管理职位空缺时，在对外招聘之前，先问问自己团队里谁已经准备好尝试。很多时候，合适的人选只是缺少一个机会。

雇用前先看看工作表现

摘自 Peopleware（DeMarco 和 Lister）：你不会不先看杂耍演员表演，就雇用他们。

在把生产代码交给某人之前，先看看他们能否完成与实际工作相近的任务。1 小时的编程练习并不完美，但与讨论他们会如何处理一个假设问题相比，它的预测性要强得多。

对话中看不出来、但工作样本能体现的方面：

• 他们如何应对模糊情况（会提出澄清问题，还是自行假设？）
• 他们的代码是否易于阅读，而不只是能运行
• 他们如何回应对其工作的反馈（会表现得抵触，还是积极参与？）
• 无法面面俱到时，他们会优先处理什么

**对于资深候选人：**可以考虑让他们审查代码，而不是（或除了）编写代码。代码审查能以新写代码无法做到的方式展现判断力——它能体现他们是否能发现真正的问题、给出有用的反馈并进行技术沟通。

**对于实习转正招聘流程：**这是你掌握的最有力的招聘信号。发出录用通知前，你已经观察他们工作了数月。善用这些信息。

许多 EM 对结构化技术评估感到不自在（“感觉像在考试”），这种感受确实存在——但另一种做法，是仅凭一次愉快的交谈就做出价值 20 万美元以上的决定。杂耍演员的比喻有助于换个角度看待这件事：评估不是对个人的评判，而是对这个岗位上任何人都会采用的标准。

---

深入了解

如果用户询问某个框架的来源、想阅读原始文章，或想了解任何主题的更多背景，请阅读 references/sources.md，其中列出了完整的来源文章（含链接）和书籍。

---

相关技能

• em-context — 了解团队和岗位背景
• performance-reviews — 评估长期表现