你好，我是四火。

经历了疫情的特殊一年，又是一个阳光明媚，草长莺飞的五月，招聘季已经到来，很快我们这个讲解技术面试的专栏将迎来尾声，不知道你是否系统学完了这个专栏的内容，并且有所思、有所得呢？

现在，让我们温习和梳理一下，我们在专栏中都学到了哪些内容。我结合每一讲的内容，提炼了课程中重要的知识和观点，为你准备了一张体系化的思维导图，供你查漏补缺。

在这里，我不会面面俱到地覆盖所有要点，而是按照专栏的结构，挑选几个要点回顾，帮你强化记忆，掌握已有的知识技巧。

要点回顾

第一部分：面试准备 / 计划篇

在第一大部分，我们其实讲了三件事情：体系评估，计划制定，以及问题设计。

体系评估很重要，但我们只需要认真仔细地做一次，后续只需要定期调整即可。而对每一位参加现场面试的候选人，面试官都要制定计划，这是一件花不了多少时间，但很容易被忽视的事情。还有问题设计，这需要面试官慢慢积累，逐步调整自己在面试中使用的问题列表。

接下来我把这三件事展开给你说一说。

先来看体系评估。公司和团队，到底需要怎样的技术人才？这就是我们建立整个面试考察评估体系的时候，最最基础的那个问号。

对于候选人的评估体系，大致可分为两个角度：一个是共通部分，就是对于一名优秀的软件工程师普遍的、客观的理解；另一个是特殊部分，指的是不同的团队和细分职位，对于软件工程师候选人，有着不一样的要求。

前者是考察角度的主体，我们经常从技术角度和非技术角度来划分，技术部分包括实际问题解决能力、代码设计和实现能力、系统分析和设计能力和其它综合工程能力，非技术部分包括基础品格、团队合作能力、学习能力、沟通能力，以及任务管理能力等。

其次是计划制定。想要完成一次成功的现场面试，制定计划必不可少。缺乏面试计划，轻则浪费时间，让候选人失望，让面试官尴尬，重则招进来不合适的成员影响团队。

面试计划制定的重点是确定人选（包括两个特殊的角色招聘经理和技术负责人），以及考察内容、考察重点的安排。这里所说的安排需要遵循两个方面的**“一致性”原则**，分别是面试团队的职位和角色匹配上，要遵从一致性原则；以及考察角度、考察重点、考察内容，三者也要遵从一致性原则。

接着是问题设计。在技术面试中，技术问题就是这个面试内容的直接体现，它要围绕考察重点展开，如果技术问题没有设计正确，对于候选人的考察，就不可能靠谱。

技术问题最理想的效果是，问题覆盖了我们要考察的重点，平衡了深度和广度，并且问题的最高难度，恰恰是候选人“踮踮脚能够到”的难度，既不会过度简单，又不会难不可达。

第二部分：面试进行 / 实践篇

专栏的第二大部分，就是讨论真刀真枪面试的流程把控了。只有把控好流程，我们辛苦设计的面试计划、技术问题才会真正派上用场，才能收集到足够的事实数据，全面合理地评估候选人。

这部分主要讲了整体把控流程的原则和技巧，同时我们详细讲了最常见的算法和数据结构考察和系统设计能力考察这两类考察方式怎样实现，还介绍了对于其它工程技能的考察方式。

面试的流程把控，它对面试的质量影响特别大，因此面试官需要始终保持状况的可控，保证最核心的考察项能够覆盖到，同时还能够给候选人留下一个好印象，这里我们学习了一些原则和技巧。

面试，说到底是社交活动的一种，必须建立在平等和尊重的基础上。因此我们要保证整个面试过程有头有尾，在面试中表现得有礼有节。

对于技术面试而言，面试官要抱着和候选人一起做一个有头有尾的迷你项目的心态，这样，不但可以实现广度和深度平衡的考察，还可以令整个面试过程完整。

在问题求解和面试推进过程中，面试官需要选择合适时机介入。如果候选人能力很强，对于问题的推进合理有效，那么面试官就要学会做“绿叶”，给对方更多的发挥空间，让对方去主导问题的解决；反之，如果困难过大，时间落后，或者看着路线要“跑偏”，那么面试官就要毫不犹豫地及时介入，主动调控，保证整个方向和时间可控。

算法和数据结构考察可以说是最经典的一种技术面试考察类型，具体的流程把控上有不少技巧，我使用一个详细的案例向你呈现了，该怎样使用“给出挑战”和“要求澄清”两种方式，不断地推进问题解决。

作为面试官，只要是思考向着大体正确的方向，我们的优先选项一定是顺着候选人的思路走，一起讨论，即便这样的思路不是最佳的。

考察算法和数据结构，编码能力考察往往是必选项，这就牵涉到白板编码的问题。在我看来，白板编码虽然也有不足，但现在却无法被替代。事实上，它是如今现场编码考察的操作方式中，最公平、最直接，且最有效的一种方式了。

