标准提升者、招聘委员会和其他提高招聘质量的复杂方法。

作者.png

当 Uber Engineering 的工程师数量达到 800 名时，工程被分配给大约 5 名工程总监。大多数工程和流程问题都在这五个组织内本地解决。这在大多数情况下运作良好，但意味着我们的核心流程几乎没有一致性。招聘尤其分散，每个团队的经理都负责制定自己的面试、问题和结构。

然而，无论哪个团队最初聘请了一名工程师，几乎每个团队最终都与该工程师合作，随着时间的推移，一些团队对其他团队认为松懈的招聘标准越来越感到沮丧。最终，三位董事对第四位的招聘标准非常不满，他们成功地主张推出一个仿照亚马逊的“提高标准”计划。在该计划中，招聘组织之外至少有一名合格的面试官会对每个招聘人员进行权衡。从理论上讲，标准提高者是候选人是否可以收到报价的最终决定者，确保每个招聘人员至少满足两个组织的招聘标准。作为最初的提高标准推出的一员，我可以保证它解决了许多这些问题，尽管它很难处理那些升级任何与他们自己相矛盾的提高标准的决定的招聘经理。

当我后来加入 Stripe 时，我内化了一个关于提高标准的核心课程：除非他们有大量持续的、授权的组织支持，否则它们很容易被无声地颠覆。所以我拒绝引入提高标准，并很高兴支持建立招聘委员会。你不知道吗，招聘委员会会提出他们自己的一些挑战。

从这里开始：决定是否应该引入一个提高招聘质量的计划，运行一个提高标准的计划，运营招聘委员会，最后是我使用结构化审批的首选方法。

你应该优先考虑招聘质量吗？

运行一个成功的工程组织的一个重要部分是尽可能多地避免流程，但仅此而已。当您考虑是否需要提高招聘质量时，需要回答三个有用的问题：

您是否已经创建了结构化的招聘流程并培训了您的团队使用它？如果没有，请先这样做。
您是否普遍关注招聘质量，还是与少数人相关的狭隘问题？如果只是几个人，先引入一个绩效管理系统，然后用它来管理这些人。
在提升结构化招聘和绩效管理系统后，您是否仍然担心招聘质量？好吧，让我们介绍一个提高招聘质量的计划！

通常，您会发现这些流程在快速招聘期间最有价值，尤其是当许多招聘经理是您公司的新手时。如果您认为有必要在招聘人数较少或招聘经理任期较长的时期引入这些做法，我最初的猜测是您的团队中存在需要直接解决的绩效问题，而引入流程只是一种推迟处理该问题的形式。

提高酒吧

自从亚马逊推出了提高标准的计划以来，许多公司对其进行了调整和复制。如开篇所述，Uber 在 2015 年左右也采用了 bar raiser 计划，其运作方式如下：\

面试循环通常由每个团队的工程经理设计
但是，所有循环都必须包括作为面试官的提高标准的人。提高标准的人必须来自与循环的招聘工程经理不同的主管报告链
提高标准的人进行了他们选择的面试，而不是由循环的招聘工程经理分配的面试
选拔标准提升者是因为他们有很强的面试技巧、有专门在优步面试的经验证明，并得到了领导标准提升计划的团队的批准。在开始面试之前，调酒师经历了一个简短的培训计划

引入提高标准是对面试过程本身的一个简单改变，但仍然有意义地改变了优步的整体面试结果。最大的运营挑战有时是无形的，归结为解决标准提出者、招聘经理和招聘经理的报告链之间的冲突。如果没有高管赞助来支持提高标准的决定，该角色的影响很容易被招聘经理的报告链的频繁否决所破坏。

优点

去中心化，随着访谈次数的增加而有效地扩展
通过引入额外的批准步骤来避免减慢流程
任何给定的面试循环都有多个潜在的标准提升者，这意味着即使有一定比例的标准提升者校准不佳，招聘质量仍然相对较高

缺点

容易受到招聘管理链上压倒一切的升级影响，从而削弱提高标准的影响力和士气
鉴于工作在晋升过程中通常不被重视
分散的日常运营会给执行发起人带来模糊的角色，这通常会转化为脱离参与而不是负责任的发起人

检查问题

你们的报价延期和报价接受率是多少？
提高标准的人多久改变一次面试的结果？
你有多少个提高标准的人？
在过去的一个季度中，您增加/失去了多少个提高标准的人？
提高酒吧的人的面试负担是多少？
执行发起人如何知道结构是否需要调整？

招聘委员会

到 2016 年，Stripe 的工程招聘遵循“池招聘”模式：候选人进入流程，接受工程师和来自整个组织的一名经理的面试，然后经理和招聘人员将反馈讨论综合成招聘决定在面试汇报期间（由于历史原因，候选人汇报会议在内部被称为“比喻”）。 “联合招聘”是指参与招聘的面试官，包括经理，通常不是来自候选人可能加入的团队。

