聊聊技术面试 | 掘金技术征文

前言

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

何为技术面试

我所理解的面试，是一场围绕着两个角色 - 面试官 & 面试者 之间的一场“对接之旅”， 如何在短短的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，另外沟通能力不能太差，因此至少有中等规模项目的参与，而且和不一样的角色进行沟经过。这样一个能力模型，再去匹配外包，招聘必然是事半功倍的。

掘金数征文连接👉 juejin.im/post/5aaf2a…