导读

“招前端难，招优秀的前端更难，招能带团队的优秀前端难上加难”，这似乎是目前业内的常态。本文将聚焦于讨论如何低成本，高效率的进行人才筛选和招聘，希望能够对正在搭建前端团队的同学有所帮助。

分析

人才方面

也就是供给方。一方面，表面看起来前端门槛相对较低，大多数想转行到互联网做技术的人，都会选择从前端做起。这部分人主要会通过市场上的培训班等技能培训途径入门，通常这些培训机构也会与外包公司有合作，一定程度解决就业问题。

另一方面，由于目前高校还没有系统性的前端开发课程，选择前端方向实习或就业的毕业生，基本都是在学校“机缘巧合”接触了前端并有一定实践，之后也就顺着惯性继续走了，其学习方式主要是通过自学。

以上两类虽然不能代表全部的前端人才来源，但肯定占了大多数，具有一定的代表性。近些年前端技术发展非常迅速，可谓日新月异，百家争鸣，这也决定了前端开发几乎是最考验自学能力的岗位。但是自学又很难保证知识的完整性与系统性，也就是人才质量。如果仿照人口结构图，以人才质量为纵轴，那么前端人力结构则会呈现为典型的倒喇叭形，底部很宽，越到上方收缩越快（请参考印度人口结构图）。

招聘方面

也就是需求方，也是我们本文讨论的重点。招聘是有成本的，以面试官的维度来说，直接成本就是面试官付出的时间，可以简单粗暴的用面试官的时薪来衡量成本。值得注意的是，技术面试通常都是三轮以上，往往越高级别的面试官时间越值钱。所以越在面试早期淘汰掉不合适的候选人，越能够节省成本。结合上述前端人才结构来看，在初期筛选掉大多数候选人，是个大概率事件。如果团队中初面面试官与终面面试官的面试量没有太大差别的话，大概率是有问题的。

上面主要是说明“什么样是对的”，接下来分析怎样做对。一般来说，有一定从业经验的人来做面试官是比较合适的，但是以笔者观察到的现象来说，高级别的面试官是相对很稀缺的，甚至初级面试官都不够用。一般的前端团队构成大概是，1 个 Leader，2~3 个高级工程师，带 4~6 个初级工程师，外加几个流动的实习生或外包，这已经算得上是成规模的前端团队了。可以看到，即使是这样的团队构成，在面对海量的面试时，初级面试官也是不够用的。所以一些工作和面试经验都较少的同学，也不得不赶鸭子上架的充当面试官的角色。这时最怕，也最容易出现两种极端情况：

• 一是面试前期无法判断候选人能力是否合适，把面试工作全部后移，增加了招聘成本；
• 二是误判了候选人的能力，将一些合适的候选人过早的淘汰，直接造成了损失； 所以我们应该聚焦在如何快速的让初级面试官能够科学有效的甄别候选人，尽最大可能减少上述极端情况的发生，从而提高面试效率上。另外，简历筛选实际上更为前置，但是通常这部分不会出太大问题，所以不是本文讨论的重点。

目标

让我们再次整理，明确一下目标：

1. 尽量在早期淘汰掉不合适的候选人，节省成本
2. 科学合理的评估候选人能力，避免误伤
3. 面试初期尽可能多的挖掘有效信息，提高效率

方案

候选人能力模型

针对不同级别的候选人，考察的重点会有所不同，这个我们后面再细说。我们先要提炼出一个候选人能力模型，以便系统性、针对性的输出解决方案。

1. 基础知识与技能。深度比广度更重要，不断追问比散点式提问更有效，要挖掘到候选人的极限；
2. 沟通能力。即表达和理解能力，叙述是否有条理、有层次，能否快速理解面试官的引导，能否按照面试官的思路回答问题；
3. 单兵作战能力。主要考察编码能力与做过的项目，不同级别候选人考察侧重点不同，主要观察其遇到困难时的真实反映。挖掘其自驱力、热情以及技术追求，甚至是价值观；
4. 带团队能力。项目管理、团队提效、跨团队沟通、资源协调等能力考察，注意一定要考察落地情况，说的再天花乱坠也是虚的；
5. 特殊能力。如果有团队急需的特殊能力，权重要适当提高，并派专业人士重点考察； 有了以上的能力模型，我们就可以根据不同能力的考察难度，来系统的规划每一轮的考察重点以及考查方式了。

每轮都考察什么

可以看到，“越前期越套路，越后期越个性”。如此设计可以充分的发挥每一轮面试官的价值，整体来说投入产出比是最高的。“个性”的东西不好归纳，但是“套路”是可以积累的。所以学习团队的面试题库，对于快速提高初级面试官的水平是最有效的。

如何设计题库

此部分主要给出设计考题的思路，具体的考题积累需要团队根据情况落实。

代码题

切记，面试的目的绝对不是考倒对方来彰显自己的胜利，如果这样做你将是永远的输家。我们将代码题分成两类，一是 leetcode 等刷题平台的原题，二是自己编写的考题。