当我们开始招聘更多资深候选人时，我们不再采用联合招聘，因为资深候选人对了解他们将加入的团队有更高的期望。作为一名经理，向候选人推荐一个你只是模糊了解的团队也是非常棘手的。候选人通常最终会想要加入面试经理的团队，而不是员工人数的最佳目的地。

从集体招聘到团队特定招聘的转变也带来了一些挑战，尤其是招聘过程中的一致性损失。当同一个团队和同一个经理为其团队的所有角色进行面试时，您开始看到团队的招聘流程出现分歧。为了解决这种分歧，我们引入了一个招聘委员会，我相信在 2018 年的某个时候，公司大约有 800 名工程师。

招聘委员会流程的一个版本如下（我说“一个版本”是因为随着时间的推移细节发生了很大变化，尽管核心保持相当稳定）：

候选人面试特定团队的角色，并由他们将与之合作的团队和招聘经理进行面试
招聘经理做出初步的招聘决定，并为招聘委员会撰写招聘建议
招聘委员会将每隔一天在 30 分钟的常设会议上审查招聘建议，并批准/拒绝/将其发送回招聘经理以获取更多详细信息
招聘人员和招聘经理将协调后续步骤（推销候选人，将他们送回招聘委员会，或告知他们不会继续前进）

这个过程对我们来说效果很好，尽管一些经理对它使招聘过程减慢了一到两天感到沮丧（如果招聘经理准备招聘提案的速度有时会更长）。它还定期受到加入招聘委员会的校准不佳的成员的挑战，这需要持续关注来解决。

优点

由于委员会成员人数较少，招聘决策的一致性更高
招聘委员会成员快速相互学习和校准
生成集中、干净的数据源以改善组织招聘

缺点

在招聘过程中引入至少 1-2 天的额外延迟
委员会成员的大量时间负担，可能不被视为具有高影响力的工作
招聘结果受到不成比例的影响，只有少数错误校准的委员会成员

检查问题

你们的报价延期和报价接受率是多少？
招聘建议被批准/拒绝的速度有多快？
有多少百分比的招聘建议被批准、拒绝或退回以获取更多信息？
经理编写被拒绝或返回以获取更多信息的数据包的任期是什么？
是否有经理的建议总是被批准？您能否简化流程以加快这一进程？
是否有经理的提议很少被批准？你能为这些经理提供更好的教育和培训吗？
执行发起人如何知道结构是否需要调整？

结构化审批

很容易争辩说，每个招聘过程都应该对每个步骤都有明确的责任方，但我的生活经验是，许多招聘过程是模棱两可的、不确定的和不清楚的——解决这个问题比推出招聘委员会或提高标准要容易得多。我已经看到一个结构良好的招聘流程以及明确的责任方取得了巨大的成功，我将其标记为结构化批准。

我们在 Calm 工程中通常如何运行此过程是：

招聘人员负责采购，决定推进到现场，安排面试
招聘经理在收集有关候选人表现的反馈并主持招聘汇报后，做出初步决定向候选人提供报价
招聘人员在招聘经理和工程主管之间的报告链中创建了一个私人 Slack 渠道，包括招聘经理、招聘经理、工程主管和经理（如果有）
招聘经理写了一页的报价理由，并在私人 Slack 频道中分享
Recruiter根据薪酬范围提出初步薪酬建议，并分享Slack频道
工程主管有 24 个工作小时来审查和批准要约和薪酬建议。如果他们错过了窗口，则默认情况下会批准报价和提案。他们可以将任一组件送回进行第二次迭代，以收集更多反馈或修改报价。批准和协调在 Slack 通道内完成
招聘人员扩展报价，协调关闭，并在最终结果上存档 Slack 频道
工程主管每周与工程招聘主管会面，以调试招聘流程并解决出现的任何具体问题

在每个阶段，我们都有一个明确的责任方，Slack 渠道为与给定候选人相关的人员创建了对流程的可见性，我们经常会面以调试和改进底层的结构化流程。这并不是说这个特定的过程对你来说是理想的，这会因你的团队、招聘率等而有所不同。但是，我确信此流程的某个版本将有效地为您工作，即使规模很大（例如，很容易想象一个过渡点，之后只有 Staff-plus 和 Director-plus 提供升级到工程主管，而其他报价可以更接近招聘团队）。

优点

协调成本低
避免多方分散问责
执行发起人的角色清晰、明确、失败

缺点

没有固有的质量控制机制，结果完全取决于所涉及的个人
许多特定的结构很慢，通常会导致招聘延迟 1 天以上
需要注意避免退化为以异常为中心的方法

检查问题

你们的报价延期和报价接受率是多少？
新经理和招聘人员需要多长时间才能加快流程？
审批需要多长时间？钻研，哪些环节审批慢？他们对每个人来说都很慢，还是只是人们在加速？
调整薪酬建议需要多少轮来回？
执行发起人如何知道结构是否需要调整？