|
|
# 02 | 制定计划：好的计划是成功的一半
|
|
|
|
|
|
你好，我是四火。
|
|
|
|
|
|
在上一讲中，我们谈到了在面试之前，从宏观上去认识和理解公司和团队需要，和大致的人才甄选标准的重要性。今天，让我们来继续深入这个话题，我将结合实际案例继续分解面试计划，讲解在操作上的要点。
|
|
|
|
|
|
## 常见问题
|
|
|
|
|
|
你们公司和团队，会为即将到来的面试做计划吗？根据我的观察，计划这件事情，是非常容易遭到轻视的。可能我这样说你感触并不深，下面我列举几个常见的因为不做或者没有做好计划，而导致面试执行有失偏颇的情况。
|
|
|
|
|
|
我曾经作为普通面试官参加过一次面试，那是一个涉及网络安全的职位。在交流过程中，候选人明确地表达了希望成为一名安全领域工程师的决心，只可惜面试团队里面没有这方面的专家。
|
|
|
|
|
|
我们大体上是按照普通软件工程师的思路来面试的，专业领域方面没有办法做有深度的覆盖。显然，这是欠妥的，候选人也或多或少表露出了失望。最后，我们不得不找来相关领域的同事，重新加了两轮专业面试。
|
|
|
|
|
|
还有一次，是关于软件工程师候选人，5轮现场面试中，只有一轮覆盖了编码。候选人其它四轮表现都不错，可惜编码略失水准。
|
|
|
|
|
|
从正面反馈的比例来看，其实候选人还是挺不错的，其它没什么问题，但是由于编码对于软件工程师来说是一个绕不过去的硬技能，而面试考察的覆盖明显不合理，coding方面的数据点不够，所以当时我们也是挺纠结的。
|
|
|
|
|
|
综合考虑之下，这位候选人最后还是入职了，但是入职仅仅大半年就离职了，其中一条不佳的反馈就是，几位同事都提到他的代码写得一塌糊涂。
|
|
|
|
|
|
前面描述了两个我印象比较深刻的问题，其实还有一些其它的典型问题，我在这里简单提一下，看看你们公司是否也有类似的情况发生呢？
|
|
|
|
|
|
* 面试一位十几年经验的工程师，对方倒是认认真真准备了，结果面试官拿的都是要写个快排之类的简单粗暴的算法题。基本上是拿着面试初级工程师的路子来面试经验丰富的候选人，最后的决策靠谱程度可想而知，而候选人也很不开心。
|
|
|
* 走完了整个面试，候选人拿到offer的时候说：“啊，我不知道这个职位还需要我长期出差办公啊？我不能接受出差办公。”
|
|
|
|
|
|
你看，发生这些问题，几乎都是缺乏面试计划，或者没有做好面试计划造成的。这样的代价，轻则浪费时间，让候选人失望，让面试官尴尬，重则招进来不合适的成员影响团队。
|
|
|
|
|
|
那么，我们该怎样合理地制定面试计划呢？
|
|
|
|
|
|
## 实例解析
|
|
|
|
|
|
这里我们从一个具体的例子出发，这个例子可以形象化地帮助我们理解，到底一份面试计划应该怎样做。
|
|
|
|
|
|
由于不同的公司、团队，面试的情况有所差异，例如轮次、时间等等，因此在实际操作中，请勿照搬照抄，而是把握原则，去因地制宜地执行。
|
|
|
|
|
|
候选人小张，硕士计算机专业毕业，7年工作经验，现就职于某互联网金融公司，面试团队是某互联网大厂的云计算团队，职位是高级软件工程师。
|
|
|
|
|
|
### 确定人选
|
|
|
|
|
|
以大厂为例，通常来说，电话面试一般1~2轮，现场面试少则3轮，多则5、6轮。
|
|
|
|
|
|
由于错招一个人的成本太高，基本上都会用“车轮战”的方式来尽可能地多收集数据，以做出更加合理的判断。每一轮都有单独的一位面试官（少数情况出于学习和培训的需要，可能安排两位）。
|
|
|
|
|
|
面试团队的人员角色包括这样几个：
|
|
|
|
|
|
* 招聘经理（Hiring Manager，HM）：一般都是由团队经理担任，这时的招聘也往往是“给他自己的团队”招人。招聘经理特别关注候选人和团队的匹配程度，而将诸多技术考察的活儿，留给其余的面试官。
|
|
|
* 技术负责人（Bartender）：这个角色的名称在不同的公司叫法也不同（比如，有叫Bar Raiser的），具体职责也有差异，但是大致的目的，就是要维持整个面试的水准。这个角色往往经过了专门的训练，他们有比一般的面试官多得多的面试经验，并且，**为了考虑利益相关性和平衡性，他必须来自于一个不同于招聘经理所在大部门的组织**。
|
|
|
* 其他面试官：这些面试官一般都来自于招聘经理的团队，或者兄弟团队。
|
|
|
|
|
|
|
|
|
|
|
|
### 制定计划
|
|
|
|
|
|
电话面试（Phone Screen）安排如下：
|
|
|
|
|
|
|
|
|
|
|
|
小张通过了电话面试，现场面试（On-site Interview，当然，疫情期间一般的现场面试也变成远程进行的了）安排如下：
|
|
|
|
|
|
|
|
|
|
|
|
让我们来对上面的这两个表格中的安排做个说明。**请注意，在计划的过程中，我们更关注的是考察重点和考察角度是不是能够以合理的方式分配，其比例是不是恰当，而不是具体的考察内容。**
|
|
|
|
|
|
事实上，对于具体的考察内容，不同的面试官也有自己的习惯，我们应当保持尊重。这里面的考察内容，我也仅仅是以举例的方式给你提示，之后的课程我还会详细讲解怎样设计这些考察问题。
|
|
|
|
|
|
### 计划剖析
|
|
|
|
|
|
**首先，清楚团队的需求和限制，设立合理预期。**我们想把这件事情尽可能做好，但是它本身存在着诸多局限性：
|
|
|
|
|
|
* 面试的过程可以轻松自然，但面试本身是一件严肃认真的事情，其中的责任是巨大的。在我第一次参加Bartender培训的时候，讲师说过一句话，我至今记忆犹新：面试对于我们，可能最终只是其中一个必须要做出的决定，但是对于候选人来说，却可能是影响整个职业生涯的事情。我们当然不希望招错人，但是我们也不希望错过优秀和合适的人。
|
|
|
|
|
|
* 面试是一个复杂的活动，但是对于任何一位软件工程师的评估，是一个远比面试复杂得多的活动。**最理想的面试，其实应该是实习。**因为实习会有更充分的时间，通过深入的项目和团队活动，来得到足够多的可信数据，来帮助决策。但是由于人力、时间成本的原因，招人不可能仅靠实习，面试也不会有实习的时长。因此面试的目的，不是做出100%准确的决定，而是要在有限的时间里，尽量通过合理的角度布局，尽可能挖掘到有帮助的信息，从而做出风险范围可接受的决策。
|
|
|
|
|
|
* 我们需要明确的是，时间、人力成本的足够投入，和考察角度的合理覆盖，是两件完全不同且都必不可少的事情。我们希望达到的效果是，面试团队通过足够量的投入，得到了可以帮助评估候选人的较为全面的数据，但却没有过度地重复覆盖某一个角度。
|
|
|
|
|
|
* 每位面试官的标准不同，视角不同，最终很可能这个bar参差不齐。但是Bartender要利用自己的经验和好的实践，去规范和约束整个流程，帮助大家把注意力聚焦在流程上，把判断的依据放在通过面试挖掘到的数据点上。**流程正确了，数据充分了，结果就会是合理的。**
|
|
|
|
|
|
|
|
|
**其次，面试团队的职位和角色匹配上，要遵从一致性原则。**换言之，让工程师来选工程师。
|
|
|
|
|
|
在这个例子中，7轮面试（2轮电话面试+5轮现场面试）中，这里面有4位工程师（这里的Bartender也是工程师），和目标职位的一致程度超过了50%，并且另外两个角色团队经理和产品经理，都是工程师日常工作接触比较密切的角色。
|
|
|
|
|
|
**再次，考察角度、考察重点、考察内容，三者也要遵从一致性原则。**还记得我们[上一讲](https://time.geekbang.org/column/article/359015)介绍的考察角度吗？如果忘记了，不妨回看温习一下。这三者其实是一个从宏观向具体细化的过程，根据考察角度来确定考察重点，而考察内容则是最后的落实。
|
|
|
|
|
|
在这个例子中，纵览考察重点，有3轮考察了代码层面，1轮考察了系统层面，1轮考察了用户接口层面，还有两轮考察了对于软件工程的理解，以及团队匹配度等等。
|
|
|
|
|
|
而具体到了考察内容，电梯系统、限流功能、Email系统等等，你可以看到，无论描述多简洁，这些内容大多都涉及一个实际问题，或者是一个具体的系统。这是和考察重点中的“实际问题的解决”相一致的，这也符合做工程就是要解决实际问题的本质。
|
|
|
|
|
|
从这些内容中，你可能注意到了，“讨论”这个词用得很多。其实，这里面几乎所有的主要考察内容，都是以“讨论”的形式展开的。
|
|
|
|
|
|
讨论可以带来很好的交互性，候选人会具备主动的参与感，也可以帮助面试官获得很多有价值的数据点，我们在后面的课程中还会详细介绍。
|
|
|
|
|
|
**最后，考察轮次需要保持渐进性。**我们这个例子中，你可以看到，电话面试做了一个比较初步的筛查，问题难度也相对较低；而现场面试则给出候选人更有层次性和挑战性的问题，技术层面的难度也相对更高。使用这种方式，我们可以让电话面试能够初步筛选掉不靠谱的人选，让所谓的“细筛”，留到现场面试。
|
|
|
|
|
|
另外，现场面试的最后一列是企业和团队的文化关注点，这部分不同的企业和团队变动比较大。
|
|
|
|
|
|
我上面的这一列的例子来自于Amazon，为了保证面试符合企业文化的基本原则，每一轮都要求赋予一个“[领导力准则](https://www.amazon.jobs/zh/principles)”的考察项，在评估的时候考虑在内。这是一种企业文化深入工作方方面面的途径，有些互联网大厂比较喜欢这种方式。
|
|
|
|
|
|
|
|
|
|
|
|
**当我们理解了团队需要和考察角度，把人选和计划排出来**（一般这个事情是招聘经理或者Bartender主导的），**虽然真正的面试轮次还没正式开始，可是已经成功了一半。**
|
|
|
|
|
|
## 总结与思考
|
|
|
|
|
|
好，上面我以一个具体的例子，详细介绍了面试计划制定的方方面面。在此基础上，我还想对两个相关的常见问题，做出进一步的解释。
|
|
|
|
|
|
### 电话面试与现场面试
|
|
|
|
|
|
为什么不直接奔赴现场，直接搞定现场面试？电话面试的目的是什么？
|
|
|
|
|
|
其实，确实有这么做的。但是，要让候选人直接来公司，见团队，考虑到时间的成本以及交通食宿的开销，有时候代价还是比较大的，对双方都是。因此，电话面试最大的作用，就是用相对较小的代价，“过滤”掉那些明显不靠谱的人。
|
|
|
|
|
|
因此在计划中，电话面试轮次通常会比较少（1~2轮），因而，电话面试要能覆盖到我们最关心的那部分内容。而电话面试的决策，通常也非常迅速，电话面试的面试官互相碰个头，如果通过，招聘经理也觉得没什么大问题，那就可以继续，进入现场面试。
|
|
|
|
|
|
从上面的例子你也可以看到，从技术角度来看，电话面试的难度应该不大，但是又要足以过滤掉那些硬条件不符合，或是明显不能达到面试bar的候选人。
|
|
|
|
|
|
|
|
|
|
|
|
而从非技术角度来看，要重点关心对方是否有一些明确的要求，是否和团队能提供的所匹配。比如说，如果这个职位要求外派出差办公，而候选人不能接受这一点，那就必须要在电话面试或者之前就沟通清楚，以节约大家的时间。
|
|
|
|
|
|
### 应届生与老兵
|
|
|
|
|
|
前一讲已经提到过，应届生与老兵，这是两类截然相反的候选人，我们考察的重点是不同的。对于没什么经验的工程师来说，我们更看重的是潜力；而对于经验丰富的工程师来说，我们更看重的是能力，这从对于系统设计能力的要求上就能看出来。
|
|
|
|
|
|
因此，对于上面的面试计划，如果候选人从7年经验的社招变成了应届，那么可以考虑做的调整有：
|
|
|
|
|
|
* 减少总的面试轮次。通常来说，应届生，或者校园招聘，我们的投入时间成本可以适当减少。
|
|
|
* 去掉系统设计的面试轮次。我们当然可以考察系统设计，但是系统设计不应成为主要的考查内容。对于系统的理解，是一个需要时间和经历逐渐积累的过程。
|
|
|
* 减少对于工程方面理解的考察。如果考察应届生对于项目和任务管理的理解，对于软件工程的理解，往往意义不大，理由同上。
|
|
|
* 增大对于兴趣、热情、学习能力，以及是不是能够接纳意见等“潜力素质”的考察比例。一句话，你觉得他能否在团队的帮助下快速地成长，能不能很快地晋升为高级工程师。
|
|
|
* 增加对于CS基础能力的考察。这部分反映了候选人技术的“底子”牢不牢靠。
|
|
|
|
|
|
“不打无准备之仗”，今天，我介绍了怎样去给面试活动制定计划，希望对你有帮助。有了良好计划的保障，在下一讲，我们就要开始真正接触实际的面试环节了。
|
|
|
|
|
|
|
|
|
|
|
|
好了，在文末，我想知道，你所在的团队，是否为面试做计划，又是怎样安排面试实际考察的角度的呢？你能否在评论区聊一聊？
|
|
|
|
|
|
好，我是四火，我们下一讲见。
|
|
|
|