前言

最近作为面试官，参与了多场专场面试，短期内大量的面试，面对不同风格，性格迥异的面试者，让我对面试这件事本身产生了一些思考，结合自己的一些理解和技术领域特有的定级制度，我们不妨来聊聊技术面试这回事。

何为技术面试

我所理解的面试，是一场围绕着两个角色 – 面试官 & 面试者 之间的一场“对接之旅”， 如何在短短的30分钟内， 让彼此更多的了解对方， 就像两个不同的形状的卡口，不断的调整彼此认知，进行思维对接，最终完成面试。由此我们大致可以将面试划分出几种失败的场景。

1. 互怼型

面试官完全不看面试者的简历，仅从自己的技术领域出发，对面试者进行考察，面试者往往会有一种被 diss 了的感觉，脾气不好的可能会进行反向 diss，然后一场面试就变成了带点火药味的攻防战。

2. 尬聊型

面试者对自身的认知有限，简历上几乎体现不出有价值的内容，缺乏经验的面试官不知从何问起，或者面试者的简历虽然详实，但所有的问题都点到为止，场面一度陷入尴尬，就像一场尬聊，这种情况下，经验丰富的面试官可能会通过一系列问题来确定面试者的能力边界，从而构建出面试者的能力模型，如何做到这一点，我们后面聊 ：）

3. 一边倒

面试官或者面试者占据绝对的主动，但是彼此沟通并没有形成体系，往往在某个细节上进行过于深入的沟通，一方占据优势导致另一方疲于应付，最终形成一边倒的局面，结果无非是

• 面试者：“这煞笔真水”
• 面试官：“这哪来的2B”

从上述的一些场景中，我们不难发现，面试失败的原因可以归纳为2类：

• 面试者缺乏自我认知，没有把自身的优势体现出来，简历中没有很好的勾勒自己的能力模型，给面试对接过程带来了很高的启动成本
• 面试官缺乏问问题的技巧和经验，不能够通过问题确定面试者的能力边界，从而勾勒出面试者的能力模型，导致最终产生不全面，甚至错误的判断

何为能力边界 & 能力模型

俗话说人力有穷尽，每个的能力在任何方向上都会有尽头，这个尽头便是你能力的边界，我们经常在游戏中看到一种五边形，每个顶点都代表一种能力，角色在这个五边形中不同能力的数值最终构成了一个角色的能力模型，譬如敏捷型 / 力量型 / 智慧型 等等，而作为技术工程师，确定自己或者确定一个人的能力模型是及其困难的事，尤其是在短短的几十分钟内，通过一场面试，那更是难上加难，故而如果面试者能对自己的能力模型有很好的认知，面试官有丰富的经验技巧和对应的知识储备来验证这个能力模型，那面试的过程就会非常高效。

面试者如何勾勒自己的能力模型 & 面试官如何确定面试者的能力边界

回到面试者本身，因为不同的技术背景的公司对于同一层级的能力模型的定义可能存在偏差，譬如同样是高级前端工程师，对于专业能力的理解，可能会因为技术栈的不同而产生变化，一个使用 React 技术栈的公司对于能力相同，但是使用 Vue 开发的工程师给出的评价可能会低于使用 React 的工程师，而这种技术变量的存在给面试本身带来了很多的不确定性。尤其是对于面试官如果相应的知识储备不够，那评价可能就会更加失真了，所以作为面试者，我们应该从自身的角度出发，尽可能在简历中给出一个可评估的能力模型，让面试官能够更好的了解，愉快的完成对接，这里我罗列了一些边界的点，尽可能从相对通用的角度来定义工程师的能力模型。

基础能力

体现技术的基础技能的掌握情况，以前端举例，可能包括通用计算机基础，例如基本的数据结构和算法，像堆栈，队列，数组，树，链表等定义，和常规的操作等；前端技术基础，对 JavaScript的理解，对 http 协议的理解，css / html 掌握和理解以及其底层的协议和规范的理解和掌握；业务能力基础，包括对实际用于业务开发的技术掌握的情况，譬如对 React 的理解，对 Vue 的理解，如果是公共技术团队则可能涉及 Webpack 打包构建方面的理解，也可能是对 nodejs 的理解；仔细观察，不难发现，基础能力边界是一个层层推进的过程，面试者可能具有丰富的业务经验，但是如果你要理解 React 的底层实现，就一定会去学习树的数据结构和算法，看到JSX，就会想到 babel 是如何解析的，这里涉及到编译原理的前端部分，而这些又绕不开对 JavaScript的理解，从而形成一条清晰的基础能力链条，如果你的简历能体现这些，面试官就能很快的核对出你的基础能力到底是否扎实，作为面试官，我们从业务基础能力往通用计算机基础方向去不断的发问，形成一条问题链条，就能考察出面试者的基础能力是否扎实，对于那些只局限于 API 使用的情况，那基础能力上的评价就是相当低的。