平台原题

有的人对于原题很不屑，其实通过原题也能考察出很多东西。

• 第一，通过候选人回答的熟练程度来考察其对面试的准备是否充分，尤其是有了一些经验的社招，没刷题不一定不行，但是刷了题一般都比较踏实。
• 第二，即使是刷题，也是要有系统性思维的，机械的从第 1 题刷到第 100 题，通常收效不大。所以通过一些典型模型的变体来考察其举一反三的能力，通常会有不错的收获。
• 第三，平台给出的答案代码可读性通常都一般。如果候选人能够针对性的有优化，如变量名、缩进、分模块等，其代码规范性与编码经验也不会差。
• 第四，简单粗暴，低成本筛选掉明显不合适的候选人。如果简单题（即使没刷过也应该会的）经过提示都写不上来，通常会有较大幅度减分。当然，要注意先去除掉候选人的抗拒心里，否则也不容易挖掘出其真实水平。

自编考题

• 一定避免难怪偏，要有明确的考察点，不能为了考而考；
• 可以作为考察候选人逻辑能力的方式，即把一些逻辑问题，用代码的形式展现出来，不一定非要考察具体技术点；
• 带入业务场景，考察某些特定条件下的最佳实践，以及问题抽象能力；
• 针对某些库、语法、特性设计考题，主要考察候选人技术熟练程度以及编码习惯；

通常，平台类题作为探路，根据候选人的表现和反馈再考察自编考题，是比较有效的套路。当然，一切的前提都要建立在面试官对于考题已经有了深入的理解，所以对于面试官的培训和考察，还是必要的。

知识点

有人对“前端八股文”表示不屑，实际上如果你真的见过“状元写的八股文”，相信你的想法一定会有所改变，“八股文”也可以很有深度。能考上功名的人很少，同样，能把基础知识研究的足够深的人，也很少，只是看我们是否能挖掘出来。这里的重点就一句话：“不断追问，挖掘极限”。

我们要捋清楚一个逻辑，所有知识点都是为了解决实际问题而出现的，实际问题结合了特定场景是可以很复杂的。我们要做的就是从知识点出发，顺着那条“经常被忽略的”长长的线，找到它要解决的实际问题，然后再引申出其他相关知识点，再反复。理论上，可以无限的问下去。这么说还是很虚，我们来举几个例子：

数据类型

• JS 的数据类型？为什么叫引用类型？判断数组类型的方法？
• [] === [] 是否相等？为什么？ == 呢？ == 左右发生了什么？
• 引用类型在实践中要注意的点？immutable 解决什么问题？如何解决的问题？
• Vue 和 React 对数组的处理有什么特别之处？如何理解 React 的单向数据流与 Vue 的双向绑定？

HTTP 状态码

• 说几个常见的状态码以及意义？301与302的区别？
• 遇到过 1xx 吗？什么场景会出现？websocket 与 HTTP 有关系吗？HTTPS 是什么？要解决什么问题？
• 说下 304 与强缓存的原理？能解决什么问题？html 文件的强缓存如何解决？
• 如何利用缓存优化性能？浏览器并发请求数？HTTP2.0？
• HTTPS 是对称加密还是非对称加密？为什么？证书如何分发？接入微信等第三方的服务，鉴权方式通常如何？

跨域

• 跨域的定义以及常见解决方法？JSONP、反向代理的原理？
• CSRF 攻击？如何预防？cookies 的作用及使用细节？
• 如何解决集群服务的鉴权问题？有何利弊？是否有其他方案？JWT？token？
• 单点登录的多方通信过程？登出如何处理？

可以看到，上述例子都是从最基本的前端知识点开始，然后不断地追问，最后甚至引申出了与最初的问题毫不相干的领域。这样的提问至少有两方面好处：

一是节奏一直没有断，可以完整的观察到候选人的思路，同时也考察了候选人的沟通能力；

二是可以将知识点深度量化的体现出来，虽然量化的可能较粗糙，但明显是可以通过团队讨论对齐进一步优化的；

不过，要想做到上面的要求，题库起码要有足够的丰富度，以产生网络效应。再者，面试官对知识点的掌握也要达到一定深度。当然，如果面试题库已经有了，面试官的学习就会很快了。毕竟，面试官还是需要一定门槛的。

PS：更多知识点总结请移步《前端面试官速成题库》

结语

回顾一下我们的目标：尽早淘汰不合适的、科学评估避免误伤、尽可能挖掘有效信息。我们通过建立候选人能力模型、规划每轮面试考察重点、设计题库培训面试官，来达到目标。

实际上，本文只能算是提供一个宏观的思路，至于具体如何落地，还有太多的细节需要展开讨论，还要根据团队的情况进行调整。笔者观察到，不管是 HR 还是业务部门，其实都想搞好招聘和面试，但是又都苦于不知道从何入手。所以希望本文能够起到一定的梳理作用，让招聘和面试的优化有具体的抓手可落地，如真有效，也算是功德一件。

“二十一世纪什么最贵？人才！”——《天下无贼》