|
|
# 11 | 决策会开展（下）：怎样确保评估全面且有深度？
|
|
|
|
|
|
你好，我是四火。
|
|
|
|
|
|
上一讲，我们介绍了决策会流程的整体把控，包括大体有怎样的过程，期望从这个会议得到怎样的结果。
|
|
|
|
|
|
但你可能也注意到了，在这短短的半个小时里，剖析事实、总结模式、管理争论、收敛分歧，并最终引导得出共识结论，这些步骤对Bartender的要求还是非常高的。
|
|
|
|
|
|
那么这一讲，我会进一步为你阐述，决策会中这些步骤的实用操作技巧。
|
|
|
|
|
|
你可以回想一下上一讲我们介绍的决策会流程，根据流程的划分，这些操作技巧可以分为两个方面，分别是剖析事实和总结模式，以及管理争论和收敛分歧。
|
|
|
|
|
|
## 剖析事实和总结模式的操作技巧
|
|
|
|
|
|
### 避免对事实的简单罗列
|
|
|
|
|
|
“事实数据的简单堆积”，这个问题并不少见，一些经验比较少的面试官常常容易走入这个误区。
|
|
|
|
|
|
我们经常说，对候选人面试的反馈，不能只讲观点，而没有事实数据的佐证；可是，反过来也一样，有时候全是事实数据，缺乏观点，这也是不行的。
|
|
|
|
|
|
比如说，某位面试官在决策会上，谈论了他问了候选人什么问题，候选人是怎样澄清问题的，他们是怎样分析问题的，接着又是怎样讨论解决思路的，等等，洋洋洒洒一大堆，很花时间不说，还很难让人抓住主要的观点。
|
|
|
|
|
|
这种情况下，Bartender应当介入，**要求把这个观点和事实陈述的顺序反过来**：问面试官，“你觉得候选人最大的几个优势是什么，不足又是什么？”
|
|
|
|
|
|
这样一来，面试官自然而然就会思考并抛出“观点”。根据提到的优势或者不足，Bartender可以再进一步要求面试官提供佐证的事实数据，而那些相对不重要的陈述呢，就被略过了。
|
|
|
|
|
|
你看，这种方式下，面试官就不会把或大或小的过程细节全部叙述出来了，而是谈论最重要的部分，因此，这个过程中Bartender的引导作用举足轻重。
|
|
|
|
|
|
### 合理采纳推荐人的意见
|
|
|
|
|
|
我记得在我刚工作那会儿，身边朋友们，也包括我自己，主要的求职方式，还是去各大招聘网站投简历；十多年过去了，这事儿已经发生了巨大的变化，现在我很多的朋友找工作都用LinkedIn，等待猎头联系，或是点对点地找到目标公司内的朋友来推荐。
|
|
|
|
|
|
据负责招聘的同事说，总体来说推荐来的候选人，通常要靠谱得多。
|
|
|
|
|
|
如今很多互联网公司，对于“推荐”，甚至“强力推荐”的候选人，都有一些流程上的“福利”，比如，可以简化，甚至跳过电话面试，可以直接对接目标团队，而一旦候选人通过了面试并入职，目标公司内的推荐人还可以拿到一笔丰厚的推荐奖励等等。
|
|
|
|
|
|
从面试官的角度看，如果候选人是经过推荐而来参加面试的，那么在同一家公司的推荐人就很可能提供额外的考察数据。在具体操作上，我们应该怎样采纳推荐人意见呢？
|
|
|
|
|
|
**首先，在决策会之前，流程上没有什么不同**，我们不要安排整个面试团队去和推荐人详谈，这是为了尽量保证面试过程客观，避免详谈可能带来的潜在倾向性。
|
|
|
|
|
|
**其次，在决策会上，我们可以收集推荐人的推荐陈述，但是它只能作为参考，主要的决策依据，依然是不变的。**对于这一点，在具体操作上，该怎样做呢？我把我的做法列在下面供你参考：
|
|
|
|
|
|
决策会一开始，或者在第一环节的初始投票（如果你忘记了，请回看上一讲）前，请推荐人发言，Bartender要问清楚这样三件事：
|
|
|
|
|
|
1.推荐人在公司和团队中的职位角色，**他和候选人的工作关系，以及推荐的程度。**一起工作了多长时间，有多了解候选人？这一点很重要，有些时候这个推荐关系只是因为他们认识，或者是因为有一个共同好友而已；而有时候基于过去长时间共同工作的经历，他很了解并认可候选人。
|
|
|
|
|
|
2.候选人有哪些优秀的素质，可以为公司和团队带来价值？这是属于推荐的“常规”内容了。
|
|
|
|
|
|
3.还有没有需要面试团队知道的，候选人有关工作的重要情况？
|
|
|
|
|
|
需要说明的是，如果客观条件上推荐人不方便参会，那在会前由Bartender收集上面这些信息也是可以的。
|
|
|
|
|
|
你可能会问，我们都说要讨论正反两面，这里只要求谈论“优秀的素质”，是否不够客观？其实，我们当然可以请推荐人谈论候选人的不足，但是据我的经验，这个操作基本行不通。
|
|
|
|
|
|
具体说，就是很多情况下，特别是推荐人是候选人的好朋友时，他并不愿意在公开场合谈论候选人的不足，即便谈论，也是随便找一点内容搪塞过去。那既然如此，我们何必追问，搞得彼此很尴尬呢？
|
|
|
|
|
|
**再次，在推荐人的陈述完毕后，我们请他离开决策会。**
|
|
|
|
|
|
对，你没有看错，我们不希望他参加决策会的主体部分，不希望他了解投票和决策的过程，因此那样也就避免了潜在的尴尬。而且，对于所有的面试官来说，也可以继续常规的决策会流程，而不用把心思放到顾忌推荐人的感受上。
|
|
|
|
|
|
需要强调的是，推荐陈述对丰富反馈数据很有帮助，但从这个陈述的重要性来看，它不能超越我们的面试反馈。面试官还是要继续相信自己的观察和收集到的数据，决策流程不应该因此有什么大的改变。
|
|
|
|
|
|
**最后，推荐人依然是一个可供确认候选人具体情况的资源**，在一些特殊情况下，比如对于个别的观察有所担忧，因而面试官摇摆不定，那我们可以就单个具体问题询问推荐人，以获得更多信息。
|
|
|
|
|
|
### 妥善处理考察项覆盖的缺失
|
|
|
|
|
|
首先，大家都应该清楚，对于有面试计划的情况，这种情况其实是不应该出现的。但是一旦出现了，也不要抱怨，而应继续这个决策会，根据当前的讨论结果决定下一步的策略。
|
|
|
|
|
|
举例来说，如果在决策会的时候，我们注意到，原计划希望面试覆盖2~3轮编码，但是结果该候选人的考察只覆盖了一轮，因此我们就认为这一系列面试缺少了编码能力的考察数据：
|
|
|
|
|
|
* 如果候选人在该面试系列中表现不错，并且在所覆盖的那轮编码考察中表现出色，那么虽然数据有所欠缺，我们还是可以认为候选人编码能力是过关的，因此面试的最终结果为：通过。
|
|
|
* 如果候选人在该面试系列中表现不佳，没能通过，那就没有必要继续考虑编码的覆盖情况了，最终结果就是：不通过。
|
|
|
* 如果候选人在该面试系列中表现总体不错，但是在那一轮编码考察中问题却不少，这就是比较纠结的一种情况了。这时可以考虑调取电话面试中代码考察的数据，如果还是不好判断，又不愿意错过候选人，可以考虑额外增加一轮代码考察。
|
|
|
|
|
|
你看，就是这样，我们有时候得到的数据不够完美，但是就像用软件来解决复杂的实际问题一样，我们就是要能够应对这样不完美的情况。
|
|
|
|
|
|
我这里想补充一点，你也许会问，那一旦遇到考察覆盖不全的情况，加面一轮不就行了吗？事实上，由于它会明显消耗候选人和面试官双方的时间和精力，**我们只有在没有更好的办法时，才会这么做。**
|
|
|
|
|
|
最后，在这种情况发生以后，Bartender和招聘经理需要从中吸取教训，在未来的面试安排中做得更好，尽量避免这样的情况再次发生。
|
|
|
|
|
|
## 管理争论和收敛分歧的操作技巧
|
|
|
|
|
|
### 处理面试官态度摇摆不定的情况
|
|
|
|
|
|
就像软件领域的二八定律一样，面试决策会也是，80%的会议都很明确，大家的观点也很可能一边倒，很容易达成共识。但是剩下那20%，则可能出现各种“纠结”的状态。
|
|
|
|
|
|
比方说，一种常见的情况，就是候选人优缺点并存，长项和短处都很明显，而很多面试官虽然有观点，但不坚定，或者说“自己也说不清楚”。
|
|
|
|
|
|
这时候，Bartender的价值就体现出来了，可以积极介入，对事实数据进行分析和引导，而这些事实数据，恰恰都是这些摇摆不定的面试官自己得到的。
|
|
|
|
|
|
除此以外，在这里我还可以给你分享一个小技巧，就是**把“从事实推定结论”，转换为“从结论思考事实”。**比方说，某位面试官纠结于候选人过强的个性，听不进建议的做事风格，是否最终可能给团队带来弊大于利的影响，那么，Bartender可以快速地问他这样两个问题——如果候选人加入了团队：
|
|
|
|
|
|
* 你觉得他是否能够很好地融入团队？
|
|
|
* 你是否愿意和他在工作中相处和合作？
|
|
|
|
|
|
**前一个问题其实针对的是团队中的“其他同事”，而后一个问题针对的就是面试官“自己”了。**两个问题都是为了得到面试官对候选人的团队契合度判断。
|
|
|
|
|
|
先回答，再反过来想“为什么”这么说，如果最终能够通过这个结合实际数据的“为什么”来佐证，那就是有效的观点，但必须明确的是，用“为什么”来佐证这一点必不可少，否则就真的变成主观臆断了。
|
|
|
|
|
|
通过这样的方式，其实是让你的“下意识”帮助你给出更准确的判断。
|
|
|
|
|
|
不要小看这一点，人的“下意识”其实是一种很强大的工具，很多事情的判断其实是有明确理由的，只是有时候我们自己并不清楚而已，因此我们需要一点技巧把它梳理出来。
|
|
|
|
|
|
### 引导对候选人的定级
|
|
|
|
|
|
作为决策会输出的一部分，面试团队需要给出一个明确的建议级别。虽说根据某些公司的流程，实际offer上写着的级别，未必完全由这一步确定，但面试团队经过了相当系统的面试和评估，其建议级别无疑具有举足轻重的作用。
|
|
|
|
|
|
级别怎样确定？我觉得你大致可以从这两个部分来考虑：
|
|
|
|
|
|
1. **候选人的背景和经验。**
|
|
|
2. **候选人的面试表现。**
|
|
|
|
|
|
前者，包括候选人的工作年限、在行业的影响力，已经做出的得到认可的成就等等。这听起来似乎理所当然，但是我注意到一些技术面试流程从一开始，对候选人设置的“默认级别”或者“期望级别”就是不合理的。
|
|
|
|
|
|
从决策会的角度说，根据候选人的面试表现，最终给出的推荐级别有可能会基于默认级别，有一定的上下浮动，但通常不会有较大出入。
|
|
|
|
|
|
因此，如果一开始大家都认可的期望级别设置出现了很大偏差，那么后面的流程就很难把它掰回来了。
|
|
|
|
|
|
以某公司为例，软件工程师的技术级别“初级工程师”一般工作经验不超过3年，而“高级工程师”为5到10年。那么，对于一名有着7年软件工程师工作经验的候选人来说，如果他去面试初级工程师，这个方向从一开始就是不合理的。
|
|
|
|
|
|
请让我进一步解释这一点。从初级工程师到高级工程师，这不仅仅对能力和经验方面要求更高了，还可以说，对他期望也是体现在不同的方面了。回想一下[第2讲](https://time.geekbang.org/column/article/360268)，我们已经谈到，对于初级工程师，我们更看重的是潜力；而对于经验丰富的工程师来说，我们更看重的是能力——这就是区别。
|
|
|
|
|
|
举例来说，对于初级工程师，我们更关心兴趣、热情、学习能力，以及是不是具备能够接纳意见等“潜力素质”，这些都是很难学到的、教不来的东西，而弱化了他立即独当一面，来工作和产出的能力。
|
|
|
|
|
|
但是，如果这位候选人已经有很多年的经验，或者说，无论基础的积累，还是做事的方法，都已经“成熟”了，那么我们就希望他已经能带领团队、快速产出了，招他的目的，自然就不是为了他的“潜力”。
|
|
|
|
|
|
**也就是说，如果这样的“沙场老兵”候选人达不到高级工程师的要求，却满足了初级工程师的bar，我们可以“降级”，给他一个初级工程师的offer吗？显然是不能的。**
|
|
|
|
|
|
另外，对于工作年限，我想再做一个说明。工作经验，从量的数据来看，确实是和工作年限成正相关的。但是，放到个体上，这并不是绝对的。
|
|
|
|
|
|
举例来说，一个在互联网前沿领域，每天做着有挑战性工作的工程师，有了三年的工作经验；和一个在传统产业，每天机械地做着重复性的工作，也工作了三年，他们作为软件工程师所积累的“经验”，可能有着很大的差别。
|
|
|
|
|
|
## 总结与思考
|
|
|
|
|
|
今天我给你分享了一些操作技巧，帮助你在决策会中剖析事实、总结模式、管理争论、收敛分歧，并最终引导得出共识结论。不知道你是否有所收获呢？
|
|
|
|
|
|
|
|
|
|
|
|
在最后，我想给你留一个问题。假如说，决策会上，大家第一环节的初始投票时，就已经表达了非常一致的态度，比如说，所有人都是No Hire，那么，你觉得这个决策会还有必要继续进行下去吗？还是说，直接给出一个共识结论——“不通过”就可以了呢？欢迎在留言区讨论。
|
|
|
|
|
|
好，我是四火，我们下一讲见。
|
|
|
|