你好,我是四火。

上一讲,我们介绍了决策会流程的整体把控,包括大体有怎样的过程,期望从这个会议得到怎样的结果。

但你可能也注意到了,在这短短的半个小时里,剖析事实、总结模式、管理争论、收敛分歧,并最终引导得出共识结论,这些步骤对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讲,我们已经谈到,对于初级工程师,我们更看重的是潜力;而对于经验丰富的工程师来说,我们更看重的是能力——这就是区别。

举例来说,对于初级工程师,我们更关心兴趣、热情、学习能力,以及是不是具备能够接纳意见等“潜力素质”,这些都是很难学到的、教不来的东西,而弱化了他立即独当一面,来工作和产出的能力。

但是,如果这位候选人已经有很多年的经验,或者说,无论基础的积累,还是做事的方法,都已经“成熟”了,那么我们就希望他已经能带领团队、快速产出了,招他的目的,自然就不是为了他的“潜力”。

也就是说,如果这样的“沙场老兵”候选人达不到高级工程师的要求,却满足了初级工程师的bar,我们可以“降级”,给他一个初级工程师的offer吗?显然是不能的。

另外,对于工作年限,我想再做一个说明。工作经验,从量的数据来看,确实是和工作年限成正相关的。但是,放到个体上,这并不是绝对的。

举例来说,一个在互联网前沿领域,每天做着有挑战性工作的工程师,有了三年的工作经验;和一个在传统产业,每天机械地做着重复性的工作,也工作了三年,他们作为软件工程师所积累的“经验”,可能有着很大的差别。

总结与思考

今天我给你分享了一些操作技巧,帮助你在决策会中剖析事实、总结模式、管理争论、收敛分歧,并最终引导得出共识结论。不知道你是否有所收获呢?

在最后,我想给你留一个问题。假如说,决策会上,大家第一环节的初始投票时,就已经表达了非常一致的态度,比如说,所有人都是No Hire,那么,你觉得这个决策会还有必要继续进行下去吗?还是说,直接给出一个共识结论——“不通过”就可以了呢?欢迎在留言区讨论。

好,我是四火,我们下一讲见。

评论