|
|
# 答疑课堂03：面试决策篇热点问题解答
|
|
|
|
|
|
你好，我是四火。
|
|
|
|
|
|
这一讲，我们围绕第三大板块“面试反馈/决策篇”主题。进行热点问题的解答。
|
|
|
|
|
|
对于面试反馈和决策部分，据我观察，对于面试官，特别是Bartender（技术负责人）的挑战还是很大的。在这里我将挑选几个很有典型意义的问题，跟你分享一下我的看法。
|
|
|
|
|
|
**问题1：怎样看待候选人面对同样类型的考察问题，却表现出巨大差异的现象？**
|
|
|
|
|
|
这是决策会上比较常见的一个问题。
|
|
|
|
|
|
比方说，某候选人同样在面对算法问题的时候，回答的情况差异巨大。在一轮考察链表的某个算法问题的时候，回答很顺利，不但完成了原问题的讨论、解答，还有充分的时间和面试官讨论两个延伸问题。
|
|
|
|
|
|
而在同一天的另一轮算法题考察环节，折戟沉沙，候选人面对一个难度适中的关于链表的算法问题，却推进缓慢，一直到最后也没有完成代码。
|
|
|
|
|
|
同样是算法问题，甚至都是关于链表的算法问题，两轮表现如此大相径庭，我们该怎样认识和处理这样的情况呢？我觉得可以从这样几个角度考虑。
|
|
|
|
|
|
**首先，正确认识面试考察的局限性，不要钻牛角尖。**我们在谈论计划制定时（[第2讲](https://time.geekbang.org/column/article/360268)）就说过，面试考察的目的，不是做出100%准确的决定，而是要在有限的时间里，尽量通过合理的角度布局，尽可能挖掘到有帮助的信息，从而做出在风险范围内可接受的决策。
|
|
|
|
|
|
因此，永远不要期望能做出一定正确的决策，也不要期待所有的问号都得到解答。有时候，候选人也许就是单纯在某一轮没发挥好，如果非得要钻出他那一轮为什么表现不佳，这就不合适了。
|
|
|
|
|
|
**其次，尝试从分歧中寻找一致的模式。**有些时候，表象是矛盾的，但是背后的原因却是一致的，如果我们能找到这个一致的原因，那再好不过，如果找不到，自然不要勉强。
|
|
|
|
|
|
在[第9讲](https://time.geekbang.org/column/article/367483%E3%80%81)中我介绍了一个例子，是说对于同一位候选人，有一位面试官说他编码能力不行，而另外两位则表示候选人编码能力没有问题。经过推敲，我们发现其实该候选人在其中一轮面试中，是因为没有妥善地沟通，理解问题，才走了一个错误的方向，而被简单地描述为“编码能力不行”。
|
|
|
|
|
|
再结合这位候选人其它的事实数据，我们发现他确实在沟通和交流方面存在不足。但他的编码能力本身，从面试中的表现来看，是没有问题的。
|
|
|
|
|
|
所谓模式，我们已经介绍过，指的就是**对候选人出现一次以上的相似评价，或者是体现出的相同问题。**
|
|
|
|
|
|
因此，我们如果能经过推敲，找到这样多次出现的事实数据作为佐证，那就可以得出一个比较可信的判断了。在这个例子中，经过了决策会的推敲，无论是候选人编码能力的正面反馈，还是沟通技巧的负面评价，都是有多次的数据支持的，都构成了模式的判断。
|
|
|
|
|
|
**最后，从不一致中继续分析其它原因。**找不到背后一致的模式，我们还可以继续寻找不一致的原因。比如说，有时候我们会发现，候选人第一轮表现相对于其他轮次往往要差一些，也许这和刚开始心里有些紧张，没有进入好的状态有关。
|
|
|
|
|
|
总之，候选人对同类考察问题的表现差异很大，我们确实可以尝试寻找原因。即使找不到差异背后的原因，面试中收集的考察数据还是可以帮助我们决策的，不必强求所有关于分歧的问号都得到解答。这时我们最好多找共性，也就是一致性的数据，这样的数据越多，越有助于判断出“模式”，提升决策的合理性。
|
|
|
|
|
|
**问题2：候选人优势非常突出，不忍错过；但不足也非常明显，达不到工程师的水准线，我们该怎样处理这种情况？**
|
|
|
|
|
|
其实这种情况挺常见，其中最典型的是，候选人各方面能力都达标，有的部分甚至非常出色，例如对于分布式系统的理解非常深刻，但就是代码能力一塌糊涂。说不通过吧，觉得错过这样的候选人也挺可惜的；说通过吧，作为一个程序员代码关不合格，怎么说也过不去。
|
|
|
|
|
|
第二个例子是，候选人技术能力很不错，大家都非常认可；但是性格强势，很难合作，多轮面试都有面试官反映了这个问题。这就又纠结了，既不想错过这样技术优秀的候选人，又担心加入了团队每天搞个人敌对。
|
|
|
|
|
|
我觉得遇到这种情况，可以从两个方面来分析。**第一个方面是，候选人所不足的部分，对于相应级别和职位来说，它的重要程度如何？**如果不是“必要”，那么目标团队，愿不愿意接纳，并承担它带来的风险？
|
|
|
|
|
|
就说第一个例子中的代码能力，它显然是一个通常意义上软件工程师的必选项，那么如果代码关过不去，就不能够胜任这样的职位。
|
|
|
|
|
|
但第二个例子中的“性格问题”，这就很难说了，主要得看目标团队的态度。有些团队希望有这样性格较为强势但是技术出色的人加入，以达到一种平衡，而有些团队则不然，不愿意这样的候选人加入，担心这会破坏和谐的气氛。
|
|
|
|
|
|
因此遇到这类情况，有的招聘经理会直接拍板，也有些会去团队内部开个短会，获得大家的认可后再接纳，这些操作方式都可以供你参考。
|
|
|
|
|
|
**第二个方面是，无论是出于上述的何种原因，候选人不适合当前职位、当前团队，那么能否推荐给其它职位、其它团队？**
|
|
|
|
|
|
如果是不同的职位，例如软件工程师改为产品经理，那么一般需要重新走一遍面试loop（轮次）的完整流程，毕竟这两个职位对于候选人的要求太不一样了；如果是不同的团队，那么对应的团队一般会要求加面一两轮，或者由该团队的工程师或经理和候选人聊一聊，再最终决定。
|
|
|
|
|
|
**问题3：要根据候选人的表现，来对标对应职位和级别的bar，那这个bar到底有多高？**
|
|
|
|
|
|
这个问题其实是很多面试官的担忧。初衷很简单，每个人的标准都不同，尤其是刚开始做面试官，不太好把握这个度。
|
|
|
|
|
|
候选人有优点，也有不足，那在评估的时候，不知道这个评判候选人够不够得上要求的bar（标准尺度）在哪里，而且似乎很多不同的面试官，心中的这个尺度也差很远。对于这个问题，我觉得可以从这几个角度入手。
|
|
|
|
|
|
**首先，认识和接纳评判总是具有主观性，标准难以完全统一的事实。**也许单独把这一条拿出来讲不难理解，即便我们将尊重事实数据的实践做得再好。毕竟面试官都是人，是人就不可避免地带有主观性，而且有着相当强的主观性。我们能做的，是尽量做到让事实说话，尽量让决策背后的逻辑清晰、自洽。
|
|
|
|
|
|
对这个最终结论为“是”还是“否”的bar也是如此，我们一直在说，结论可以是“合理”的，但谁也不能保证它100%是“正确”的。
|
|
|
|
|
|
**其次，把握原则和方向，而不是具体的“指标”。**原则和方向似乎总是比较虚，习惯了和0与1打交道的程序员来说，更喜欢具体、明确的“指标”。但事实是，一旦这样的指标规定出现，它就一定会在某些情况下变得不合理，并且随着时间流逝，它很可能会越来越复杂，最后失去了它存在的意义。
|
|
|
|
|
|
举例来说，在[第2讲](https://time.geekbang.org/column/article/360268)中，我们就说，“对于经验较少的工程师来说，我们更看重的是潜力；而对于经验丰富的工程师来说，我们更看重的是能力”，这就是原则和方向，而不是一个具体的指标。如果非要制定出具体的指标来，一定会走样，例如怎样才算“经验丰富”，怎样才算“经验较少”？显然，这是无法量化的。
|
|
|
|
|
|
**再次，寻找参考标尺。**这是说，已经出现过的对于这个bar的定位和理解的事例，我们可以拿过来参考。比方说，一般来讲工作经验只有三年内的工程师，是不会考虑高级工程师的定级的，有太多这样操作的例子了，这就是一个参考标尺。但是需要明确的是，既然叫做“参考”标尺，那也存在着允许特例的可能。
|
|
|
|
|
|
还有一个典型的标尺，就是自己团队的同职位和级别的工程师。不知道你听说过Amazon的“50%原则”没有？就是说，在决策会的定级过程中纠结的时候，可以问团队这样一个问题，你觉得候选人会比你所了解的同职位和级别的工程师中，50%的人更优秀吗？
|
|
|
|
|
|
这个方式虽然也带有争议，并且问题依然很主观，但是它至少给出了一个参考标尺，可以避免一些明显不合理的决策。
|
|
|
|
|
|
**最后，发挥Bartender的引导作用，多观摩、交流，积累经验，和普遍的认识保持一致。**我们已经多次介绍过，Bartender在整个面试前后的组织和引导作用，那么在这个问题上也是一样的。
|
|
|
|
|
|
OCI的Bartender，每年都会有认证培训和很多交流活动，大家还可以自由地选择观摩其它面试官的面试。目的就是能够通过更多的沟通，让Bartender的标准尽量做到接近，追随主流。
|
|
|
|
|
|
作为Bartender，如果你意识到你过于严苛了，那么之后就要注意适当放低一些标准；同样，如果过于宽松了，那么在后续的决策会中，就可以相应地抬高一些要求。生活中很多事情都崇尚个性，但是对于面试和决策标准这一条看不见的bar，我们却不希望有太多个性，而是要和普遍的认识保持一致。
|
|
|
|
|
|
**问题4：能不能发几个面试文字反馈评价事例？**
|
|
|
|
|
|
这个问题来自于用户郭志华的提问，我觉得之前在介绍面试反馈的时候，给了参考模板，但并没有给出使用模板的具体反馈例子。
|
|
|
|
|
|
下面我挑选了近期工作中的两个来自“一线”的文字面试反馈，你可以看到它们使用了不同的格式，但包含的内容还是比较相似的，从决策会需要的角度衡量，都是比较不错的反馈了。另外，需要说明的是，它们都经过了翻译，隐去了个人信息。
|
|
|
|
|
|
示例1，这是一个结论为No Hire的例子，反馈内容还是清楚、合格的：
|
|
|
|
|
|
> 考察专注角度：系统设计，赢得和给予信任（公司的一项领导力准则）
|
|
|
|
|
|
> 我们谈论了候选人现在的职位角色，他现在是团队中的开发骨干，也经常要跨团队合作，处理Ops问题，之后我们讨论了他做过的几个项目。
|
|
|
|
|
|
> 优势：对分布式系统模式有一定认识，比如Pub-sub系统和Event Queue，但是只限于它们大致是怎样工作的，而并不能说出使用场景和优劣来。他表现出了对于构建后端系统的热情，和对Java的喜爱。
|
|
|
|
|
|
> 不足：不幸的是，他在系统设计的环节做得很糟糕。我们先一起过了一遍他当前在工作的项目，但是之后他没法展现他对于项目了解的深度。在我对于他的系统存在“Single Point Failure（单点故障）”的质疑之后，他没能拿出一个解决办法。我不知道他今天是不是比较疲惫，他说话有点心不在焉。他总是连续说出一大堆而不给我对话的机会，因此好几次我不得不打断他的谈话，和他交流挺困难的。
|
|
|
|
|
|
> 结论：No Hire。根据我的经验，我不觉得他达到了OCI的标准。
|
|
|
|
|
|
示例2：这个反馈原本比较长，我保留了其中的片段。我之所以选择这一个面试反馈，并不是因为它内容有多完整、合适，而是因为它反馈了候选人在面试中作弊的情况，我觉得它有一定代表性：
|
|
|
|
|
|
> 结论：Never Hire，有一项red flag，我将在下面解释。
|
|
|
|
|
|
> 级别：IC2
|
|
|
|
|
|
> 行为考察：我询问了他简历上一个特性设计的经历，陈述清楚，对于业务的理解也很清晰。
|
|
|
|
|
|
> 技术考察：我的问题是让他设计一个保龄球的计分系统。他表示他并不了解保龄球，因此我给他做了介绍。
|
|
|
|
|
|
> 接下来，在我给了他一些具体需求之后，我看见了他眼镜片上的白色反光，看起来是在使用Coder Pad（注：面试中使用的在线编码工具）以外的东西。他没等我叙述完需求，就开始跟我讲他的实现方案了，这时候白色反光就消失了，Coder Pad背景的黑色反光又回到了他的镜片上。这样的过程在整个过程中反复了几次，我意识到他肯定是在查什么东西。
|
|
|
|
|
|
> 很快我再次确认了我的疑虑，因为他用到了一个我没有提到过的技术术语，用来表示保龄球的轮次，但是我知道在Stackoverflow上有这个问题的答案，并且答案里就有这个术语。
|
|
|
|
|
|
> 在之后我比较了Stackoverflow上的代码实现，方法签名和名字居然和他的实现一模一样，这更验证了我的猜测，虽然他最后也没有完成完整的代码实现。
|
|
|
|
|
|
> （略去下面的代码片段）。
|
|
|
|
|
|
那好，今天就谈论这几个问题吧，希望这些问答对你有所帮助。
|
|
|
|
|
|
你需要记住的是，无论准备再充分，作为面试官，作为Bartender，在决策环节总会遇到棘手的问题的，就像我们之前反复说到的那样，只要决策过程的逻辑是合理的，那结果就是合理的。同时，也不要害怕把困难的问题抛出来，和其他面试官一起讨论。
|
|
|
|
|
|
如果你有问题，欢迎在留言区告诉我，我将尽可能给你答复。
|
|
|
|
|
|
好，我是四火，我们下一讲见！
|
|
|
|