专业能力

相对于基础能力聚焦于技术领域，考察的是技术工程师中的技术两个字，而专业能力则考察技术工程师中的工程两个字，一个优秀的工程师，一定具备良好的工程项目设计，管理，推进能力。一个软件工程从无到有的过程，其最初一定是设计，如果一个技术工程师没有任何设计一个项目的经验，那这一项一定是不合格的，如果他有，那设计的方案是否合理，是否具备良好的扩展性，可维护性，就是需要考察的一个点，因为有了设计，那一定需要将设计落地，这个过程就是工程项目的推进，作为工程师，他如何推进，如何落地一个设计，这中间是如何管理的，如何控制项目风险，确保设计最终能够被落实到项目中，这些都是考量的点，面试官可以持续的深入去了解从设计到落地的全过程，并通过工程项目的复杂性来判断他专业能力的高低。这也是在基础能力通过的前提下，给一个技术工程师评级的关键。

沟通能力

任何工作都离不开沟通，尤其是技术工程师，在团队协作中跟不同的角色产生的沟通，更是团队能否有效率的持续完成任务的关键，那如何体现自己的沟通能力 / 面试官如何考察一个人的沟通能力？

第一应该是直接感觉，在面试过程中，对方是否能够很好的说明自己的优势，并获得面试官的认可，这本身也是沟通能力的体现，但光靠这个可能还不够。所以第二点，又回到了之前的专业能力上，面试者所完成的工程项目的复杂性直接体现了他沟通能力，譬如这是个跨部门跨团队的大项目，他能够拿到比较好的结果，那沟通能力一定不会太差，如果一直都是做一个人的项目，或者是从没有 owner 过一个项目，那沟通能力可能很难被评估出来，这时候不妨问些有引导性的问题，譬如：“是否遇到过工作上的难点，需要同事协助？”；“有主动去和其他部门的人沟通，完成一些工作么？”，如果都没有，那只能靠第一感官了……

潜力 & 成长性

很多时候，面试者可能并没有丰富的履历和工作经验，有些甚至是半路出家的“自学达人”，这时候，如果仅仅评估上述三点，也可能会错失人才，另外即便是上述3点都非常好，但是因为人的阶段的不同导致后续的表现并不如评估的那样，为此我们需要考量面试者的潜力，即成长性

那怎么定义潜力，或者说成长性呢？

我个人的理解，一个人的潜力来自于两方面，一方面是这个人在早期的学习和工作经历中的积累，即基础是否扎实，这在基础能力评估中可以比较准确的判断，另一方面则是自我驱动，学习能力，善于思考，善于总结抽象等软性能力

综合起来看，即面试者对于自己的工作是否真的感兴趣，对于技术是否有很强的好奇心，表现在行为上，一个自我驱动好，对技术有好奇心的人，往往会对工作之外的技术表现出极大的关注，即虽然这些技术目前你用不到，实际工作中可能没有场景，但是依然会去了解，并进行尝试，并深入去了解背后的实现原理，技术发展的前因后果，跟同类的比较等等，最后再进一步进行思考提炼加工，变成自己的东西，这个过程最终体现的其实是你的学习能力，即面试者是否有潜力，是否有成长性，就是看他是否能够自我驱动，并拥有优秀的学习能力。

经验

为什么把经验放在最后，因为我认为在整个能力模型中，经验是万不得已的评判标准，即一个人4项都不行，但是他有经验啊，对于商业化的公司来说，某些场景下，我们需要的仅仅可能是一个对某一块非常有经验的技术工人。

总结

通过对能力边界 & 能力模型的定义，面试官可以组合出你自己想要的能力模型， 然后匹配面试者的能力模型，让面试的过程一开始就具备良好对接的可能，而面试仅仅是完成对接，验证这个能力模型是否真实，是否匹配罢了。

比较极端的一个例子是外包，大公司可能会有不少苦力活需要外包，这时候其实就可以定义出外包的能力模型， 即对某一块经验丰富，同时熟练掌握业务基础 API，即业务基础能力较差，但是至少不是 0，另外沟通能力不能太差，所以至少有中等规模项目的参与，并且和不同的角色进行沟通过。这样一个能力模型，再去匹配外包，招聘必然是事半功倍的。