从简历建立初印象
拿到简历后，首先我们应该对这个候选人建立一个初步的印象：
-
用过，以及最近用过哪些技术栈 这里关注的是候选人技术栈的广度，以及对哪些技术更熟练，面试应该侧重他更熟悉的方面考察。如果对方熟悉的却是自己并不知道的技术栈，应该在面试前大致了解一下。
-
做过哪些项目 有些人项目经验可能很多，但都是类似的技术栈和场景，因此我需要合并同类项，对这个人的项目做个分类，比如toB还是toC，pc还是mobile，工具类还是社交类。并且还需要思考这些项目，如果是自己来做，会有哪些技术选型偏好，或者可能会遇到哪些技术难题。
-
深度思考过哪些问题 深度思考的问题，可能是技术攻坚、源码解析，或者业务、产品、管理上的思考心得。从他思考的问题可以看出，这个人的兴趣是偏技术还是偏向产品，亦或是管理。
题库的准备与调整
我们对不同级别的技术岗位总有一套核心题库。比如用vue的岗位，如果答不上来双向绑定，那么可以确定他不适合p5级别的岗位，但若常见api都答不上来，可以确定连外包岗都无法胜任了。
但是匹配公司业务的题库，未必匹配候选人的经历。面试的目的之一，是明确候选人的能力。而能力，往往承载于他所做过的事情中。因此我们往往需要结合候选人的经历调整面试题。
比如，一般对高级别的技术岗，只掌握一个框架是不够的，但如果候选人过去三年只用了一个框架是否一定不合适这个岗位？如果公司的技术栈是react，但是候选人只有过vue的经验，我们并不能按部就班的根据标准题库设问，从而得出一个react经验不足，无法胜任的结论。
如果学习能力优秀，对已有的知识深入掌握，便能举一反三，只要两三天就可以上手一个新框架。我们不如设计一些vue相关的题目，看候选人的理解是否已经触及了框架的设计核心，或者看候选人能否在引导下理解框架间不同的设计理念：比如基于依赖收集和基于diff的更新策略优缺点，更新合并的异步与同步实现。如果候选人能够答上来，说明他只需极少的时间就可以胜任不同框架的项目，我们可以考虑往下进一步考察。
另外，基于候选人的经历设计问题，也能够让他更好地表现自己的能力。比如性能优化，如果是pc端开发者，可以从长列表优化开始切入，对移动端开发者，可以从首字节时间切入。这些问题并不是要候选人回答出所有场景的优化手段，而是看候选人对性能有没有意识以及思路是否正确。如果意识和思路都有问题，即便是有经验，再次面临类似的问题，仍难免会陷入困境。
总之，面试题应该结合候选人的经历进行设计或调整，找到对方擅长的点，不断深挖他的边界。
从自我介绍开始面试
题目有了，候选人也到了，你是否会以”请做个自我介绍吧“开始面试？等候选人介绍完了就无缝进入技术面试了？同样一个问题，你面向cto、hr还是面向一线技术官，解释的角度乃至比喻的方式总会不一样吧。如果让你与一个陌生人认识，你大概会和对方相互介绍一下自己，面试也是同理。
接到候选人后，我会先做个自我介绍，xx公司，xx部门，在做xx业务，是本次的技术面试官。面试的岗位是xx，时长大概多久，是否有机试，是否有旁听，录音等。这样候选人对这场面试和面试官有个更清楚的认识，后续可以用双方都能够理解的方式来沟通。我还遇到很多次，候选人投的是中级岗位，但是却安排了高级岗位的面试，有了这样的简短介绍，也能帮双方减少误会，节省不少时间。
及时给出反馈
一般情况下面试当场就可以得出这个候选人能不能通过本轮的结论，当然有些情况可能会需要和用人部门沟通后才能确定。但无论是否通过，都应该由hr来通知候选人。
不过我通常会在最后给出本次面试表现的反馈：你这次面试，哪些部分理解不足，哪个方面的能力需要加强。我觉得反馈是对这场面试双方所花费的时间的尊重。有心的候选人会从反馈中更好的认识自己，即使没有通过，也能以更好的状态面对其他面试。
常见的问题
- 候选人能力比自己强不少
不管面试什么样的候选人，面试官一定不要心虚，多根据对方的经历设计问题，即便是遇到了一些大神，也能对等的交流。
如果对方确实比你厉害，那么可以抛出一些你曾经深度思考过的问题与之讨论，注意这里是讨论，不是提问也不是请教。如果你真的思考过这些问题并有自己的答案，那么与对方思辨的过程中可以更加确定对方是只高出你一点点还是高出你很多。
面对一个比你强的人，没必要试图测试出他的能力边界，面试后在评价里备注上这个人的能力评价以及可能适合的职级，交给后续的面试流程即可。
- 如何识别有潜力的候选人 首先有潜力的候选人，能力必定是超出同年限的平均能力的。除了这个我们还需要去寻找技术外的亮点，比如坚持博客、反思复盘的习惯、跳出自己的角色多角度看待问题、良好的沟通能力、时间管理。同时还要帮他考虑，他所面的岗位，是否能够让他将这些亮点更多的发挥出来。面试的过程中总会遇到一些自己欣赏的人，但始终不要忘记因岗择人。
