你好，我是四火。

今天这一讲，我们来聊聊技术面试后的决策会。决策会，就是大家碰头商讨候选人情况，达成面试共识的过程。显然，这在一定程度上将决定，公司和团队是否愿意接纳候选人，也就是说，候选人是否能得到相应的工作机会，其重要性不言而喻。

“开会”这个事儿是技术团队的长期热门词汇，无论你是否喜欢，在很多情况下，它是一种群聚的同步交流方式，目前并没有更好的方式可以替代开会。

今天我们要讨论的情况便是如此，候选人经过了技术面试，怎样给出最终的评估结论？大多数的情况，还得靠开会。

其实这个给出结论的过程，一般有两种形式：

  1. 第一种，是一个特殊角色的人（这个人一般是级别较高的管理者），收集了面试后各位面试官的评价，然后独立决定；
  2. 第二种，是面试团队坐到一起，以会议的形式讨论并达成共识，共同决定。这个会议，有很多叫法，我们在这里把它简单称作“决策会”（Debrief）。

通常来说，对于普通的软件工程师面试，第二种，也就是决策会的形式，更为多见，我也更为推荐。因为相较于第一种，它也保证了更高的参与度，团队内部保持公开透明，更能真正做到让团队为团队自己选人，而这一讲的讨论也是针对这一种方式展开的。

典型的误区

决策会的误区其实还是非常多的，我们来讲最典型的几个，看看有没有你熟悉的。

把决策行为变成了民主选举

对面试结果的决策变成了民主选举，无论是简单粗暴的直接投票，还是共识无法达成索性强行投票，本质上都是一个“少数人服从多数人”的逻辑，这看似很公平，其实恰恰相反。关于这一点，我觉得可以从这样两个角度去理解：

1. 评估一个面试决策，**更具意义的衡量标准是，它背后的逻辑是不是合理，而非人数是不是占优。**我们平时说的“以理服人”，其实说的就是这件事情。

2. 在某些情况下，面试官其实对于自己的选择也并不坚定、或者思考并不成熟，需要引导、需要讨论，而民主投票在一定程度上，直接粗暴地“绕过”了这个过程。比如说，面试官有他的观察，也有他的数据，但是如同在第 9 讲中提到的那样，它不够深入，或是不能较为准确地剖析和认识它所代表的意义。

Bartender（技术负责人）应该在这样的面试决策会上，根据已明确的事实和数据，针对所有在会上的讨论内容综合分析以后，引导面试官做出合理的决策，达成基于团队的共识。

由于这个问题太过常见，我见过一些决策会中，虽说 Bartender 都明白这个道理，还是会不知不觉地犯下“民主选举”的错误，特别是在争辩较为激烈的情况下，为了收场，在很多分歧还没有得到解决，很多疑点还没有澄清的情况下，选择了投票选举这种简单粗暴的办法。

因此，我要再一次强调，面试结果的决策，不是民主选举。

过于倚重招聘经理的意见

招聘经理的话语权重过大，这个问题也非常常见。特别是某一些团队中，工程师资历比较浅，他们有时会无意识地倾向于经理的观点，因为在平时工作中，招聘经理就是他们的主管，有时候即便有不同的看法，自己也不一定在决策会上提出来，或者即便有足够的理由，也不能够坚持自己的看法，据理力争。

因此，Bartender 的协调作用就非常大了，他需要站出来，帮助团队识别出具体的事实数据，而不是单纯的具有倾向性的观点。在这一讲的后面，以及下一讲我还会介绍一些技巧，尽量减轻这个问题可能带来的影响。

缺乏事实依托

缺乏事实依托，其实在上一讲也谈到了这个误区。在收集和整理对候选人的反馈时，需要有事实依据，在决策会的讨论中，凡是抛出对于候选人评估的观点一旦需要求证，要能拿得出事实数据来。

举例来说，有的面试官讲，他注意到候选人并不能听取和接纳他人的意见，那么，要是有人要求他拿出事实数据，来解释为什么给出这样的观点，如果他没法说出来，或者只能说“不太记得了，就这个印象确实很深”，这样的观点逻辑就不成立。

但是，如果这位面试官确实拿出了一条数据呢？

比如说，候选人在一个算法问题的求解上陷入了挣扎，他原本的回溯法思路走不通，于是面试官提示候选人另外一种排列组合的思路，候选人听到了，但是却选择了忽略建议，继续在他原有的思路方法上挣扎。

有了这样的事实数据，我们是否就能认定候选人“不能听取和接纳他人意见”呢？我认为，单单凭此还是不能的，至于原因，我先卖个关子，我在后面会告诉你为什么。

不合理的决策因素影响

有一些事实不应该影响到决策，但正所谓“旁观者清，当局者迷”，在决策会上，其实经常会看到一些不合理的决策因素。