相较于算法和数据结构的考察，系统设计能力考察的流程推进和评判标准明显不同，我们往往没法给出丁是丁卯是卯的正误判断，因而面试中更多是讨论可行性，以及对于不同实现方案的利弊权衡。

我们在面试中，一定要摒弃掉所谓的“最佳设计”或者“推荐方案”这样的想法，而是尽量追着候选人的思路跑。换言之，面试官可以主导面试，却不要主导设计。

从具体的考察形式看，主要有两种，一种是让候选人讲他自己熟悉的、做过的系统；另一种是给出一个实际问题，细化、分析，延伸成一个对于核心功能的系统设计问题，并加以讨论和解决。这两者，我们都结合实际案例做了详细说明。

最后是其它技能考察，近几年来大家对于软件工程师的全面性要求越来越高，考察的类型也愈发多样。面向对象考察就是其中一种，它通常包含了两个方面，一方面是考察代码层面的面向对象设计能力，另一方面则是综合代码组织的能力。

还有 API 设计考察、测试能力考察和项目、任务管理能力考察等等，这些项虽然看起来琐碎，但随着对软件工程师候选人的全面性要求越来越高，你也不要忽视它们。

对于行为型问题的考察，我们不但学习了背后的逻辑（即候选人在过去遇到困难的时候，遵循的逻辑和采取的行为，这相当程度上反映了未来候选人将怎样应对类似的困难），还重点讲了操作要点的四大关键步骤，即**“情境”、“思考”、“应对”和“结果”。**

第三部分：面试反馈 / 决策篇

第三大部分围绕着面试之后的决策展开。也就是我们该怎样收集事实、提炼数据，并在决策会中对候选人做出全面和有深度的评估决策。

首先在收集事实数据，书写面试反馈方面，使用反馈模板这个技巧用处很大。具体操作上需要注意，一个是要保证包含面试考察最关心的点；另一个是模板要简单、直接，因为越简单、直接，可操作性就越强。我给出的参考模板包含了考察重点和主要考察内容，优势和不足，以及综合结论这样几个部分。

接着就是决策会了。决策会，就是大家碰头商讨候选人情况，达成面试共识的过程，这个环节很重要，且没有其它方式替代。

决策会有不少典型误区，我在文中介绍了几个，我们尤其要避免**“将决策行为变成民主选举”**这个非常常见的做法。我们要关注的是，决策背后的逻辑是不是合理，而非人数是不是占优。

我们介绍的决策会流程，可以大致分为三个环节：初始投票、反馈陈述，争辩开展与共识达成。其中，对于 Bartender 来说，最具挑战性的是在第三环节中，怎样汇总建议，收敛分歧，达成共识，为此我们一起专门讨论了一些方法技巧。

场景再现

在场景再现模块，我跟你探讨了两个专题内容，第一个是关于线上面试的。线上面试既包括传统的电话面试，也包括由于疫情等原因，移到线上进行的现场面试。

其中，对于电话面试广度和深度的平衡，我的建议是更重视广度覆盖，掌握好基本情况，把基本问题排查清楚，因为电话面试的最大的价值其实就是初筛。在后续的讨论中，我分享了线上面试的一些技巧，并给出了一个具体的案例帮助你理解。

第二个专题是关于简历识人的。面试官去认识候选人，未见其人，未闻其声，先读简历，从简历这短短的文字中，可以看出候选人的诸多品质。尤其结合面试的流程，这里面更有一些重要的技巧。

面试前，简历可以帮助确认职位的匹配情况，也可以帮助面试官收集候选人技术背景等重要的信息。面试中，简历可以作为切入点，面试官可以和候选人聊经历，深挖其中的事实数据。而在面试后，简历也能作为候选人评估的参考内容。

结课寄语

天下没有不散的筵席，专栏到这里，也要告一段落了。相信你也已经看到，小小面试的背后，水确实很深。正所谓“操千曲而后晓声，观千剑而后识器”，技术面试也需要你学以致用，在实践中深化认识。

如果你把专栏的学习、你自己的思考，与后续具体的面试实践三者结合起来，反复地操练，不断完善你自己的面试原则和方法论，这趟旅程才算真正“功德圆满”。

在你未来的职业生涯发展的道路上，我很期待这个专栏带给你的启发和收获，能成为真正助力的一步。希望疫情尽快过去，祝愿你的公司和团队能够招募到合适的人才，愿你百尺竿头，更进一步。

在这个专栏结束之际，不知道你是否有所收获呢？

我想听听你的看法。欢迎你继续在留言区发表观点，专栏更新结束了，但专栏的问答和讨论并没有结束。

此外，如果你对全栈开发感兴趣的话，我在之前还写过另一个专栏《全栈工程师修炼指南》，也欢迎你移步阅读。

最后，我还为你准备了一份调查问卷，题目不多，希望你可以花两分钟填一下。十分期待能听到你的反馈，说说你对这门课程的想法和建议。

好，我是四火，我们后会有期！