mod

极客时间专栏/技术面试官识人手册/面试反馈|决策篇/09 | 决策会准备：怎样全面收集事实，有效提炼数据？.md

@@ -0,0 +1,168 @@
+<audio id="audio" title="09 | 决策会准备：怎样全面收集事实，有效提炼数据？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/86/b3/8610b189ab7f75f1eyy84ff104f01bb3.mp3"></audio>
+
+你好，我是四火。
+
+讲完了面试前的准备，讲完了面试时的把控，现在我们要讲到面试后的决策了。在决策会前，我们通常要求面试官准备好一份简短的面试反馈（feedback），这份反馈包含了面试官自己观察，以及对于候选人“推荐程度”的结论。
+
+你我都知道，包括面试在内，凡是“考试”，最基本的原则就是要客观公正，可是事实上，每个人都难免戴着有色眼镜看世界，这跟我们总是期望着的客观公正背道而驰。
+
+那么在这一讲，我来着重谈一谈，我们该怎样去收集事实、提炼数据，尽可能地少受情绪与主观臆断的影响，尽量保持客观公正，把这些采集到的信息真实地提供给决策会。因此，这里的关键就是，专注于具体的事实和考察数据，减少对模糊主观感受的依赖。
+
+## 常见的误区
+
+老规矩，我们先从反面来看看在数据采集和整理方面，都有哪些常见的误区。
+
+### 脱离面试计划
+
+还记得[第2讲](https://time.geekbang.org/column/article/360268)介绍的面试计划吗？没错，脱离面试计划，就是最常见的一个问题，有时候这个“脱离”，是面试官忽略了计划安排，而有时候甚至就是因为压根儿“没有”面试计划，在这种情况下，谈何“全面、客观”地评估呢？
+
+面试计划的一大要点就是确定了每个面试官的考察重点，谁负责考察编码能力，谁负责考察对系统的理解，都分别确定了下来，因此对于一个面试，哪怕大家遵循了一个非常简单的面试计划，都要远远好于没有计划，或者是订立了计划却抛之脑后。
+
+我们当然鼓励面试官自由发挥，但是自由发挥的底线是保证和安排的面试重点保持一致。这就像是做软件，如果没有遵循设计，甚至根本没有设计，哪怕代码写得再精致，很可能也是事与愿违，甚至南辕北辙。
+
+### 缺乏事实依托
+
+“专注于事实和数据”有时是一件并不容易做到的事情。我们都知道要摆事实、讲道理，通过实际的事实和数据来佐证我们的观点。但是在实际操作的时候，特别对于一些面试经验较浅的面试官而言，很容易被情绪或者是第一印象带着跑。
+
+我来举一个真实的例子，有一位面试官在他的面试反馈里说，候选人“coding能力不足”，但是读完整个面试反馈也没有找到非常扎实的事实描述，来佐证他的判断。于是在debrief的时候，我就仔细追问了他给出这个观点的原因。
+
+后来才知道，候选人的coding之所以表现不佳，是因为他走了一条错误的路线，但其实问题的根源是候选人没有能够沟通清楚和理解问题，而并非coding本身。再结合其他两位覆盖coding的面试官的反馈，我们得到的大致结论是，候选人的coding本身是没有问题的，基础知识也比较扎实，但是沟通等方面存在不小的问题。
+
+<img src="https://static001.geekbang.org/resource/image/1b/d8/1b217c26e9ce4c9ee366b6fbef6da4d8.jpg" alt="">
+
+### 事实数据浮于表面
+
+这一点，指的是有时候我们觉得已经得到了考察数据，但是这样的数据不够深入，缺乏足够的说服力。比如说，知道概念，不知道原理；说得出选择什么技术来实现，却说不出为什么。有时候面试官缺乏过硬的技术基础，或者缺少一点往“具体”，甚至“细节”挖掘下去的动力，就很容易陷到这个坑里。
+
+比方说，有位候选人对于一个分布式系统的大致理解谈论得还可以，在问到怎样做系统平滑扩容的时候，他也明确提到可以使用基于“一致性哈希”的技术，那好，“什么是一致性哈希呢？”，结果候选人听到这个问题就卡壳了。
+
+其实对于面试官来说，多一个这样的追问并不难，而对于候选人来说，一致性哈希也可以说是分布式系统的一个基础知识，但这个快速追问就是一个向下探查的过程，很有意义。换言之，可能通过这样的提问来谈论自己的理解，加起来也就一分钟时间，这个过程很自然地发生了，但是却可以得到一个很有价值的考察数据。后来，我们发现，这位候选人对于系统的很多基础知识并不是真正理解。
+
+类似地，在技术选型的讨论上也有这样的情况。例如说持久层的技术选择，有候选人说要使用NoSQL，那我们就可以要求澄清，“使用哪一种NoSQL存储技术呢？”，候选人说是HBase，紧接着进一步追问就可以抛出来“那为什么选择它呢？”。通过这样的方式，我们希望获得的数据，是候选人是否真正理解这些他自己说出来的概念和技术，还是只知道一个名词而已。
+
+此外，需要小心的是，在技术方面，我们可以考察能力和基础，而不是考单纯的记忆力，更不是钻牛角尖。这在[第3讲](https://time.geekbang.org/column/article/361420)的“知识性的问题”部分我已经强调过了。
+
+### 重复考察已明确的数据点
+
+面试的时间是宝贵的，面试官都应当有“珍惜双方的时间”这样的意识，因此，我们对于已经非常明确的考察数据，不应该再去重复考察，而是应该把时间分配到其它的考察项上去。
+
+我来举一个例子吧。候选人在算法部分，problem solving的部分表现得非常好，思路清晰，问题解决推进迅速，复杂度分析准确，但是代码却写得有些混乱，比如命名不一致，组织欠缺条理，重复代码多等等。
+
+这时候，在编码后问follow-up问题的部分，我觉得面试官就可以先放一放对于problem solving的进一步考察了，而是可以问一下候选人，对于代码的组织和书写，有没有可以优化的地方呢？
+
+这样做的目的就是，对于我们有疑虑的部分，又觉得考察程度还不够，可以给出提示，看看候选人能否改进他的“作品”，而对于他已经很明确的强项部分，我们已经有了足够的数据，就可以先放一放了。
+
+## 可采用的技巧
+
+好，说完了常见的问题，下面我们就从正面来讲一讲，除了上面提到的注意要点，还有哪些数据采集和整理的技巧。这些技巧的目的都是一致的，围绕预先规划好的考察重点，尽量客观地去评估候选人。
+
+### 面试情况速记
+
+速记，这是一个很有价值的技能，并且这个技能因人而异，需要不断练习。我的习惯是，对于面试过程中的沟通，基本上重要的信息，都会用几个单独的词记录下来，这些信息，自己能看懂就好，目的只有一个，就是能够帮助自己回忆。同时，在记录笔记的过程中，最好能大部分情况下盲敲键盘，这样，眼睛可以用来和候选人进行沟通，提供直接的眼神交流是很重要的。
+
+<img src="https://static001.geekbang.org/resource/image/ef/08/ef923e6259691312c7f718faa5c2bf08.jpg" alt="">
+
+### 及时预定决策会
+
+决策会将是所有参与该候选人面试的面试官碰头的一个机会。一般来说，“及时”是要点，只要各自的面试反馈能够及时在会前整理，这个会议定的时间越早越好，因为越早大家脑海中的印象也越新鲜。
+
+如果这个会议发生在面试的一周后，判断的准确性就要大打折扣了。在有的公司里，这个会一开始由招聘专员（Recruiter）制定，有的则是由招聘经理制定，这都可以，但是，我们要尽量保证每个面试官都参加。特殊情况下个别人无法参加的，需要提供一份比较详细的面试反馈。
+
+### 使用面试反馈模板
+
+在我看来，面试反馈模板的使用，是效果最强大的技巧了。一般来说，每一组面试的Bartender，可以在面试计划的时候，给出一个反馈模板，要求大家都按照模板上的格式来提供反馈意见。模板的要求很简单，就两点：
+
+1. 保证包含面试考察最关心的点；
+1. 模板要简单、直接（越简单、直接，可操作性就越强）。
+
+下面这个模板的例子供你参考：
+
+> 
+<p>考察重点：<br>
+主要考察内容：<br>
+优势：<br>
+不足 / 担忧：<br>
+结论：<br>
+其它重要信息：</p>
+
+
+好，我来逐条讲一下。
+
+**首先是反馈模板的第一部分：考察重点和主要考察内容。**它们各一句话，这些都要和[第2讲](https://time.geekbang.org/column/article/360268)的面试计划一致。如果你忘了，请回看。比如说，考察重点是：
+
+> 
+实际问题的解决，代码设计和实现，面向对象设计
+
+
+这就要求这一轮面试的反馈，要包含对上述考察项的评估意见。通过模板的方式再一次明确这一点，从而保证面试过程有着明确的目的，而不是漫无边际地谈论。
+
+接着的主要考察内容，也是来自于面试计划，也就一句话，比方说：
+
+> 
+要求设计一个电梯系统，设计其中的主要类和方法。
+
+
+要不要详细说明具体是怎样定义的，划定了哪些具体需求点，又是怎样实现的？我的建议是：不要求。如同上面所说，模板要尽量保持简单、直接，要求越多就越难以实施。
+
+但是不知道你注意到没有，各一句话，**考察重点是目的，考察内容是途径**——通过这两句话，就可以大致了解，这一轮面试，通过怎样的途径，主要要考察候选人的哪些方面。
+
+**其次，反馈模板第二部分，优势和不足。**这两个部分，我想谈这样两个操作要点：
+
+第一，优势和不足都要写到，如果面试官只看到了一面，也就是只看到了好的一面，或者是差的一面，这样的反馈是不合格的。因为这样的观察说明是不客观的，或者是不深入的。
+
+第二，写出观点的时候必须要写事实论据吗？需要，但是我们不强求每一条观点都写论据。比如这样的例子：
+
+> 
+编码能力不够扎实，花了很长时间才把一个BFS逻辑的基本结构写出来。
+
+
+这就是一个合格的表述，但是据我观察，大多数人在反馈中，总会有部分观点是不写事实论据的，有时甚至连描述性的语句也没有。但只要在整个反馈中占比是属于少数的，这就没有关系，遇到这种情况，我们可以在决策会的时候再要求该面试官说明即可。
+
+**再次，是反馈模板的第三部分：结论。**怎样写结论？这包括两个部分：
+
+1.推荐程度<br>
+2.级别
+
+“推荐程度”，指的是根据该轮表现，面试官认为候选人是否能通过面试，成为团队的一员。有的公司要求填写Hire / Weak Hire / Weak No Hire / No Hire，有的公司要求填写强烈推荐/推荐/不推荐/强烈不推荐，还有的公司干脆要求打1~5分，但它们原理都是类似的。
+
+“级别”，顾名思义，根据该轮面试官对于候选人的综合评估，如果结论是正面的，那么该结论是基于哪个级别得出的。如果不提及级别，那么就以面试计划中设定的默认级别为准。
+
+有些时候，有的面试官会给出一个简单的“条件表述”，也是可以的。比如：
+
+> 
+综合表现尚可，但对于coding有所疑虑，如果其它轮次coding没问题的话，我给出“Weak Hire”，否则“No Hire”。
+
+
+**最后，是“其他重要信息”，但这是一个选填内容。**通常这部分都是留白的，但是有些特殊情况需要和整个面试团队交代，比方说，我经历过的一个例子，有位面试官发现候选人作弊，具体来说就是线上面试，一遍用语言应付，一遍在互联网上搜索问题的答案。这就是一个非常重要的信息，对这一类“道德品行”的问题该怎样看待，我们在后续会谈到。
+
+此外，如果有候选人的绘图、代码片段等你认为有必要陈列的，可以一并附在反馈中。
+
+### 催促面试官提交反馈
+
+上面我讲了一个我推荐的面试反馈模板的例子。那么，这个反馈写好了发给谁呢？一般来说，不要发给面试团队全员，而是只发给Bartender（技术负责人，我们在[第2讲](https://time.geekbang.org/column/article/360268)介绍过，如果忘记了请回看）和招聘经理就好了。
+
+按理说，反馈写得越及时，面试过去的时间越短，效果就越好。如果面试已经过去一天了，或者是决策会快要开始了，而有的面试官还没有提交反馈，那么Bartender就需要催促面试官把反馈提交上来（当然，有时候这个角色是招聘经理负责的）。
+
+好，接下来，我想讲一讲为什么把面试反馈写下来那么重要。
+
+**首先，面试反馈确保最基本的逻辑正确性，明确立场。**作为一个面试官，我这一轮关注的重点是什么，我做了什么操作来考察候选人，候选人有哪些好与不好的表现，分别支持我的哪些判断，而最后又是一个怎样的结论。
+
+这些内容，说起来都是很简单的逻辑，但是只有把它们写下来，有因有果，才算真正梳理清楚了。尤其对于“纠结症患者”，逻辑清楚非常重要，这样在激烈的决策会讨论中，对于自己的观察，有着明确的立场，不会轻易摇摆。从这个角度说，其实，面试反馈写下来这个过程，要比面试反馈本身的内容，重要得多。
+
+**其次，面试反馈帮助记忆，也留下重要的记录。**如果你做过面试官，你也许会有这样的体会，完成了一轮面试，感觉有很多话要说，但是过了一天之后，忘记了一半，剩下的部分，再过一天，又忘记了剩下的一半。但是面试反馈可以帮助你把最重要的部分记录下来，在debrief的时候帮助回忆。
+
+有些时候，面试的决策不容易做出，在极端情况下甚至需要有其它人参与进来，回看面试的情况（我们在后两讲会谈到，如果面试团队自己无法达成一致怎么办），那么这些面试反馈就是很有价值的文字记录了。
+
+**最后，这些反馈可以帮助Bartender和招聘经理在决策会前留意到一些重要信息。**比如前文中提到的一些反映严重道德品行问题的事情，这样的信息在后面决策会的时候可以优先拿出来确认。
+
+## 总结与思考
+
+今天，我介绍了在面试中收集数据和记录事实信息的误区，以及可以采用的正确的技巧，并且介绍了在面试后如何根据它们总结成客观、有效的反馈。
+
+希望这些内容对你有所帮助，但是我要强调的一点是，要保持独立思考的习惯，所有的这些对候选人的评价，要独立进行，在决策会开始以前，不要去和任何别的面试官讨论面试的事情，以免影响自己的判断。
+
+<img src="https://static001.geekbang.org/resource/image/81/f6/816a27d7924f0d3bcb6d2746b73c5cf6.jpg" alt="">
+
+在本文的最后，我想留一个问题供大家讨论。动员面试官写反馈的一个常见困难是，对方说“太忙，没时间”，对此，你怎么看？
+
+好，我是四火，我们下一讲见！

极客时间专栏/技术面试官识人手册/面试反馈|决策篇/10 | 决策会开展（上）：怎样引导争辩，达成共识？.md

@@ -0,0 +1,177 @@
+<audio id="audio" title="10 | 决策会开展（上）：怎样引导争辩，达成共识？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/70/9c/70cf71d486636505fe76edd27358169c.mp3"></audio>
+
+你好，我是四火。
+
+今天这一讲，我们来聊聊技术面试后的决策会。决策会，就是大家碰头商讨候选人情况，达成面试共识的过程。显然，这在一定程度上将决定，公司和团队是否愿意接纳候选人，也就是说，候选人是否能得到相应的工作机会，其重要性不言而喻。
+
+“开会”这个事儿是技术团队的长期热门词汇，无论你是否喜欢，在很多情况下，它是一种群聚的同步交流方式，目前并没有更好的方式可以替代开会。
+
+今天我们要讨论的情况便是如此，候选人经过了技术面试，怎样给出最终的评估结论？大多数的情况，还得靠开会。
+
+其实这个给出结论的过程，一般有两种形式：
+
+- 第一种，是一个特殊角色的人（这个人一般是级别较高的管理者），收集了面试后各位面试官的评价，然后独立决定；
+- 第二种，是面试团队坐到一起，以会议的形式讨论并达成共识，共同决定。这个会议，有很多叫法，我们在这里把它简单称作“决策会”（Debrief）。
+
+通常来说，对于普通的软件工程师面试，第二种，也就是决策会的形式，更为多见，我也更为推荐。因为相较于第一种，**它也保证了更高的参与度，团队内部保持公开透明，更能真正做到让团队为团队自己选人**，而这一讲的讨论也是针对这一种方式展开的。
+
+## 典型的误区
+
+决策会的误区其实还是非常多的，我们来讲最典型的几个，看看有没有你熟悉的。
+
+### 把决策行为变成了民主选举
+
+对面试结果的决策变成了民主选举，无论是简单粗暴的直接投票，还是共识无法达成索性强行投票，本质上都是一个“少数人服从多数人”的逻辑，这看似很公平，其实恰恰相反。关于这一点，我觉得可以从这样两个角度去理解：
+
+1.评估一个面试决策，**更具意义的衡量标准是，它背后的逻辑是不是合理，而非人数是不是占优。**我们平时说的“以理服人”，其实说的就是这件事情。
+
+2.在某些情况下，面试官其实对于自己的选择也并不坚定、或者思考并不成熟，需要引导、需要讨论，而民主投票在一定程度上，直接粗暴地“绕过”了这个过程。比如说，面试官有他的观察，也有他的数据，但是如同在[第9讲](https://time.geekbang.org/column/article/367483)中提到的那样，它不够深入，或是不能较为准确地剖析和认识它所代表的意义。
+
+Bartender（技术负责人）应该在这样的面试决策会上，根据已明确的事实和数据，针对所有在会上的讨论内容综合分析以后，引导面试官做出合理的决策，达成基于团队的共识。
+
+由于这个问题太过常见，我见过一些决策会中，虽说Bartender都明白这个道理，还是会不知不觉地犯下“民主选举”的错误，**特别是在争辩较为激烈的情况下，为了收场，在很多分歧还没有得到**解决，**很多疑点还没有澄清的情况下，选择了投票选举这种简单粗暴的办法。**
+
+因此，我要再一次强调，面试结果的决策，不是民主选举。
+
+### 过于倚重招聘经理的意见
+
+招聘经理的话语权重过大，这个问题也非常常见。特别是某一些团队中，工程师资历比较浅，他们有时会无意识地倾向于经理的观点，因为在平时工作中，招聘经理就是他们的主管，有时候即便有不同的看法，自己也不一定在决策会上提出来，或者即便有足够的理由，也不能够坚持自己的看法，据理力争。
+
+因此，Bartender的协调作用就非常大了，他需要站出来，帮助团队识别出具体的事实数据，而不是单纯的具有倾向性的观点。在这一讲的后面，以及下一讲我还会介绍一些技巧，尽量减轻这个问题可能带来的影响。
+
+### 缺乏事实依托
+
+缺乏事实依托，其实在上一讲也谈到了这个误区。在收集和整理对候选人的反馈时，需要有事实依据，在决策会的讨论中，凡是抛出对于候选人评估的观点一旦需要求证，要能拿得出事实数据来。
+
+举例来说，有的面试官讲，他注意到候选人并不能听取和接纳他人的意见，那么，要是有人要求他拿出事实数据，来解释为什么给出这样的观点，如果他没法说出来，或者只能说“不太记得了，就这个印象确实很深”，这样的观点逻辑就不成立。
+
+但是，如果这位面试官确实拿出了一条数据呢？
+
+比如说，候选人在一个算法问题的求解上陷入了挣扎，他原本的回溯法思路走不通，于是面试官提示候选人另外一种排列组合的思路，候选人听到了，但是却选择了忽略建议，继续在他原有的思路方法上挣扎。
+
+有了这样的事实数据，我们是否就能认定候选人“不能听取和接纳他人意见”呢？我认为，单单凭此还是不能的，至于原因，我先卖个关子，我在后面会告诉你为什么。
+
+### 不合理的决策因素影响
+
+有一些事实不应该影响到决策，但正所谓“旁观者清，当局者迷”，在决策会上，其实经常会看到一些不合理的决策因素。
+
+比方说，我经历过一场决策会，本来大家对结果达成一致了，认为候选人通过了面试，并且也确定了级别。
+
+结果会后，招聘经理突然把大家召集到一起，说我们能不能把给候选人的级别增加一级，因为他已经从别的公司得到了一份offer，原有级别的offer无法说服他来我们公司。
+
+我认为，这个试图改变决策的初衷就是不合理的，因为候选人有没有其它offer既不属于候选人过去的经验、履历，也和候选人当时的面试表现无关，那么这样的因素就不应当影响面试结果的决策。
+
+## 流程把控
+
+好，介绍完典型的误区以后，我再从Bartender的视角介绍一下，作为面试官，我们对于决策会应该有一个怎样的预期，又应该怎样把控整个决策会的进程。
+
+### 整体认识
+
+一般绝大多数的决策会都可以在30分钟完成，并且是由Bartender主持的。少数情况，譬如候选人的情况比较复杂，或是争议较大，达成一致较为困难，我们就需要延长时间。
+
+从参与的人员上看，所有现场面试的面试官都应该参加决策会，而之前电话面试的面试官，可以不参加。有时，负责招聘的同事（recruiter），也会参加，一般不发表看法，而是倾听，了解这位候选人的情况。
+
+如果有个别面试官由于个人情况无法参会，只要提交了清晰的面试反馈，这也没关系，不影响会议进行，但是，**如果Bartender或是招聘经理无法参会，那么这个会就必须要延期。这是因为，这两个角色在整个面试团队中比较重要，而且相互制衡**（具体原因请参见[第2讲](https://time.geekbang.org/column/article/360268)），缺乏任何一方都无法保证决策会的全面、客观、公正。
+
+从输入上看，我们要求所有面试官都将完成的面试反馈，交给招聘经理和Bartender，这是会议高效的保证，当然，如果存在没有提交的情况，虽不理想，但也不应成为会议进行的阻碍，具体的反馈内容可以在会上详述。
+
+从输出上看，最重要的就是得出面试结果，包括两点，首先是面试是否通过；其次，如果通过的话，面试团队为候选人裁定的角色级别是什么。
+
+具体形式上，不同公司会有不同要求，很多公司都有内部的一个管理招聘流程的网站，有了结果后就需要更新上面的信息。
+
+好，在整体上有了感观认识，下面我来介绍一下决策会的几个重点环节。这些环节可能在不同公司和团队中有所差异，我所介绍的实践方案，是在我看来比较推荐的一种。
+
+### 第一环节：初始投票
+
+会议开始以后，Bartender会介绍一下候选人的姓名和目标职位、默认的目标职位级别。然后，大家开始投票，投票内容其实就是一个事儿：对候选人的推荐程度，例如 Hire / Weak Hire / Weak No Hire / No Hire（具体介绍你可以参见[第9讲](https://time.geekbang.org/column/article/367483)）。
+
+具体操作上，把握一个原则，尽量让大家不要互相影响，而是完全凭借自己的判断给出结果。如果非疫情期间，大家都坐在会议室里，那么一种推荐的方法是，Bartender数1、2、3，然后大家一起伸出大拇指，Hire就垂直朝上，Weak Hire就45度角朝上，Weak No Hire就45度角朝下，No Hire就垂直朝下。
+
+<img src="https://static001.geekbang.org/resource/image/65/8f/650ff053debf0ef83f763c1c3f2fe28f.jpg" alt="">
+
+其中的原因我想也很容易理解，比方说，如果招聘经理先表态，而招聘经理往往也是团队的经理，其它面试官也很可能平时就是汇报给他的，那么某些面试官就更容易受到经理表态的影响。
+
+需要说明的是，这一轮投票让大家先开门见山地亮出自己简要的结论，而并非据此直接裁定决策会的结果，并且我们在第二环节中会再展开陈述反馈，即“先摆明态度，再慢慢解释”。
+
+**经过实践的验证，这是一种比较好的方式，有助于每个面试官独立地表达和明确自己的观点，并且能让每一位与会者快速参与，进入思考与讨论的状态。**
+
+### 第二环节：反馈陈述
+
+第一环节很简单，一般一两分钟就结束了，下面进入具体陈述反馈的第二环节，它的花费时间一般可以比较长，但也请尽量保留至少10分钟的时间给第三环节。
+
+具体操作的方法是，在Bartender的提示下，所有面试官依次来介绍他那一轮的面试简况，面试的重点和内容大致是什么，候选人的优势和不足是什么，也就是说，给出第一环节的那个投票，你的逻辑是什么。叙述顺序还是一样的——普通面试官、招聘经理、Bartender。
+
+在反馈陈述方面，Bartender需要控场，主要抓住这样几个要点：
+
+**陈述时间控制。**可以先提示一下，也可以在陈述的过程中判断，如果发现陈述过于细致具体，那么就要提醒一下，我们的目标是给其他人，以及第三环节保留一定的时间。
+
+**事实支撑的鉴别。**对于主要的观点，如果发现只有观点陈述而没有事实依托，需要立即追问，确保对方谈到的事实和观点是匹配的。
+
+**主要内容的速记。**这一步很重要，我在上一讲也已经谈到了，把诸位面试官的判断中，几个关键词记录下来，在第三环节需要纵览这些反馈，获得一个比较清晰的认识，如果不动笔而单纯靠记忆力，是比较困难的。
+
+### 第三环节：争辩开展与共识达成
+
+接着是第三环节，**首先，Bartender可以简单地帮大家回顾一下前两个环节的情况**，比如说：
+
+> 
+一共3票Hire，两票No Hire；两轮覆盖了coding，两轮覆盖了系统设计，还有一轮综合考察。
+
+
+不要小看这一步，除了可以帮助大家强化一下这个基本印象，还能够识别一些面试程序上明显的问题。
+
+比如说，如果软件工程师候选人没有人进行代码面试，这就是一个覆盖面的硬伤。如果真的遇到这种情况，也别担心。对于这样硬伤的处理，我在下文中会谈到。
+
+**然后，寻找反馈的模式（pattern），和大家一起讨论。**这里所说的“模式”，指的就是对候选人出现一次以上的相似评价，或者是体现出的相同问题。我来举个例子：
+
+面试官A说：
+
+> 
+候选人谈到他做xxx项目的时候，周末加班把它完成了，但是下周一的时候，他主管说他做的其中一个主要功能并不是需要的。
+
+
+面试官B说：
+
+> 
+我让候选人将一棵二叉树序列化成字符串，他和我很简单地沟通了一下，就开始介绍该怎样实现了，但我们并没有讨论清楚序列化的具体要求是什么。
+
+
+虽然两位面试官说的明显是两件不同的事，但这里隐约暴露出了一个模式，也就是同一个问题：候选人在工作的时候，很让人担心他能不能做到充分的沟通：
+
+1. 做了一个不需要的功能，这不是技术问题，更像是缺乏充分的沟通；
+1. 没有讨论清楚需求就开始设计和实现，这也反映了缺乏充分的沟通。
+
+作为Bartender，就是要领着大家，从茫茫反馈的数据中，挖掘出这些模式来。模式所体现的优势，或是暴露的问题，要比单一的数据点要有说服力得多。
+
+**因为单一的数据点偶然性很大，兴许候选人可能就是单纯地没做好，但模式经过了超过一个支撑事实，或是不止一名面试官的验证，就可信得多。**这有点像医生看病时，结合化验报告和症状等多项“证据”，给出诊断。
+
+**接着，汇总建议，收敛分歧，达成共识。**经过Bartender引导的分析讨论，有些面试官提到的担忧，可能不是问题；有些提到的优势或不足，可能事实支撑并不构成较强的“模式”；而还有些优缺点，则会得到验证。
+
+经过这样逻辑清晰的分析，很多情况下面试官会调整或者改变原先观点，大家逐步达成一个“共识”，这个共识就是前面提到的决策会需要产出的面试结果——综合来看，候选人有哪些优势和不足，他是不是通过了面试，大家对他认可的级别又是什么。而Bartender，这时可以归纳总结一下，并给出自己的建议。
+
+当然，这个从争辩到共识的过程并不好做，而且它非常考验Bartender对于对话组织和内容概括的功力，我们将在下一讲介绍这方面的许多技巧。
+
+对于共识的达成，通常有三种结果：
+
+1.最终如果大家能够达成共识，那最好不过，这也是大多数的情况；
+
+2.如果招聘经理和Bartender和多数其它面试官达成了共识，但个别面试官依然不认可，但这个不认可的程度较弱，那么我们依然可以采纳这个不完全的“共识”作为结果，但保留个人意见，完成决策会的输出；
+
+3.但如果招聘经理和Bartender都无法达成一致，或是大家分歧比较大，这就可能需要依赖于外部资源了，不同公司和团队处理方法不同。比方说，某些公司中，这种无法达成一致的情况，就表示面试不通过，简单直接；还有一些公司，有一个独立的“招聘委员会”，它由一些经验丰富的面试官等人组成，他们会根据所有的面试反馈，以及Bartender提交的面试会记录等材料，做出进一步的裁决。
+
+最后，无论是上面的哪一种情况，Bartender需要**简单陈述一下结果，确保整体决策的逻辑清晰合理。**
+
+<img src="https://static001.geekbang.org/resource/image/6b/cb/6b9df05437c3bd54ed4d99810010c9cb.jpg" alt="">
+
+## 总结与思考
+
+今天我给你介绍了面试后决策会的大致流程，包括其中都有哪些典型误区，对它的把控又有哪些步骤。
+
+就像我前面所说，Bartender作为面试官中的一个特殊角色，决策会的流程把控其实非常考验他的对话组织和内容概括的功力，这需要在实践中反复练习以及经验的积累。
+
+这个环节一旦做不好，由于观点碰撞和意见分歧，决策会就很可能变成乱糟糟的“吵架”大会。
+
+<img src="https://static001.geekbang.org/resource/image/d1/8d/d10ba0ab4341fca355308981cda7228d.jpg" alt="">
+
+今天的内容就是这些，我在最后留一个小问题吧：你作为面试官在面试后，是怎样做出通过或不通过的结论呢？能否在留言区和我分享一下呢？
+
+好，我是四火，我们下一讲见！

极客时间专栏/技术面试官识人手册/面试反馈|决策篇/11 | 决策会开展（下）：怎样确保评估全面且有深度？.md

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

极客时间专栏/技术面试官识人手册/面试反馈|决策篇/答疑课堂03：面试决策篇热点问题解答.md

@@ -0,0 +1,149 @@
+<audio id="audio" title="答疑课堂03：面试决策篇热点问题解答" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/ab/c5/ab4193796bcbc5a0409fb25aa97044c5.mp3"></audio>
+
+你好，我是四火。
+
+这一讲，我们围绕第三大板块“面试反馈/决策篇”主题。进行热点问题的解答。
+
+对于面试反馈和决策部分，据我观察，对于面试官，特别是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，在决策环节总会遇到棘手的问题的，就像我们之前反复说到的那样，只要决策过程的逻辑是合理的，那结果就是合理的。同时，也不要害怕把困难的问题抛出来，和其他面试官一起讨论。
+
+如果你有问题，欢迎在留言区告诉我，我将尽可能给你答复。
+
+好，我是四火，我们下一讲见！