mod

极客时间专栏/技术面试官识人手册/面试准备|计划篇/01 | 评估体系：公司和团队到底需要怎样的技术人才？.md

@@ -0,0 +1,190 @@
+<audio id="audio" title="01 | 评估体系：公司和团队到底需要怎样的技术人才？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/1f/ef/1f75cd5cbde26a2c74a935bfa7823fef.mp3"></audio>
+
+你好，我是四火。
+
+孙子兵法中，有句话叫做“胜兵先胜而后求战，败兵先战而后求胜”，这句话的意思是说，胜利的军队总是先制造胜利的态势然后向敌方挑战，失败的军队则反过来，先发起交战，然后在作战中求得侥幸的胜利。
+
+招聘和面试的过程，就如同一场大战，在我们正式开始讨论招聘和面试过程的话题之前，我们需要把初衷搞清楚，把对于软件工程师候选人考察的策略大体订立清楚，做到心中有谱，以“先胜后战”。
+
+大公司也好，小公司也罢，招人，就需要面试，这我们都知道。可是公司和团队，到底需要怎样的技术人才？这就是我们建立整个面试考察评估体系的时候，最最基础的那个问号。
+
+## 常见答案
+
+在回答这个问题之前，我们先来看看一些常见的答案。
+
+<li>
+<h3>“能干活的，能加班的”</h3>
+</li>
+
+我相信给出这个答案的大有人在，我听过这样的说法：“软件的架构都已经做好了，设计都已经完成了，现在需要的就是普通劳动力，把代码填上。”
+
+在我看来，这种初衷可以理解，但实施起来却非常困难。也许在某些行业这的确是可行的，但是在软件工程的世界里却恰恰相反。
+
+究其原因，是持有这个观点的人，把软件工程这个复杂的行为，使用简单的劳动分工来划分了。在历史上，这样的做法并非没有人尝试过，只不过大多数的尝试都失败了，或是最终令它的其它环节成本，高到失去了这样做的意义。
+
+这是为何？
+
+让我来进一步解释一下。比方说，我们可以把软件工程的流程简单地分为需求、设计、实现、测试、维护等几个步骤。当我们将“实现”环节的人员要求降低，也相应地将质量要求降低，那么我们就将迫不得已在其它环节投入更多的人力去平衡，最终导致研发成本并没有得到本质上的改善，反而在实现环节埋下隐患，比如糟糕的代码设计为未来的维护和扩展挖坑。
+
+这样的平衡，可能是花更多时间来完成更细致的设计文档，可能是添加更多的测试人手和执行更全面的测试，也可能是花更长时间试运行版本和bug修复，还可能是招更多的、专门的管理人员来盯着这些程序员严格遵守流程。
+
+**说白了，就是在软件工程的其它环节做更多的工作，然后给糟糕的实现环节擦屁股和买单。**
+
+<li>
+<h3>“算法好的”</h3>
+</li>
+
+这是第二个常见的答案，但有意思的是，这个答案却很少从有经验的团队负责人或者招聘人员那里听到，而更多地是从踏入职场没多久的候选人那里听到。在我见到的面试实践中，这也确实是一个普遍现象。**好端端一个软件工程师的面试，最后变成了刷题成果检验会。**这个现象，你是不是也觉得似曾相识？
+
+那么，为什么这样的观点是错误的？
+
+**原因很简单，用四个字来概括，就是“以偏概全”。**
+
+软件工程是一个多维度的、复杂的行为，代码实现只是其中的一个部分；而算法，更只是代码实现的其中一个部分。单纯的算法牛人离真正的软件工程师，其实还差了十万八千里。
+
+也许你会有这样的问题，那既然单纯的算法面试如此片面，为什么还有那么多公司如此频繁地使用它？别急，我在这里先卖个关子，因为我会在这个专栏中慢慢展开来讲，详细告诉你这是为什么。
+
+<li>
+<h3>“牛人”</h3>
+</li>
+
+这也是一个常见的答案，我不能简单地说这是一个错误的答案，因为“牛人”二字的定义实在是不明确。如果我们把这里的“牛人”理解成“技术杰出的人”是否就正确了呢？
+
+我觉得，这依然不正确。相较于“牛人”，团队更需要的是“合适的人”。
+
+先从技术角度来说。**理想的团队，技术层面上是需要在一定程度上互补的。**比方说，在一个全栈的团队中，有的成员擅长系统底层，有的擅长Web应用；有的系统思维严谨，有的产品直觉敏锐，那么无论在系统设计还是在问题定位的时候，团队的决策就可以因为取长补短而达到一定的平衡。
+
+再从非技术角度来说。即便在技术层面候选人已经无可挑剔，我们都还有很多非技术因素需要考虑；即便在个人的非技术层面已经无可指摘，我们依然需要考虑候选人和团队风格的契合程度。举例来说，某些技术特别出色的人，个性更为鲜明，或者说不易相处。我们应该对这样的候选人说yes还是no？
+
+这就要牵涉到一个公司的文化，以及团队的接纳程度了。显而易见的是，一个团队里面，如果全都是“刺儿头”，到处是激烈的观点碰撞，这肯定是一个糟糕的状况，很可能经理每天要忙于摆平冲突；而一个团队里面，如果全是“老好人”，只有赞美和观点认可，这其实也是一个令人担忧的状况，因为缺乏观点往往就意味着决策力的缺乏。
+
+<li>
+<h3>“聪明、有潜力的”</h3>
+</li>
+
+这一类回答，主要是针对职场经验尚浅的候选人来说的。
+
+一家公司也好，一个团队也好，有经验的工程师和有潜力的工程师，需要在构成上达成一定的平衡。
+
+有的团队相对技术成熟，架构稳定，流程确凿，而有经验的工程师可以有一定的时间来指导和帮助新人成长，团队可以培养自己的骨干，那么这样的候选人可以说是再好不过了。
+
+而有的团队则相反，特别是某些创业团队，或是产品初创团队，每个人都要挑大梁，甚至大家都忙于救火，那么这种情况就特别需要自我管理能力强、综合素质和经验皆备的老兵，这时这样的候选人就不适合。
+
+你看，团队需要怎样的技术人才？这个问题并不是那么好回答的。
+
+## 考察角度
+
+那么，不回避问题，公司和团队到底需要怎样的技术人才？或者说，反映在面试中，我们应该从怎样的角度去考察和甄选人才？
+
+我将分两个部分来回答这个问题。在这一讲我将谈谈，从宏观上怎样去把握软件工程师候选人甄选的维度；而在下一讲我将结合实际案例来分解面试计划，讲解在操作上的要点。
+
+好，我认为，首先我们要充分认识职位，这里面既包括职位在普遍认知中所具备的共通部分，也是主要部分；又包括特定职位特殊的要求，这有时只占小部分比例，但也不可或缺。
+
+### 共通部分
+
+**共通部分，说白了，就是对于一名优秀的软件工程师普遍的、客观的理解。**
+
+我们来看一个真实的例子，以下是一段来自某互联网公司的职位描述：
+
+> 
+<p>1.扎实的编程和数据结构算法基础，深入理解面向对象编程思想，具有较强的设计能力。<br>
+2.具有较强的分析和解决问题的能力，有强烈的责任心和团队精神，善于沟通合作。<br>
+3.具有音视频、直播、OpenGL相关开发经验者优先。</p>
+
+
+非常精简，但也很有代表性。短短的几条描述，就已经包含了下面我要讲的关于人才甄选共通（第1、2点）和特殊（第3点）这两个部分，并且也包含了技术和非技术这两个对立的范畴。
+
+#### 技术层面
+
+技术层面上，我们要考察软件工程师的基础技能。包括：实际问题解决能力，代码设计和实现能力，系统分析设计能力，测试和验证的能力。
+
+**首先是关于实际问题解决能力**，工程师毕竟是要做工程的，做工程的目的就是要解决实际问题。
+
+这也是为什么，我不赞成面试中，较多地使用单纯的算法和数据结构问题。不是因为它不具备考察性，而是它的覆盖面太窄，具体说，一个典型的实际问题的解决，需要包含两个部分：
+
+1.**把具体问题抽象成若干个可解决的软件问题；**<br>
+2.**使用软件工程的知识与技能去解决这些问题。**
+
+而单纯的算法和数据结构问题，不但只能解决上述两点中的第二点，而且这第二点还必须得是一个落得到编码层面、甚至数学层面上的问题，足见其覆盖面之窄。至于怎样的问题才是一个好的面试问题，我们在专栏的后文中会去专门讨论。
+
+**其次是代码设计和实现能力**，这是软件工程师的基础技能，就如同厨师切菜和钢琴师读谱一样，都是看家本领，技术面试要花相当比例的时间来验证这一点。
+
+但请注意，即便只讨论这一点，它涵盖的范围也比单纯的算法和数据结构广泛得多了，像是有些公司特别喜欢考察的面向对象就属于这个范畴。
+
+**再次是系统分析和设计能力**，包括是否能够针对问题给出合理的系统估算、架构设计等等。这一部分是和经验密切挂钩的。
+
+对于代码实现层面，可以简单地认为，无论是刚工作1年的新手，还是工作15年的老兵，预期上当然会有差别，但并不那么大。
+
+但是，如果是系统的分析和设计能力，就截然相反了，一般来说，丰富的工作经验，理应意味着一定的系统分析和设计能力，我们可以简单这样认为：
+
+<img src="https://static001.geekbang.org/resource/image/e9/68/e96efda992e3d6daa38551f48b42ca68.png" alt="">
+
+需要强调的是，这里说的“系统”是泛指的“软件系统”，而不是“分布式系统”。
+
+这么强调是因为我觉得，如今的互联网的浪潮，给技术人也带来了一些不太好的影响，比如过度追捧“分布式”这样的热门词汇。仿佛谈及系统，就是大数据、海量、高吞吐，一些简单的系统都不太瞧得上了，我觉得这是很不妥的。
+
+对于系统的理解，就如同数学的基础是初等算术一样，还是要把根基打扎实。
+
+**剩下的共通的技术层面的部分，我觉得可以叫做“其它综合工程能力”**，比如测试与验证的能力等等。不是说它们不重要，也不是说不考察，而是说，在面试中，对于软件工程师的技术考察，我们要有所侧重。比方说，我们可以简单地约定只把20%的技术考察时间，放在这部分。
+
+你也许会问，**计算机的基础知识考察在哪里啊？其实，它就蕴藏在上述的考察项之中。**对于这些分项的考察，是不可能脱离扎实的计算机基础知识来进行的。
+
+比方说，要设计一个网站系统，要有对于网络协议，特别是HTTP协议的基础认识吧，要有对于中间件、容器的基础知识吧，还要有对于数据库的基础理解吧。
+
+在实际面试和考察的过程中，专业技术层面的指标相对容易辨别、容易执行，也往往是作为一个“技术人”的考察重点，我们也确实会花很多时间、设计很多方法在这一部分。但是非技术层面，却容易被具备软件工程师背景的面试官所轻视。
+
+#### 非技术层面
+
+那我们就再来说说非技术层面。**我们关注工程师的基础品格、团队合作能力、学习能力、沟通能力，以及任务管理能力等等。**
+
+在非技术层面，单纯地分项考察有时候会比较困难，也很难覆盖所有我们关心的点（但并不是不能做，我在后续会介绍一些方法）。但我们每一个人，其实都带着我们对于职业素养的基本认知，如果某一点上出了问题，我们会察觉到的。因此多数情况下，我们只需要对于技术面试中发生的一切，保持敏锐。
+
+举例来说，面试中，如果你发现与候选人的沟通存在很大问题，那么你不可能不留意到这一点，而根本不需要特别地去问一个“专门”考察沟通能力的问题。
+
+综上，对于软件工程师的候选人来说，面试的轮次要保证大部分都以技术面试的形式覆盖，而允许少部分以非技术面试的形式覆盖（比如5轮中有4轮技术面试，1轮非技术面试）。但是每一轮技术面试拿到的数据，却应当同时覆盖二者。
+
+举例来说，技术面试中，候选人被要求设计一个短网址系统。候选人二话不说，上来就开始绘制系统组件图，既不确认功能性需求，也不讨论非功能性需求。
+
+面对这样的情况，面试官可能会觉得，候选人缺乏良好的问题澄清和沟通的习惯。也就是说，我们在技术面试的轮次中，也会得到一些非技术层面的数据。**即我们并没有在这个轮次的考察中特别地规划这个非技术考察项，但是我们却得到了关于它的考察数据。**
+
+在技术层面，我们谈到了针对不同工作经验的候选人，我们考察项的不同侧重，而在非技术层面，这里也有一样的情况。
+
+**对于踏入职场不久的工程师，要更关注潜力相关的素质**，比如是否能够听从建议并加以思考，以及是否具备兴趣与热情，因为这是学不到的东西。
+
+**而对于有丰富经验的工程师，要更关注视野，技术理解的深度，以及职业素养。**
+
+也就是说，“经验”，不是体现在年头上，不是体现在更复杂的算法和更高级的数据结构上，也不是体现在记忆那些晦涩难懂的参数配置上，而是对于软件系统的理解，对于团队和产品的理解，对于软件工程的理解。
+
+这有点像足球俱乐部的建制，引入年轻球员更多考虑的是未来和潜力，而引入老兵则是要带来立竿见影的效果。
+
+### 特殊部分
+
+特殊的部分，指的是不同的团队和细分职位，对于软件工程师候选人，有着不一样的要求。
+
+技术层面上，比方说有一些职位要求具备前端技能，有一些职位要求具备AI背景，而有的团队则要求云计算方面的工作经验。
+
+在非技术层面，很多大厂都会设置几条特定的指导原则，这些原则就像纲领一样，指导对于候选人非技术部分评估的过程。比如[亚马逊的领导力准则](https://www.amazon.jobs/zh/principles)，这几年来讨论的人很多，在亚马逊每一轮面试都会被要求覆盖其中的一到两条。
+
+好，上面就是我们从宏观上，从公司和团队的需要出发，对于面试的考察角度，所应具备的大体认识。
+
+你可能注意到了，即便某一特定的细分职位，对于技能有着较为细致和明确的需求，我们还是可以发现，对于大厂的面试，往往共通部分所占比例就越大，我想在这里解释一下原因。
+
+显而易见的是，越细分的职位，越特定的要求，就越能够提高候选人的匹配度，但是这也降低了人才筛选的普适性，让招聘变得无比困难。因此，这些大厂，给出了模糊的招聘标准，而选择在招进来以后，做进一步地培养。这既是刻意为之，也是无奈之举。
+
+但请注意，这里面也蕴含了一个简单的道理，**一个面试中在“共通”部分表现优秀的软件工程师，更可能就是一个通常意义上的优秀的软件工程师，那么就算他并不立即具备特定职位的某项技能，但是经过较短时间的学习和融入，他也很可能可以很快地胜任这个职位。**
+
+关于职位细分，我还想拓展一点，谈一下我对于开篇词中那个“培养起来跑掉了怎么办”担忧的看法。
+
+在前文中，我已经提到，对于任何一个公司和团队来说，都不是要招“牛人”，而是要招“合适的人”，**我们大的目标是和候选人一起共赢，而不是单纯的劳动性价比。**
+
+无论是领域、薪酬，还是工作内容，大家接触到的信息都是开放的，候选人和公司如果各自都能够在大体上得到想要的，就可以在一定程度上缓解这种担忧，你也可以不用太担心这个跑路的问题。
+
+## 总结与思考
+
+面试就像打仗，在打仗之前，我们要高屋建瓴，预先做好规划。因此，作为第一讲，今天我们介绍了，从团队需要的角度出发，宏观上该从怎样的角度去考察软件工程师候选人。这同时包括了技术层面以及非技术层面的关注点。
+
+<img src="https://static001.geekbang.org/resource/image/f0/1a/f0217d59ee4cbcc999394e5569fa2c1a.jpg" alt="">
+
+在最后，我想知道，你的团队又是从怎样的角度招人的呢，能否分享一下？欢迎在留言区一起讨论。
+
+好，我是四火，我们下一讲见。

极客时间专栏/技术面试官识人手册/面试准备|计划篇/02 | 制定计划：好的计划是成功的一半.md

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

极客时间专栏/技术面试官识人手册/面试准备|计划篇/03 | 问题设计（上）：三大原则理清面试考察方向.md

@@ -0,0 +1,192 @@
+<audio id="audio" title="03 | 问题设计（上）：三大原则理清面试考察方向" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/37/fe/37b766c2880b79ce90a3590c22c364fe.mp3"></audio>
+
+你好，我是四火。
+
+相信你在学习了[第02讲](https://time.geekbang.org/column/article/360268)的面试计划之后，心中对于它已经有了更深入的理解。
+
+我们在面试计划中，谈到了规划合适的面试内容，来帮助我们获取面试重点所对应的数据。而在技术面试中，技术问题就是这个面试内容的直接体现。
+
+我们也重点提到了，这个过程中，考察角度、考察重点、考察内容，三者要遵从一致性原则。因此，如果技术问题没有设计正确，对于候选人的考察，就不可能靠谱。
+
+那么接下来的两讲，我就来说说，具体怎么去设计“合适”的技术问题。这一讲我会先从反面介绍几个糟糕的技术问题典型，再从正面讲讲技术问题设计的原则；下一讲我会介绍一些技术问题的设计技巧，以及一些实践中的注意点。
+
+相信在学习完这两讲之后，你对怎样设计技术问题就能做到心中有谱了。
+
+## 糟糕的技术问题
+
+首先，让我们来看几个典型的、在面试中不断被使用的技术问题，看看你有没有似曾相识的感觉。
+
+下面这样的问题，可以在适合的场合下快速地使用，但是，通常来说却是不适合作为面试的“主要”问题的，换句话说，这些问题并不适合花大量的时间和候选人去讨论、分析和解决。
+
+### 知识性的问题
+
+**有一些问题，是知识性的，这一类问题，考察的是知识，是记忆力，而不是任何一项工程师的核心能力。**举例来说，有这样的问题：
+
+> 
+“对于OA系统，我们该怎样配置Tomcat？”
+
+
+为什么说这个问题不好呢？这是因为这里抠了一个Tomcat配置的细节：
+
+- 首先，如果候选人不了解Tomcat，回答不了这个问题呢？是不是就可以认为这是一个负面的考察数据？
+- 其次，就算候选人了解Tomcat，但是具体配置项记不起来了呢？这是否又可以成为一个负面的考察数据？
+
+这一类问题，我们简单地称其为“知识性问题”，在技术面试中，我们通常就应该避免。**因为一方面它不具备普适性，另一方面它又具备太强的随机性。**
+
+不具备普适性，指的是候选人必须要了解特定的框架或者库，考虑到优秀的候选人的知识背景有所区别，所以这一要求过于武断；而太强的随机性，指的是候选人是否知道这一个知识点，随机性太强，而并不能反映候选人的技能水准。
+
+<img src="https://static001.geekbang.org/resource/image/76/22/7647ea2212f10bcca5d49b2c3e4f4522.jpg" alt="">
+
+另外，**有一些问题并不像上面的例子那么直接，但是本质上有类似性。特定编程语言、框架和库限定下的问题就是其中之一**，比如：
+
+> 
+“请实现C++的atoi算法。”
+
+
+这个问题，如果团队就是要求候选人必须具备C++技能，那没什么问题；但是对于大多数团队来说，情况并非如此，那么这个问题就对平时以Java为主要编程语言的候选人不太公平了。这也是为什么，很多大厂对于面试流程的培训中，有一条指导原则：不限制候选人使用的编程语言。
+
+还有一些问题，可能有一些隐含的知识，或者说“背景知识”前提蕴藏在问题中，而这样的知识从面试角度来看，又不是我们关心的。
+
+这一类问题需要注意，可以问，但这部分背景知识最好是众所周知的“常识”，倘若候选人不知道，那就应该最直接快速地告诉他，而不应该把时间浪费在它上面。比如说：
+
+> 
+“请设计一个算法，把十进制的数字，用罗马数字来表示。”
+
+
+你看，这看似是一个挺好的问题，可假如说候选人不知道罗马数字的[书写规则](https://zh.wikipedia.org/wiki/%E7%BD%97%E9%A9%AC%E6%95%B0%E5%AD%97#%E6%8B%BC%E5%AF%AB%E8%A6%8F%E5%89%87)，是不是就卡壳了？而罗马数字的书写规则是我们对软件工程师候选人考察的内容吗？显然不是。
+
+你可能会问，那么假如候选人知道这个规则，是不是就可以问了？
+
+原则上没错，可前面已经提到了，我们需要的问题是具有“普适性”的，这样我们才能**把这个问题频繁地拿出来问，积累足够多的、可以用于比较的数据**。好问题千千万，何必死磕这一类呢？
+
+你还可能会问，那我要是告知候选人这个规则，是不是这就变成一个好问题了呢？说得好，可答案依然是否定的，至于原因，我先卖个关子，你不妨先想一想。
+
+### 过于常见的问题
+
+这一类问题，我想应该很容易理解吧，但是我们却经常见到。举例来说，算法题有：
+
+> 
+“请对二叉树做一次先序遍历。”
+
+
+系统设计问题有：
+
+> 
+“请设计一个URL短网址系统。”
+
+
+我们考察候选人，是希望得到真实的数据，而被使用太多遍的问题，很有可能就是候选人准备好了的，这就让考察的真实性大打折扣了。诚实的候选人会告诉你，这题我做过了，但你不能奢望每个候选人都如是操作。
+
+每一个面试官，随着经验与时间的积累，自己应该有那么两三个“杀手锏”问题。这样的问题经得起多次面试中询问的考验，并且积累了足够的数据，而更重要的是，这样的问题要具备一定的“独特性”，是候选人通常准备不到的。
+
+另外，这里我必须要强调一下，我们这里是指问题本身不要过于常见，而不是说，“问题类型”和背后的“原理”不要过于常见。
+
+**相反，我们恰恰就是要通过“新”问题考察候选人的“旧”能力。这就是为什么我们说，问题是多变的，但套路是永恒的。**
+
+因为这些套路恰恰就是，软件工程师得以在问题的千变万化中，依然能够游刃有余地分析和解决它们的原因。比方说，URL短网址系统的设计问题都被考烂了，但是背后的系统设计的考察要素，比如对于网络协议的理解、系统容量的估计、存储技术的选型等等，都是非常好的具体考察点。
+
+### 规则过于复杂的问题
+
+再回到前面提到的罗马数字的问题：
+
+> 
+“请设计一个算法，把十进制的数字，用罗马数字来表示。”
+
+
+为什么即便告知候选人规则，这依然不是一个好问题呢？因为这就可能是一个“规则过于复杂”的典型例子。因为如果候选人对罗马数字一无所知，那么把罗马数字的规则前前后后都讲清楚，怎么也得花费十多分钟的时间。
+
+因此这样的问题，往往就不是一个好问题，毕竟，我们要把宝贵的时间尽量地分配到考察的重点内容上。
+
+<img src="https://static001.geekbang.org/resource/image/53/01/53219e1ebeb3bb41ce0b25c920c9d701.jpg" alt=""><br>
+当然，这样的问题也不是不能“抢救”一下的。同样是考察代码层面的能力，如果我们给这个问题加一个小小的限制，比如，我们只考虑二十以内的数字，我们假设输入都是正确的等等，规则就会简单不少，那么，候选人就可以把精力集中在核心实现上。
+
+需要说明的是，**复杂问题的简化途径，和考察项是密切相关的。**如果你就要考察候选人，是不是能够对各种场景考虑周全，那么就不要假设输入都是正确的，而让候选人自己去进行必要的输入判断和错误处理。
+
+## 技术问题的设计原则
+
+好，上面我们谈到了几个糟糕的技术问题，这是反面典型。接下来我们就从正面来谈谈，到底应该把握怎样的原则去设计和选择技术问题，以及到底怎样的问题才是好问题吧。
+
+### 和考察角度、考察重点保持一致
+
+不知你是否还记得，我们之前[第02讲](https://time.geekbang.org/column/article/360268)里，关于制定计划的内容，面试内容，就是要和考察角度、考察重点保持一致的。我们的目标，是和候选人一起来解决这个技术问题，在这个过程中，我们可以围绕它来获得有效考察数据，从而便于我们在面试后做出决策。
+
+举个例子，某面试官要对候选人进行面试考察，重点是“实际问题的解决以及对系统的理解”。于是，他决定使用一个“网约车系统的设计”问题来作为主要问题，在面试中和候选人一起讨论。那么，从这里我们大致可以看出，面试官需要把握这两个要点：
+
+- 实际问题的解决：面试官打算给出实际问题，关注候选人是不是能够逐步通过工程师的技能，把这个“网约车”（比如滴滴打车，这就是一个实际的系统）实际问题中最核心的部分，简化和抽象为软件问题，并加以解决。
+- 对系统的理解：面试官打算在和候选人讨论清楚需求后，要求候选人设计一个软件系统来实现它，这个过程中重点关注候选人是不是有系统设计的技能，以及是不是能够根据问题的特点，做出合适的技术选择。
+
+对于怎样执行这个要点把握，还是不够明确对不对？别急，我们接着看，我会在接下来的技术问题设计原则中，完整地把它描述出来。
+
+### 从模糊到清晰，从实际到抽象
+
+你读到这里，可能会问，从模糊到清晰可以理解，可是什么是从实际到抽象呢？难道不应该是从抽象到实际吗？只有落到实际才能够实现啊！
+
+别急，我这就来做一个解释。从专栏一开始我就讲到，软件工程师，就是要做工程的，而做工程，从本质上说，就是要解决实际问题的。
+
+这里说的从模糊到清晰，以及从实际到抽象，看似是两个过程，但其实它们恰恰是统一的：实际问题，往往就是模糊的，它可能来源于顾客的一句抱怨，用户的一个建议，或是一个不明不白的痛点；而软件途径可以解的问题，必须是清晰的、简单的，如果连软件的设计人员自己都说不清楚需求和逻辑，实现就无从谈起了，既然能够说清楚，这个描述肯定是经过了简化和抽象，去掉了细枝末节，只保留问题的核心。
+
+因此，一个具体问题只会有某些核心的部分可以通过软件来解决，而余下的大部分只能是作为陪衬。**这一条原则，其实谈的是“深度”。**
+
+这个对实际问题的简化和抽象的过程，正是软件工程师的重要能力，并且它还和实打实的经验密切相关。
+
+我前面提到过，**纯算法题当然可以拿来问，但是我通常是不推荐的，因为考察面太窄，这样的问题本身就已经是一个经过抽象和简化了的数学问题了。**或者说，直接讨论这样的问题，就失去了将实际问题简化和抽象成软件工程可解的问题，这样一个非常有价值的过程。
+
+<img src="https://static001.geekbang.org/resource/image/82/2c/824f0d0591afc95cca97a3460ce6852c.jpg" alt="">
+
+我接着前面的例子来讲。面试官向候选人提出了这样的技术问题：
+
+> 
+“请你设计一个网约车系统。”
+
+
+就这样简简单单一句话，有些候选人拿到问题以后，会不知所措，“天呐，我该从何下手？”没错，这个问题看起来就非常大，但这也是一个实际问题，工程师要去解决的，经常就是模糊的实际问题。
+
+因此，我们希望和候选人一起，做出这样一个将问题从模糊到清晰，从实际到抽象的转化过程，以系统设计的考察路径为例：
+
+1. 根据模糊的表述，明确我们要解决的核心问题是什么？网约车系统那么大，解决问题中，哪一类问题是我们最关注的。
+1. 根据我们明确了的最关注的问题，列出相关的功能需求和非功能需求。需求可能包含很多，我们的目标是从中确定在面试时间内关心的部分。
+1. 根据需求进行系统设计，包括从客户端、网络、service到存储等等各层，有了大致的方案以后，我们的目标是从中筛选出我们最关心的一小部分展开讨论。
+1. 如果还要考察代码层面，那么就从上述的设计中选取某一个组件，某一个机制，讨论代码层面的设计。
+1. 根据代码层面的设计，择要实现，比如可以要求实现核心逻辑，核心数据结构等等。
+
+从中你可以看出，整个思路是这样的：
+
+> 
+问题&gt;需求&gt;系统设计&gt;代码设计&gt;代码实现
+
+
+**这不就是一个做迷你项目开发的过程吗？没错！虽然说，为了可操作性，每前进一步，都会缩小范围，纵深地考察候选人不同层次的技能。**用一个图示来表示的话，正像一个漏斗：
+
+<img src="https://static001.geekbang.org/resource/image/02/3d/02e4b9c2833227f2ab4cee7472e07f3d.png" alt="">
+
+需要说明的是，这就是一个最完整的典型系统设计考察路径，我们不一定要覆盖全部的步骤，但是我观察到许多面试官会覆盖前三步，或是将代码层面的考察，替代为深挖某一个组件或某一个机制的技术选型与trade off。
+
+### 不止一个考察角度，不止一个解
+
+这里说的“不止一个考察角度”，指的是一开始同样模糊的描述，可以根据面试计划中的安排，逐步引导到某一个特定的考察角度上去。**这一条原则，其实谈的是“广度”。**
+
+比方说，就上面提到的这个网约车系统的模糊问题，我们走的是一条系统设计考察的路径。
+
+但是如果考察重点要求我们走一条数据结构和算法考察的路径，那也是可以的，比如从起点到终点的简单的寻路算法，落地到代码；我们还可以走面向对象设计考察的路径，设计关键用例中涉及到的类，包括它们的结构和关联关系，等等。
+
+跟随每一条路径，都一样可以逐步细化、抽象到一个具体的、软件可解的问题。
+
+这里说的“不止一个解”，指的是在更低一级的层面，在细化到上述的具体的问题之后，解答不应该是唯一的，而应该存在多种不同的方法。比方说，寻路类的算法问题，我们有时可以用暴力回溯法来解，有时候可以用经过优化的动态规划方法来解，等等。
+
+事实上，做面试官的一大乐趣正在此——可以和不同的候选人，一起讨论一些自己已经思考过、应用过的技术问题，看到不同人新颖的思路，有些很巧妙，有些很周全。
+
+## 总结与思考
+
+好，今天我们通过正反两个角度，先从反面介绍了几个糟糕的技术问题典型，再从正面结合例子讲解了我们该把握怎样的技术问题设计原则。
+
+这些设计原则中，我想再谈一谈“从模糊到清晰，从实际到抽象”这一点。我们要看到的是，并不是所有的候选人都可以非常顺利地将一个模糊问题逐步细化清晰的，我们自然也不能复制同一套流程。
+
+我的建议是，**越是软件经验丰富的候选人，我们就越可以给一个较为模糊的问题，尽量让他来主导这个分解和细化的过程；**而对于校招生，我们则可以给一个相对清晰具体的需求。当然，在这个过程中，如果发现难度过高，我们可以积极地给出提示，或者帮助他完成部分过程，这都是在合理范围内的。
+
+<img src="https://static001.geekbang.org/resource/image/c0/66/c03acb8dee37c9857f8c8fd63b204166.jpg" alt="">
+
+好，今天的内容就是这些，如果你觉得在大方向上有数了，但是还不是特别有谱，那也别着急，因为在下一讲，我会继续讲解技术问题的设计技巧，以及实践中的注意点。在该过程中，我会将例子完全地展开。
+
+最后，我想和你交流一下，你能否谈一谈，在你的面试经历中，是否遇到过糟糕的技术问题，而它们又为什么糟糕呢？
+
+好，我是四火，我们下一讲见。

极客时间专栏/技术面试官识人手册/面试准备|计划篇/04 | 问题设计（下）：五个技巧助攻技术问题设计.md

@@ -0,0 +1,152 @@
+<audio id="audio" title="04 | 问题设计（下）：五个技巧助攻技术问题设计" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/36/73/365ea7a38ef5b78d1519ddf3e909e273.mp3"></audio>
+
+你好，我是四火。
+
+在[上一讲](https://time.geekbang.org/column/article/361420)我们学习了技术问题设计的原则之后，今天我们将继续结合实例，围绕原则来进一步分享一些技术问题的设计技巧，以及一些实践中的注意点。希望在这一讲之后，你可以真正掌握技术问题设计的技巧，真正做到“手边有粮，心中不慌”。
+
+## 技术问题的设计技巧
+
+下面我将逐条讲解技术问题的设计技巧，这些技巧看似都有各自的独立性，但是其实它们是围绕着领域、深度和广度这三个方面展开的，我将给出尽可能具体和完整的例子，来帮助你理解。
+
+### 从熟悉的领域设计问题
+
+在具体实践方面，这是第一条，也是最重要的一条技巧。**什么样的问题，哪怕在发散性探讨时，你依然觉得尽在掌握？那一定是自己熟悉的。**相信每一个人都有特别熟悉的领域，举个例子来说，我有一位朋友，也是一位面试官，他在亚马逊工作了9年，他喜欢和候选人探讨的一个问题是：
+
+> 
+“如果你从头设计亚马逊（或是其它大型电商）的零售业务，你打算怎么做？”
+
+
+其实这就是一个挺好的问题，话题描述很容易理解，但又足够模糊、足够宽泛，而且可以有很多不同的角度来切入并细化。最重要的是，对他来说，这个领域太熟悉了，基本上不存在明显的思路盲区。
+
+当然，这个问题的领域也必须是“大众”所熟知的，你要是问一个冷门话题，就有可能偏离了考察方向（具体请参考[第3讲](https://time.geekbang.org/column/article/361420)，我在其中做了详细说明）。如果你的工作领域并不为大家所熟知，那么从生活中找问题，或者是从自己的知识领域找问题，也是一个很好的办法，当然，这往往需要多做一点功课。
+
+### 由浅入深，分层展开
+
+这一条技巧，讲的是“深度”方面，也就是上一讲我们说的“从模糊到清晰，从实际到抽象”原则。还记得我拿来举例的那个问题吗？
+
+> 
+“请你设计一个网约车系统。”
+
+
+下面我们继续沿着系统设计的路径，分析这个问题深入的过程。
+
+在问题抛出以后，有的候选人能够淡定地做进一步沟通，明确问题，而有的候选人则需要面试官逐步引导——“这个问题具体包括什么？”没错，这正是一个分析和细化需求的过程，需要候选人和面试官一起讨论。
+
+显然，我们不可能在面试中完整实现一个网约车系统，但我们可以专注于某几项核心功能。**我们可以从核心用例的角度来思考，想想都有什么角色，可以通过该系统完成什么功能，比方说**：
+
+1. 乘客可以随时随地叫车；
+1. 系统寻找邻近的司机并转发请求，如果无法接单，继续扩大寻找范围；
+1. 司机可以抢单，即接受或者拒绝叫车请求；
+1. 双方可以刷新自己在地图上的位置，也可以查看彼此当前的位置；
+1. 等待期间双方可以查看对方信息；
+1. 双方可以查看对方评分，也可以在约车结束后给对方打分；
+1. ……
+
+这样梳理后，虽然清楚一点了，但是我们发现其中的内容很多，于是我们可以选择其中最必不可少的一项或几项功能，来跟候选人继续进行探讨，毕竟面试时间有限，贪多嚼不烂。例如，我们就选其中的几项来讨论，其它一概忽略，这就把这个已经简化了的问题进一步简化，于是，问题的范围变得更小了。
+
+**在功能需求明确以后，进入设计步骤前，我们还需要讨论确定几项重要的非功能需求。**比如用户量有多少、每日的请求数有多少等等。这些数值不需要多么精准，但是数值的数量级会影响到系统的设计。
+
+在上面的过程中，候选人和面试官一起对问题层层梳理，把一个模糊问题转化为一个简化了的业务问题，只剩下有限的几个需求点要实现。
+
+但是麻雀虽小五脏俱全，功能需求和非功能需求都包括了。下一步，才是根据前面选定的需求点，从技术角度去考虑怎么实现；而技术实现，依然要秉承一样的原则，从模糊到清晰，逐步细化：
+
+1. 整个系统上看，有哪些组件，或者说有哪些service？（组件的调用和依赖关系）
+1. 把系统组件和用户角色放到一起，乘客和司机怎样和系统交互？（交互的时序关系）
+1. 每一个service都有什么职责，系统的数据存储选用什么技术？（存储层设计）
+
+你看，从上面这几个具体问题也可以看出，这正是在花主要的时间，考察候选人对于系统的理解。
+
+<img src="https://static001.geekbang.org/resource/image/2a/f8/2a76834be664c8cd9b7ce594658357f8.jpg" alt="">
+
+**在有了一个大体可行的系统设计后，从中选出一层、一个组件，或是一个机制，进一步细化展开。**
+
+比如说，对于存储方面，如果候选人提出使用关系型数据来存储乘客和司机的位置信息，那么我们可以通过这样的思路来展开：
+
+1. 你打算设计怎样的表结构来存储这样的信息？
+1. 这样的方案是否存在隐患，在产品上线后可能发生怎样的问题？
+1. 你打算怎样解决这样的问题？
+
+### 设定“踮踮脚能够到”的最高难度
+
+下面来谈谈问题的难度。
+
+很显然，不同的候选人，能力是不同的，对于同一个问题能够完成的进展也是不同的。我前面已经说了，问题的深入要有层次，逐步细化问题、抽丝剥茧，最后落实到一个短时间内就能完成的局部实现上。
+
+如果留意到问题对于候选人较为困难，面试官需要动态调控，目的是降低难度，方法可以是给出问题提示、主动减小问题范围、弱化问题要求，甚至直接推进问题分析。而如果问题对于候选人来说过于简单，那就要压缩流程中时间的分配，更多地把时间放到问题解决之后，对于进一步改进等等的“follow-up”的讨论上面。
+
+举个例子，如果一个算法问题是，使用非递归算法实现二叉树的前序和后序遍历，而候选人看起来缺乏头绪，那么我们可以：
+
+- **给出问题提示**：“二叉树是怎样的一种数据结构？前序和后序遍历的定义是什么？”；
+- **减小问题范围**：“我们先来只实现前序遍历吧！”；
+- **弱化问题要求**：“如果我们可以使用递归来实现呢？”；
+- **推进问题分析**：直接介绍前序或者后序遍历，使用非递归来实现的思路。
+
+一句话，通过暗示也好，明推也好，不断深入并击破难度递增的每一层问题挑战，并且**最理想的效果，是最终这个迷你项目的最高难度，恰恰是候选人“踮踮脚能够到”的难度，既不会过度简单，又不会难不可达。**
+
+这就有点像打电脑游戏，太简单了没意思，候选人也会觉得这家公司和团队不怎么样；太难了则又可能对候选人打击太大，或者导致他无法完成整个问题的解决流程。我们可以通过上面的四种办法，引导候选人理清思路，直到可以开始动手编码的程度。
+
+这个动态调整的过程是需要通过经验的积累，才能驾驭自如。但是我们从一开始，就可以树立这样的目标，我们希望不同程度的候选人，都可以“来时开开心心，走时不住回味”。
+
+面试的过程，如我们之前所说，考察是双向的，我们既要考察候选人的情况，也要给候选人留一个好印象。
+
+### 持续收集数据，调整你的问题
+
+对于前面提到的“问题的解决流程要完整”，和“抵达‘踮踮脚能够到’的难度”，不知你是否会觉得听起来很难做到，这需要比较高的经验和技巧。
+
+没有错，这也是为什么我们需要“持续收集数据，调整你的问题”。就好像要把任何一件复杂的事情做好，都要经过千锤百炼一样，一个问题设计好了以后，我们要反复地在实践中使用它。
+
+一方面，可以**不断地获取数据，这样的数据可以帮助你建立起属于自己的“坐标参考系”**，在评估一个新的候选人的时候，我们知道他大概处于一个什么位置；另一方面，又可以根据结果，反向地调整、改进，甚至替换问题，包括可以根据情况适当地增大或者减小问题的范围等等。
+
+举个例子，我认识一位面试官，他在考察算法的面试中，使用一道有关无向图求路径的问题，如果候选人对于无向图的基本知识缺乏了解的话，它就是一道挺难的题目了，毕竟，图的表示和路径求解，并不包含在我们最常见的数据结构和算法里面。这个题目他用了好几次，但是发现候选人普遍“没有思路，答不上来”，于是就不再使用这个题目了。
+
+我的一个经验是，在一个问题（包含确定的某一考察角度）被用了5次以上之后，基本上这个问题本身就成熟得多了。
+
+使用一个你自己设计的问题，还会给候选人带来一定的“新鲜感”，做这个迷你项目，解决一个新颖、有趣的问题，而不是互联网上一搜一大把那些。感觉这是一个信手拈来的事情，可他所不知道的是，这个问题是面试官精心准备的，也是在实践中锤炼过的。
+
+### 拓宽广度，给问题设置多角度延伸
+
+这一条技巧讲的是“广度”，其实就是我们上一讲的“不止一个考察角度，不止一个解”原则。
+
+这次拿我自己来举例，我拿这样一个问题，问了好几十人：
+
+> 
+“如果你所在的团队拥有一个重要的service，它的平均请求响应时间为1秒，有一天你部署了软件新版本后，留意到它的平均请求响应时间异常地增大到了10秒，你该怎么做？”
+
+
+这显然是一个实际的问题，而且可以是一大串不同问题的引子，根据考察的需要，我们可以把它延伸出去，进行各种追问。
+
+延伸一——**考察对用户体验、对工程的理解**：第一时间我们该怎样做，才能把对用户的影响降到最低？我们可能会谈到回滚，那么我们就可以讨论Ops。怎样避免未来再出现这样的问题？这就可以讨论软件工程的流程，讨论质量保证，讨论CI/CD，讨论灰度发布等等。这个延伸可以考察软件工程流程的方面，考察Engineering Excellence的方面。
+
+延伸二——**考察监控和告警系统设计**：我们该怎样争取在第一时间知道我们的系统出了问题？这就可以谈论软件监控和告警，我们需要对怎样的数据进行监控和告警？怎样采集数据，怎样发送数据，即怎样设计告警系统？这个延伸可以继续细化到一个监控系统设计的问题，或是做代码层面的考察。
+
+延伸三——**考察问题排查思路、系统的理解**：我们该怎样去定位问题，问题可能出现在哪一个层面？
+
+比如，可能service根本没事，只不过客户端出了问题，也可能网络有了问题，还可能就是service出的问题。而service出的问题，又可能有哪些原因造成，可以采用怎样的策略，去一层一层从高到低去定位问题所在？这一个延伸可以继续考察候选人对于系统的理解，尤其是通过一个请求响应的过程，考察他对于系统全栈的理解。
+
+延伸四——**聚焦系统某一层**：通过细化到某一层来进一步展开，这部分的思路就很多了，根据需要我们可以选择几个常用的切入点。
+
+比方说，如果问题是关系数据库的语句过慢造成的，这里我们就可以进一步聚焦，讨论一些常见的关系数据库性能问题出现的原因，以及相应的解决思路。如果是应用层面的问题，比如应用的内存不足，那么可以从这个角度进一步展开。
+
+延伸五——**聚焦系统限流问题**：如果问题是恰巧由于该时间点某一客户端在短时间内发送过量的请求，系统无法及时处理而导致的拖慢，那么我们就又可以从流量控制的角度展开。流量控制的问题也是属于经典的系统问题之一，既可以从系统设计的角度考察，也可以从代码设计的角度考察。
+
+你看，一个模糊的实际问题，可以拿过来做多种方向的延伸，而这些延伸之间又具备密切的联系。我们可以根据需要，在面试中选取其中一个延伸的角度来进行考察。
+
+### 平衡考察的深度和广度
+
+**如果我们总是能把技术考察，从一个简略、模糊的实际问题开始，逐步深入，到最后以一个完整的问题解决过程收尾，那么几乎就可以说，我们就做到了深度和广度的兼顾。**
+
+我曾经两次提到过，为什么我不推荐面试中使用简单粗暴的纯算法题？说到底就是一个考察面的问题，单纯地考察算法题，就是一个可以具备足够的考察深度，但是很容易丢失考察广度的例子。
+
+反过来也一样，我下面来说说覆盖广度而丢失深度的情况。有一种面试风格，是让候选人谈论一个他自己最熟悉，或是最自豪的一个项目，然后从中抓住某些点不断深挖。这本身听起来似乎也是一个挺不错的考察思路，和我们前面谈到的面试官去准备问题的思路，恰好相反——由候选人来主导这个过程。
+
+但是现实中，对于经验尚浅的面试官，我一般不太推荐上面的方式，主要原因是，在实践中这个方式对于面试官的素质要求非常高：如果候选人谈到的项目或者系统，面试官比较熟悉，那一切都好说，但是如果不熟悉呢，面试官就很难把握住这里的关键，容易被候选人牵着鼻子走，可能这一轮面试候选人一直在泛泛地说，谈到了许多方面，但是面试官也提不出什么一针见血的问题。
+
+## 总结与思考
+
+在上一讲谈论的技术问题设计原则之后，今天我们结合了几个实际例子，讨论了几个技术问题的设计技巧，相信你通过今天的内容，在之前大致思路的基础上，收获到了一些可以用于实践的小窍门。
+
+<img src="https://static001.geekbang.org/resource/image/cd/cf/cd4bee6e4c74d2304942e63a84da9bcf.jpg" alt="">
+
+在文章的最后，我想提一个问题，你能否分享一下，你觉得行之有效的，在面试中考察候选人的小窍门呢？
+
+好，我是四火，我们下一讲见！

极客时间专栏/技术面试官识人手册/面试准备|计划篇/答疑课堂01：面试计划篇热点问题解答.md

@@ -0,0 +1,143 @@
+<audio id="audio" title="答疑课堂01：面试计划篇热点问题解答" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/38/11/38683e5d9d23ef1e76e76ba41dc9bf11.mp3"></audio>
+
+你好，我是四火。
+
+这一讲是关于常见问题的答疑课，对专栏第一大板块的“面试准备/计划”的篇章，还有一些很有意思的问题，在专栏正文中并没有得到足够透彻的讨论，那么我们就在这里把它们讲透。
+
+**问题1：候选人经验比我丰富，我自认技术上也不如他，因而缺乏驾驭面试的自信怎么办？**
+
+这是一个非常常见的面试官心理建设的问题。尤其对刚做面试工作没多久的面试官，这个问题尤为常见。
+
+首先需要明确的一点是，闻道有先后，术业有专攻。没有任何一条面试的原则说，你非要比候选人在某个特定的方面更加出色，才可以面试他。就是在一起工作的团队，其中的不同成员在特定业务和技术上，能力层次还有高有低呢，不过在做项目和沟通交流的时候，大家都是平等的。
+
+其次，面试的过程，从你的角度看，就是使用你的方法考察候选人的过程，也是候选人考察目标团队的过程。
+
+既然如此，把注意力放到你的面试具体实践上，无论是一起讨论一个问题，还是一起做一个小项目。在面试中，不妨把你们之间的关系，看做工作中的同事，一起解决一个业务或技术的难题。
+
+再次，每个面试官都是这样过来的。据我所知，即便经过了相当长的时间，有些面试官还依然觉得战战兢兢，如履薄冰。
+
+要知道有些情况下这是好事，缺乏自信可以让你远离自负，更加认真地对待面试这件事情，从做计划，到面试实施，再到之后的决策。
+
+最后，最开始遇到这种情形时，有些面试官可能会紧张，这是完全正常的。事实上，无论紧张的原因是什么，不要去刻意地尝试克服紧张情绪，而是坦然地接受它。
+
+再说了，适度的紧张还能够帮助提高专注力，我们只需要把注意力尽量转移到面试的流程和步骤上。相信经过多次的实践以后，我们就会慢慢淡定下来了。
+
+**问题2：怎样看待脑筋急转弯类问题？**
+
+三个字，不推荐。
+
+脑筋急转弯类问题，英文里比较接近的词是Brain Teaser，指的是一类题面比较简单，但是解答需要跳出常规思维，给出“出乎意料”答案的一类问题。
+
+原本这类问题就是问着玩儿的，但是后来它被用到了一些面试中去，甚至有不少是大公司，网上有很多关于大厂拿脑筋急转弯面试候选人的故事。
+
+最开始，脑筋急转弯就是一些“娱乐性”很强的问题，但后来慢慢演变出更广泛的形式，看似更考验候选人的思维能力，比方说：
+
+> 
+填满一辆校车需要多少个高尔夫球？
+
+
+不知道你听过这个问题没有，这是网上流传得颇为广泛的一道题，据说是Google拿来面试候选人的。
+
+我想说的是，我们只讨论针对软件工程师的面试的话，其实Google的技术面试的流程和其它几家互联网大厂都是类似的，如今说他们问脑筋急转弯问题是无稽之谈。而在一些互联网大厂的面试官培训中，都会强调一句话——不要问脑筋急转弯问题。
+
+那我们进一步解释一下这是为什么。还记得我们在[第1讲](https://time.geekbang.org/column/article/359015)中就介绍了，面试的目的就是为了**寻找“合适”的技术人才**吗？
+
+正因为这样，我们才那么希望面试尽可能还原实际工作的场景，这才有了希望在面试中“讨论一个问题”和“做一个迷你项目”这样的目标，这样收集到的数据，才能比较有效地判断候选人是不是“匹配”的。
+
+而脑筋急转弯呢？即便它能考察候选人的思路是不是开阔，反应是不是迅速，但因为**它远离了我们要解决的实际问题，远离了我们的工作场景，既没有业务覆盖，也没有技术覆盖，它在技术面试中的价值实际就很低了。**
+
+事实上，这些年来，有许多研究者仔细地分析了脑筋急转弯在面试中的应用，他们发现候选人对于这类问题的回答，和他们在实际工作中的表现缺乏相关性。
+
+比方说这篇[论文](https://iaap-journals.onlinelibrary.wiley.com/doi/abs/10.1111/apps.12163)，它提到在面试中使用脑筋急转弯问题“缺乏有效的证据，且会令候选人感到不安”：
+
+> 
+lacks evidence for validity and is unsettling to job applicants
+
+
+**问题3：怎样看待系统估算类问题？**
+
+系统估算类问题，是一种特定的考察候选人对软件系统理解的问题，它要求候选人估算一下在指定场景中，系统的规模的大小。比方说：
+
+> 
+已知 Twitter 2020年大约有2000亿的推文（tweets），如果你来设计 Twitter 系统，请问发推服务的吞吐量需要多少，网络带宽要占用多大，要存储它们需要多少磁盘容量？
+
+
+这里说的是Twitter系统，但是类似的提问方式，套用到面试中讨论的软件系统，也是一样的。这个问题如何分析和求解呢？我可以给你一个简单的参考思路：
+
+- 吞吐量，一般可以估算TPS（Transaction Per Second），2000亿 / 365 天 / 24小时 / 60分 / 60秒，大概是6000左右，那么考虑TPS的波动性，我们简单预留3倍的空间，认为系统的TPS需要预留到20000左右，就大致可行了。
+- 网络带宽，我们假设平均每条推文200个字符，众所周知每个字符占用2个字节（B，Byte），每个字节为8个比特（b，bit），我们在这里统一使用Byte，而不是bit（这里说明一下，你的网络运营商为了数据好看，可能会用比特每秒，而不是字节每秒宣传它的带宽）。这样每条推文就占用了 200 * 2 = 400 Byte，因此带宽就是400 Byte * 20000 吞吐量= 8 MB的带宽。这里其实从B到MB应该使用1/1024的倍率，但是估算就使用了近似的1/1000的倍率。
+- 存储，2000亿推文 * 200 个字符 * 2 Byte = 80 TB一年。
+
+**对于系统估算类问题，最重要的是过程要符合逻辑，而估算的最后结果并不是最重要的。**过程正确的话，结果的数量级基本上是八九不离十的，那么设计出的系统往往就是靠谱的。
+
+实践上，这一类问题我以前尝试用过，但是和其它类型的问题类型相比，它对候选人的要求其实比较高。我通常在面试高级工程师级别以下的职位时，就不考虑使用系统估算的问题了。
+
+从职位来看，如果职位需要比较强的架构设计能力，或者团队是做软件中的基础设施部分的，那往往就需要候选人具备靠谱且快速的估算能力。
+
+**问题4：对于小公司来说，怎样在人才招聘中和大厂竞争？**
+
+严格说，这是一个招聘的问题，而不是一个单纯面试的问题。但是，对于小公司来说，负责面试的同事，很可能承担了更多的职责，甚至有很重的“招人”的压力，这是很多大厂的面试官无法感同身受的。
+
+因此，对他们来说，怎样去和大厂竞争，这就成为了一个实际的、需要在面试前搞清楚的问题，而这个问题有很强的普遍性，因此我想在这里专门谈一下。
+
+有位同学lihp在专栏中留言谈到：
+
+> 
+最近公司在招聘新人，秉承公司一贯用人理念，精英式团队，对人员的素质要求高，C/C++的技术基础扎实，还需要是一个培养潜力的人，尤其是在招聘有经验的工程师岗位（入职即可快速适应工作，参与产品和项目开发），招聘的进度不及预期，年初至今尚未找到合适的人才。
+
+
+> 
+岗位要求技能和能力比较综合，不存在过度关注算法或某一项专项技术的问题，以能力面试为主，只要面试者表现强烈的学习意愿、良好的学习能力和沟通能力，技术基础与经验相匹配即可。
+
+
+于是我就问道：
+
+> 
+就你提到的“尚未找到合适的人才”我也好奇，因为从你简单的描述看似乎要求并不算特别高。那么，你觉得招不到人到底是什么原因呢？
+
+
+接着他答复道：
+
+> 
+公司岗位对合适的人，综合要求较高，学习能力强，思维逻辑清晰，专业技能扎实，也就是说我们觉得合适的人也符合多数大厂要求，候选人可选择性多。
+
+
+> 
+<ol>
+- 品牌知名度不及大厂。相比于知名的互联网公司，我司主要从事 toB 软件产品开发，在细分行业内还略有名气，但普通大众压根不知道，品牌商和大厂是没法比；
+- 薪资竞争力弱，大厂给更多，即使相同或者略少，大多数候选人也会选择大厂；
+- 筛选得到的候选人少，优秀的人才通过线下、内推等渠道选择工作，我司主要是通过简历、猎头等渠道，符合岗位需要的人数量较少。
+</ol>
+
+
+对于中小公司，这就是一个现实的问题。
+
+我记得一位负责招聘的朋友说，招人也有“二八现象”，就是市场上长期流通的简历中，有80%都是来自那20%的候选人，而很多优秀的候选人，在人才市场上出现的时间都很短。
+
+如果要通过常规的招聘网站、猎头等渠道找到优秀的人，必然要面临巨大的竞争，而那些相对优秀的候选人，也就比较容易拿到offer，甚至多家offer，这时候企业面临人才的竞争就比较激烈了。
+
+再从这位朋友的描述看，他对他们需要的人才的标准叙述很清晰，对优秀软件工程师的认识也符合主流的招聘标准，但由于知名度、薪资竞争力等方面不及大厂，那么自然，招聘就确实是一件较为困难的事情了。
+
+分析完问题，再说说问题解决的思路。
+
+首先是要清楚自身的优势。知名度和薪资竞争力不及大厂，这是事实，那么也要看到，大厂往往有着大公司病，小公司也可以有它自己的优势，因此**差异化**是关键。
+
+这个差异化既包括在对候选人的要求上有所区别，也包括提供的福利待遇和工作挑战有自己的优势。比如工作时间和地点灵活，在某些技术细分上顶尖，职位重要性高，工作影响力大，以及能提供未来兑现的期权等等。
+
+无论如何，不和大厂硬刚，寻找自身的优势，只要双方的需求能够得到大致匹配，那么候选人就能招得进来，也能留得住。
+
+我举个自己主导面试的例子吧。大家都知道，无论是从国际上看，还是在北美，Amazon的AWS在云计算领域都遥遥领先，而Oracle的OCI（Oracle Cloud Infrastructure）进入市场晚得多，份额也显然不能同日而语。因此我经常被候选人问到一个问题，作为软件工程师，在OCI工作和AWS工作相比，有哪些优势？
+
+我会谈到几个方面，其中一个是流程，我经常举一个真实的例子，一位朋友在AWS的S3组工作，他修改了一行普通的代码，需要经过好多个组的评审，花了整整三个月才让他的代码上线。而在OCI就不会有这样的情况发生，流程更为敏捷和快速。
+
+另一方面，如果要讨论影响力（impact），很明显一个相对小一些的组织，软件工程师更需要承担更重要的职责，也往往能在组织中带来更大的影响力。
+
+再者，相较于成熟的AWS，在OCI要解决的问题，往往是模糊的，很多问题更“新”，也更考验软件工程师解决实际问题的能力，这一点很锻炼人。
+
+其次，小公司尤其要扩展招人的渠道。以前我的老板说过一句话，叫做“时刻在招人”。线下的招人渠道，通常竞争更少，比如线下的技术活动，或者是因为开源项目而认识的朋友等等。
+
+我有位朋友正在创业，他的团队能力很强，有意思的是这些人几乎没有一个是通过常规的猎头渠道，或者招聘网站渠道招进来的。
+
+那好，今天就谈这几个问题吧，希望你有所收获。如果你有其它问题，也欢迎你在留言区继续跟我交流探讨，我也会和你聊聊我的看法。
+
+好，我是四火，我们下一讲见。