比方说，我经历过一场决策会，本来大家对结果达成一致了，认为候选人通过了面试，并且也确定了级别。

结果会后，招聘经理突然把大家召集到一起，说我们能不能把给候选人的级别增加一级，因为他已经从别的公司得到了一份 offer，原有级别的 offer 无法说服他来我们公司。

我认为，这个试图改变决策的初衷就是不合理的，因为候选人有没有其它 offer 既不属于候选人过去的经验、履历，也和候选人当时的面试表现无关，那么这样的因素就不应当影响面试结果的决策。

流程把控

好，介绍完典型的误区以后，我再从 Bartender 的视角介绍一下，作为面试官，我们对于决策会应该有一个怎样的预期，又应该怎样把控整个决策会的进程。

整体认识

一般绝大多数的决策会都可以在 30 分钟完成，并且是由 Bartender 主持的。少数情况，譬如候选人的情况比较复杂，或是争议较大，达成一致较为困难，我们就需要延长时间。

从参与的人员上看，所有现场面试的面试官都应该参加决策会，而之前电话面试的面试官，可以不参加。有时，负责招聘的同事（recruiter），也会参加，一般不发表看法，而是倾听，了解这位候选人的情况。

如果有个别面试官由于个人情况无法参会，只要提交了清晰的面试反馈，这也没关系，不影响会议进行，但是，如果 Bartender 或是招聘经理无法参会，那么这个会就必须要延期。这是因为，这两个角色在整个面试团队中比较重要，而且相互制衡（具体原因请参见第 2 讲），缺乏任何一方都无法保证决策会的全面、客观、公正。

从输入上看，我们要求所有面试官都将完成的面试反馈，交给招聘经理和 Bartender，这是会议高效的保证，当然，如果存在没有提交的情况，虽不理想，但也不应成为会议进行的阻碍，具体的反馈内容可以在会上详述。

从输出上看，最重要的就是得出面试结果，包括两点，首先是面试是否通过；其次，如果通过的话，面试团队为候选人裁定的角色级别是什么。

具体形式上，不同公司会有不同要求，很多公司都有内部的一个管理招聘流程的网站，有了结果后就需要更新上面的信息。

好，在整体上有了感观认识，下面我来介绍一下决策会的几个重点环节。这些环节可能在不同公司和团队中有所差异，我所介绍的实践方案，是在我看来比较推荐的一种。

第一环节：初始投票

会议开始以后，Bartender 会介绍一下候选人的姓名和目标职位、默认的目标职位级别。然后，大家开始投票，投票内容其实就是一个事儿：对候选人的推荐程度，例如 Hire / Weak Hire / Weak No Hire / No Hire（具体介绍你可以参见第 9 讲）。

具体操作上，把握一个原则，尽量让大家不要互相影响，而是完全凭借自己的判断给出结果。如果非疫情期间，大家都坐在会议室里，那么一种推荐的方法是，Bartender 数 1、2、3，然后大家一起伸出大拇指，Hire 就垂直朝上，Weak Hire 就 45 度角朝上，Weak No Hire 就 45 度角朝下，No Hire 就垂直朝下。

其中的原因我想也很容易理解，比方说，如果招聘经理先表态，而招聘经理往往也是团队的经理，其它面试官也很可能平时就是汇报给他的，那么某些面试官就更容易受到经理表态的影响。

需要说明的是，这一轮投票让大家先开门见山地亮出自己简要的结论，而并非据此直接裁定决策会的结果，并且我们在第二环节中会再展开陈述反馈，即“先摆明态度，再慢慢解释”。

经过实践的验证，这是一种比较好的方式，有助于每个面试官独立地表达和明确自己的观点，并且能让每一位与会者快速参与，进入思考与讨论的状态。

第二环节：反馈陈述

第一环节很简单，一般一两分钟就结束了，下面进入具体陈述反馈的第二环节，它的花费时间一般可以比较长，但也请尽量保留至少 10 分钟的时间给第三环节。

具体操作的方法是，在 Bartender 的提示下，所有面试官依次来介绍他那一轮的面试简况，面试的重点和内容大致是什么，候选人的优势和不足是什么，也就是说，给出第一环节的那个投票，你的逻辑是什么。叙述顺序还是一样的——普通面试官、招聘经理、Bartender。

在反馈陈述方面，Bartender 需要控场，主要抓住这样几个要点：

**陈述时间控制。**可以先提示一下，也可以在陈述的过程中判断，如果发现陈述过于细致具体，那么就要提醒一下，我们的目标是给其他人，以及第三环节保留一定的时间。

**事实支撑的鉴别。**对于主要的观点，如果发现只有观点陈述而没有事实依托，需要立即追问，确保对方谈到的事实和观点是匹配的。

