当前期刊数: 19
本期精读的文章是：The-Best-Frontend-JavaScript-Interview-Questions
讨论前端面试哪些问题，以及如何面试。
1 引言
又到了招聘的季节，如何为自己的团队找到真正优秀的人才？问哪些问题更合适？我们简单总结一把。
2 内容概要
The-Best-Frontend-JavaScript-Interview-Questions 从 概念 - 算法 coding - 调试 - 设计 这 4 步全面了解候选人的基本功。
3 精读
本精读由 ascoders camsong jasonslyvia 讨论而出。
网络技术发展非常迅速，前端变化尤为快，对优秀人才的面试方式在不同时期会有少许不同。
整体套路
在面试之前，第一步要询问自己，是否对当前岗位的职责、要求有清晰的认识？不知道自己岗位要招什么样的人，也无法组织好面试题。
认真阅读简历，这是对候选人起码的尊重，同时也是对自己的负责。阅读简历是为了计划面试流程，不应该对所有候选人都准备相同的问题。
具体流程我们一般会通过：
- 开场白
- 候选人自我介绍
- 面试
- 附加信息
- 结束
开场白是最重要的，毕竟候选人如果拒绝了本次面试，后面的流程都不会存在。其次，通过候选人自我介绍，了解简历中你所疑惑的地方。简历是为了突出重点，快速判断是否基本匹配岗位要求，一旦确认了面试，全面了解候选人经验是对双方的负责。接下来重点讨论面试过程。
开放性问题
面试的目的是挖掘对方的优点，而不是拿面试官自己的知识点与对方知识点做交集，看看能否匹配上 80%。但受主观因素影响，又不宜询问太多开放性问题，因此开放问题很讲究技巧。
正如上面所说，我推荐以开放性问题开场，这样便于了解候选人的经历、熟悉哪些技术点，便于后面的技术提问。如果开场就以准备好的题目展开车轮战，容易引起候选人心里紧张，同时我们问的问题不一定是候选人所在行的，技术问题不是每一个都那么重要，很多时候我们只看到了候选人的冰山一角，但此时气氛已经尴尬，很多时候会遗漏优秀人才。
开放性问题最好基于行为面试法询问（Star 法则）：
- Situation: 场景 - 当时是怎样的场景
- Task: 任务 - 当时的任务是什么
- Action: 我采取了怎样的行动
- Result: 达到了什么样的结果
行为面试法的好处在于还原当时场景，不但让面试官了解更多细节，也开拓了面试者的思维，让面试过程更加高效、全面。
举一个例子，比如考察候选人是否聪明，star 法则会这样询问：
在刚才的项目中，你提到了公司业务发展很快，人手不够，你是如何应对的呢？
相比不推荐的 “假设性问题” 会如此提问：
假如让你学习一个新技术，你会如何做？
更不推荐的是 “引导性问题”：
你觉得自己聪明吗？
相比于 star 法则，其他方式的提问，不但让候选人觉得突兀，不好回答，而且容易被主观想法带歪，助长了面试中投机的气氛。至于对 star 法则都精心编排的候选人，我还没有遇到过，如果遇到了肯定会劝他转行做演员 —— 开玩笑的，会通过后续技术问题甄别候选人是否有真本领。
技术问题
亘古不变的问题就是考察基本功了，然而基本功随着技术的演进会有所调整，Html Css Js 这三个维度永远是不变的，但旧的 api 是否考察，取决于是否有最新 api 代替了它，如果有，在浏览器兼容性达标的基础上，可以只考察替代的 api，当然了解历史会更好。
比如
proxy与defineProperty需要结合考察，因为proxy不兼容任何 IE 浏览器，候选人需要全面了解这两种用法。
变的地方在于对候选人使用技术框架的提问。在开放性问题中已经做好了铺垫，那无论候选人时以什么框架开发的，或者不使用框架开发，最好按照候选人的使用习惯提问。比如候选人使用 Angular 框架的开发经验较多，就重点考察对 Angular 框架设计、实现原理是否了解，实际使用中是否遇到过问题，以及对问题的解决方法，这也回到了 star 法则。
如果候选人能总结出比如当前流行的 Vue React Angular 这三个框架核心实现思想的异同，就是加分项。
对与老旧的问题，比如 jquery 的问题，也会问与设计思想相关的问题，比如候选人不知道 $.delegate，也不知道其已被 $on 在 Jq3.0 取代，这不代表候选人能力不行，最多说明候选人比较年轻。此时应该通过引导的方式，让其思考如何优化 $.bind 方法的性能，通过逐步引导，判断候选人的思维活跃度有多强。
如何防止被套路
把面试官经验抛出来，怕不怕让候选人有所准备呢？ —— 说实在的，几乎所有候选人都是有准备的，也不差这一篇文章。
以上是开玩笑。
面试主要是看候选人基础有多扎实，和思维能力。基础主要指的是，候选人提前了解了多少前端相关知识，比如对闭包的理解，对原生 api 的理解？如果候选人没接触过这两个知识点，会有两种情况：
- 这些知识点看完需要多久？如果是闭包和原生 api 的定义与用法，候选人这方面的缺陷可以通过 5 分钟来弥补，那么这种问题到底想考什么？我们真的在乎这 5 分钟看文档的时间吗？此时应该了解候选人对知识点的感悟，或者学习方式，因为这两点的差距可能几年都无法弥补
- 如果候选人学习能力非常强，但几乎所有前端知识点都不了解，弥补完大概一共要花 1000*5 分钟，这时候量变引发质变了，是不是说明候选人本身对技术的热情存在问题？
通过了基础问题还远远不够。甚至当问一个复杂的问题的时候，如果候选人瞬间把答案完美流畅表达出来，说明这个问题基本上白问了。
技术面更应该考察候选人的思考过程和基于此来表达出的技术能力和项目经验。如果候选人基础没有落下太多，思维足够灵活，在过往项目中主动学习，并主导解决过项目问题，说明已经比较优秀了，我们招的每一人都应当拥有激情与学习能力。
所以，当问到候选人不了解的知识点时，通过引导并挖掘出候选人拥有多少问题解决能力，才是最大的权重项，如果这个问题候选人也提前准备了，那说明准备对了。
非技术相关
最后考察候选人的发展潜力与工作态度，我们一般通过询问简单的算法问题，进一步了解候选人是否对技术真正感兴趣，而不只是对前端工程感兴趣。同时，算法问题也考察候选人解决抽象问题的能力，或者让候选人设计一个组件，通过对组件需求的不断升级，考察候选人是否能及时给出解决方案。
最后是工作态度，首先会考察人品，对不懂的知识点装懂是违背诚信的行为，任何团队都不会要的。同时，不正视自己技术存在的盲点，将是技术发展的最大阻碍。不过这里也不怕被候选人套路，如果全部都回答不懂那也不用考虑了。
3 总结
由于经验不多，只能编出这些体会，希望求职者多一些真诚，少一些套路，就一定会找到满意的工作。
如果你想参与讨论，请点击这里，每周都有新的主题，每周五发布。