16 KiB
10 | 决策会开展（上）：怎样引导争辩，达成共识？
你好，我是四火。
今天这一讲，我们来聊聊技术面试后的决策会。决策会，就是大家碰头商讨候选人情况，达成面试共识的过程。显然，这在一定程度上将决定，公司和团队是否愿意接纳候选人，也就是说，候选人是否能得到相应的工作机会，其重要性不言而喻。
“开会”这个事儿是技术团队的长期热门词汇，无论你是否喜欢，在很多情况下，它是一种群聚的同步交流方式，目前并没有更好的方式可以替代开会。
今天我们要讨论的情况便是如此，候选人经过了技术面试，怎样给出最终的评估结论？大多数的情况，还得靠开会。
其实这个给出结论的过程，一般有两种形式：
- 第一种，是一个特殊角色的人（这个人一般是级别较高的管理者），收集了面试后各位面试官的评价，然后独立决定；
- 第二种，是面试团队坐到一起，以会议的形式讨论并达成共识，共同决定。这个会议，有很多叫法，我们在这里把它简单称作“决策会”（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说：
我让候选人将一棵二叉树序列化成字符串，他和我很简单地沟通了一下，就开始介绍该怎样实现了，但我们并没有讨论清楚序列化的具体要求是什么。
虽然两位面试官说的明显是两件不同的事，但这里隐约暴露出了一个模式，也就是同一个问题：候选人在工作的时候，很让人担心他能不能做到充分的沟通：
- 做了一个不需要的功能，这不是技术问题，更像是缺乏充分的沟通；
- 没有讨论清楚需求就开始设计和实现，这也反映了缺乏充分的沟通。
作为Bartender，就是要领着大家，从茫茫反馈的数据中，挖掘出这些模式来。模式所体现的优势，或是暴露的问题，要比单一的数据点要有说服力得多。
**因为单一的数据点偶然性很大，兴许候选人可能就是单纯地没做好，但模式经过了超过一个支撑事实，或是不止一名面试官的验证，就可信得多。**这有点像医生看病时，结合化验报告和症状等多项“证据”，给出诊断。
**接着，汇总建议，收敛分歧，达成共识。**经过Bartender引导的分析讨论，有些面试官提到的担忧，可能不是问题；有些提到的优势或不足，可能事实支撑并不构成较强的“模式”；而还有些优缺点，则会得到验证。
经过这样逻辑清晰的分析，很多情况下面试官会调整或者改变原先观点，大家逐步达成一个“共识”，这个共识就是前面提到的决策会需要产出的面试结果——综合来看，候选人有哪些优势和不足，他是不是通过了面试，大家对他认可的级别又是什么。而Bartender，这时可以归纳总结一下，并给出自己的建议。
当然，这个从争辩到共识的过程并不好做，而且它非常考验Bartender对于对话组织和内容概括的功力，我们将在下一讲介绍这方面的许多技巧。
对于共识的达成，通常有三种结果：
1.最终如果大家能够达成共识，那最好不过，这也是大多数的情况；
2.如果招聘经理和Bartender和多数其它面试官达成了共识，但个别面试官依然不认可，但这个不认可的程度较弱，那么我们依然可以采纳这个不完全的“共识”作为结果，但保留个人意见，完成决策会的输出；
3.但如果招聘经理和Bartender都无法达成一致，或是大家分歧比较大，这就可能需要依赖于外部资源了，不同公司和团队处理方法不同。比方说，某些公司中，这种无法达成一致的情况，就表示面试不通过，简单直接；还有一些公司，有一个独立的“招聘委员会”，它由一些经验丰富的面试官等人组成，他们会根据所有的面试反馈，以及Bartender提交的面试会记录等材料，做出进一步的裁决。
最后，无论是上面的哪一种情况，Bartender需要简单陈述一下结果，确保整体决策的逻辑清晰合理。
总结与思考
今天我给你介绍了面试后决策会的大致流程，包括其中都有哪些典型误区，对它的把控又有哪些步骤。
就像我前面所说，Bartender作为面试官中的一个特殊角色，决策会的流程把控其实非常考验他的对话组织和内容概括的功力，这需要在实践中反复练习以及经验的积累。
这个环节一旦做不好，由于观点碰撞和意见分歧，决策会就很可能变成乱糟糟的“吵架”大会。
今天的内容就是这些，我在最后留一个小问题吧：你作为面试官在面试后，是怎样做出通过或不通过的结论呢？能否在留言区和我分享一下呢？
好，我是四火，我们下一讲见！