**主要内容的速记。**这一步很重要，我在上一讲也已经谈到了，把诸位面试官的判断中，几个关键词记录下来，在第三环节需要纵览这些反馈，获得一个比较清晰的认识，如果不动笔而单纯靠记忆力，是比较困难的。

第三环节：争辩开展与共识达成

接着是第三环节，首先，Bartender 可以简单地帮大家回顾一下前两个环节的情况，比如说：

一共 3 票 Hire，两票 No Hire；两轮覆盖了 coding，两轮覆盖了系统设计，还有一轮综合考察。

不要小看这一步，除了可以帮助大家强化一下这个基本印象，还能够识别一些面试程序上明显的问题。

比如说，如果软件工程师候选人没有人进行代码面试，这就是一个覆盖面的硬伤。如果真的遇到这种情况，也别担心。对于这样硬伤的处理，我在下文中会谈到。

**然后，寻找反馈的模式（pattern），和大家一起讨论。**这里所说的“模式”，指的就是对候选人出现一次以上的相似评价，或者是体现出的相同问题。我来举个例子：

面试官 A 说：

候选人谈到他做 xxx 项目的时候，周末加班把它完成了，但是下周一的时候，他主管说他做的其中一个主要功能并不是需要的。

面试官 B 说：

我让候选人将一棵二叉树序列化成字符串，他和我很简单地沟通了一下，就开始介绍该怎样实现了，但我们并没有讨论清楚序列化的具体要求是什么。

虽然两位面试官说的明显是两件不同的事，但这里隐约暴露出了一个模式，也就是同一个问题：候选人在工作的时候，很让人担心他能不能做到充分的沟通：

  1. 做了一个不需要的功能，这不是技术问题，更像是缺乏充分的沟通；
  2. 没有讨论清楚需求就开始设计和实现，这也反映了缺乏充分的沟通。

作为 Bartender，就是要领着大家，从茫茫反馈的数据中，挖掘出这些模式来。模式所体现的优势，或是暴露的问题，要比单一的数据点要有说服力得多。

**因为单一的数据点偶然性很大，兴许候选人可能就是单纯地没做好，但模式经过了超过一个支撑事实，或是不止一名面试官的验证，就可信得多。**这有点像医生看病时，结合化验报告和症状等多项“证据”，给出诊断。

**接着，汇总建议，收敛分歧，达成共识。**经过 Bartender 引导的分析讨论，有些面试官提到的担忧，可能不是问题；有些提到的优势或不足，可能事实支撑并不构成较强的“模式”；而还有些优缺点，则会得到验证。

经过这样逻辑清晰的分析，很多情况下面试官会调整或者改变原先观点，大家逐步达成一个“共识”，这个共识就是前面提到的决策会需要产出的面试结果——综合来看，候选人有哪些优势和不足，他是不是通过了面试，大家对他认可的级别又是什么。而 Bartender，这时可以归纳总结一下，并给出自己的建议。

当然，这个从争辩到共识的过程并不好做，而且它非常考验 Bartender 对于对话组织和内容概括的功力，我们将在下一讲介绍这方面的许多技巧。

对于共识的达成，通常有三种结果：

1. 最终如果大家能够达成共识，那最好不过，这也是大多数的情况；

2. 如果招聘经理和 Bartender 和多数其它面试官达成了共识，但个别面试官依然不认可，但这个不认可的程度较弱，那么我们依然可以采纳这个不完全的“共识”作为结果，但保留个人意见，完成决策会的输出；

3. 但如果招聘经理和 Bartender 都无法达成一致，或是大家分歧比较大，这就可能需要依赖于外部资源了，不同公司和团队处理方法不同。比方说，某些公司中，这种无法达成一致的情况，就表示面试不通过，简单直接；还有一些公司，有一个独立的“招聘委员会”，它由一些经验丰富的面试官等人组成，他们会根据所有的面试反馈，以及 Bartender 提交的面试会记录等材料，做出进一步的裁决。

最后，无论是上面的哪一种情况，Bartender 需要简单陈述一下结果，确保整体决策的逻辑清晰合理。

总结与思考

今天我给你介绍了面试后决策会的大致流程，包括其中都有哪些典型误区，对它的把控又有哪些步骤。

就像我前面所说，Bartender 作为面试官中的一个特殊角色，决策会的流程把控其实非常考验他的对话组织和内容概括的功力，这需要在实践中反复练习以及经验的积累。

这个环节一旦做不好，由于观点碰撞和意见分歧，决策会就很可能变成乱糟糟的“吵架”大会。

今天的内容就是这些，我在最后留一个小问题吧：你作为面试官在面试后，是怎样做出通过或不通过的结论呢？能否在留言区和我分享一下呢？

好，我是四火，我们下一讲见！