这个月是第一次以面试官的身份参加校招，至此已经参加三批校招（一次笔试为一批），我负责的是一面，共和 37 位候选人交流，其中 10 人通过本轮面试。下一批面试要到下个月了，因此很适合在这个节点记录一下这段体验。

如何进行技术面试

“八股文”这个词在招聘中广为流传，我一直认为这种一问一答没有深度的八股交流无法筛选出合适的人才，从我最初面试实习生开始，便打定我不会做这样的面试官的想法。从实际面试经历中，确实可以看到许多候选人对于知识点侃侃而谈，一旦深入或进行编码便寸步难行。由于前端的入门门槛比较低，转行的或者学习时间短的较多，因此这种现象非常普遍。

一面主要关注「基础知识」和「编码能力」，我进行技术面试的策略是：问题都从一个需求或者实际场景出发编写代码，在编写代码的过程中进行细节询问或者内容扩展让知识点尽量串联。比如：

可以从一个函数出发，逐步扩展：

• 为了确保后面某些操作的正常执行，我们需要对函数的入参进行类型判断
• 现在确定入参是一个对象，那么我们来遍历这个对象，这里就可以考察原型相关内容；对象属性不允许修改谈到 defineProperty 、Vue 双向绑定等，这里又可以衍生出一些场景问题
• 实现某个逻辑执行前停顿 3s，聊到 Promise、聊到异步

可以从前端每两秒轮询调用后端接口拿到某个数据内容这个常见的业务场景出发：

• 完成基本编码
• 如果候选人使用了 setInterval，便可以和他说如果后端的接口耗时很长，这里会有什么问题？如何解决这个问题；如果候选人使用了这个场景下应该使用的 setTimeout 解决方案，便询问是基于什么考虑没有使用 setInterval。总之这里可以考察到 setTimeout 和 setInterval 的共性和区别，也可以考察候选人分析问题理解问题的能力
• 当然这里也可以从定时器聊到事件循环

这种方式考察基础知识的同时，也编写了较多的代码，但这些代码比较零碎，篇幅也不会很长，虽然能一定程度反映出编码风格，但编码这块还是需要所谓的“做题环节”进一步考察。相对于 leetcode 上的题，我更喜欢一些在实际工作中常遇到过的数据转换、查找的问题，这些问题有些是需要对 JavaScript 有较好的了解才可以写出可读性好的代码；有些是需要考虑到足够的用例场景；有些是半开放性的，需要沟通这里是否有 xx 方法已经在业务中存在了。

这样的面试方式对于候选人来说是高质量的能力考察，在实际面试中有三类表现：

• 如果是仅仅停留在“八股文”这个层面而没有写过足量代码练习的候选人，会步步难行，一般在面试开始十分钟后逐渐破防。最初自我介绍时声音洪亮，逐渐声音弱小，对于自己的回答开始不自信，其中有一位女生我甚至感觉快要落泪了
• 进行过一定的编码练习且在前端领域投入过一定时间的候选人，虽然会有中途卡顿、想不出来的情况，但是经过引导最终顺利想清楚问题，面试官和候选人都会有一种协作的快乐
• 能力较强的候选人会和面试官聊得非常开心，你知道我想问的是什么，我给的就是你想要的。

在面试结束后许多候选人对我表示了感谢，说这种引导式的面试比之前参加过的一问一答的体验好多了，从面试过程中学到了很多东西，也知道了自己哪里不够好。我对于他们的感谢非常开心，这也是我期望中的理想面试。面试者可以从面试中展现自己、学到东西、认识到不足；面试官可以从面试过程中考察到自己想要的东西、修正自己不够清楚的问题阐述方式、学会如何对候选人思维进行引导、如何感受和转移候选人的情绪变化。

不过这种面试也存在问题，一方面是内容过于充实，导致面试时间经常不够；另一方面是对于面试官来说有点累。在某天劳累的面试结束后，我坐在地铁上不禁对自己面试反省。

首先，我认为这样的方式对面试官的要求是比较高的，也许经验丰富、能力强的面试官可以做到手到擒来，但是对于我来说，不得不在面试前思考我会从哪些知识点考察候选人，这些知识点如何通过一些场景在编码中进行串联考察。这需要花一定的精力和时间去准备一场面试。

另外，在候选人非常一般的情况下，我需要想尽各种方式，甚至需要打起问题答案的“擦边球”引导，当面试场次频繁的情况下对于脑力和耐心的消耗是比较大的。有时候甚至仿佛是在手把手教学生明白如何解决这个问题，这一块的原理是什么。这一点尤其让我自我反省这是否是必要的；有时候甚至觉得这种考查方式或者我的行为方式是有问题的；也会觉得一问一答，不会就打断跳过的面试方式确实会轻松很多。

候选人卡住时怎么办

候选人在面试这种高压环境下，因为紧张等原因卡住非常正常，这个时候我们的适当引导是非常有必要的。我一般会这样做：

如果候选人的思路正确，首先对候选人思路进行肯定，继而提醒他可能是什么没有想清楚。比如有个候选人在一个问题解决中卡在将 Map<string, number> 这个数据结构根据 number 进行排序并转为二维数组时，便可以提醒他这个问题通过 Map 进行统计的想法是正确的，但这里使用循环遍历 Map 进行重新排序以及二维数组转换有点麻烦，我们是不是可以想一下在 JavaScript 中 Map 和二维数组是不是有什么联系？

我们可以让候选人重新阐述思路或者我们进行引导，并在白板上写出思路中的关键字。比如说用 JavaScript 实现一个 sleep 函数，有些候选人想不到解决方式。这时候便可以这样引导：

• 我们在 JavaScript 中，有一个同步阻塞的方式，是什么呢？候选人提到 await
• 那 await 它等待的是什么呢？候选人思考后回答是等待 Promise 完成
• 那 Promise 它有哪几个状态呢？什么时候才算完成呢
• 那这里如何实现一个 Promise 3s 后完成？候选人答使用 setTimeout

这样下来，候选人能力正常的情况下，根据这些关键词，应该就可以想到解决方法了。

如果经过引导候选人还是没能想出答案，而面试时间并不允许长时间停留于此，那么就只能对候选人进行情绪安慰，比如可以表示这里没有想（做）出来没关系哈，你的想法是正确的/已经很接近了，主要是这个思考过程答案并不重要哈。我们继续探讨后面的内容。

候选人反问

候选人反问一般喜欢问部门做什么的、学习建议、面试评价、内部技术栈这几个问题。我觉得对于反问，面试官应该真实、真诚，不要不好意思说。尤其是“面试评价”这个问题，我觉得相比于明明表现不够好但却夸赞，结束后将候选人挂掉，不如真实的和候选人说他的优点和不足，适当给予建议。前者虽然在面试时心里似乎比较好受，大家相互也是 peace&love，但是收到拒信后会很失望甚至难过吧，心里也免不了去想很久的为什么。

如何做决定

不通过的候选人基本在面试过程中就有了决定，但是总会有一些让你纠结一二的候选人。可以通过下面几点做决定：

• 你愿不愿意和他做同事？
• 如果他入职后是你做导师，你愿不愿意培养他？
• 沟通能力、表达能力、逻辑能力
• 有没有感受到技术热情

其他

表达和礼貌

面试官代表公司形象，在面试过程中不管是态度还是用词，对候选人要礼貌、尊重、平等。在提问时要注意问题的边界。同时阐述问题时不要故弄玄虚，清晰准确地表达想要问的问题即可，如果候选人回答的方向是错误的理解了问题意思，这个时候可以适当回头想想是不是自己阐述方式有些问题。

面试和上班

面试比上班累多了！一天 7-10 个，45 分钟一个，每个之间 15 分钟，经常出现上一个面试评价刚写完就要开始下一个的情况，因此休息时间很短。

关于运气

以前听人说面试是一门“玄学”，这次我多少也感受到这一点意味，其中我最想提一下的是招聘策略调整导致后批次面试难度下降。

在秋招开始前，我们面试官群里发了一个文档，里面有一部分是“总体原则”，其中两点有所争议：基础好但看不出什么潜力的，淘汰；前端学习时间短，但觉得学习能力强的，淘汰。

基于这个文档里的一些内容，前两批面试的通过率比较低，我手上挂了非常多的大厂实习+本硕 985 的候选人。后面到第三批时 HR 说我们前端这边的一面通过率只有 20% 多，其他部门有 40%，因此到第三批策略进行了调整，具体内容不言，简而言之就是要求有所降低。当时我想起了几个我纠结过但最后淘汰的候选人，心里有不平、内疚、可惜等混合心情。

当然“运气”这部分更多的还是在面试官的问题是否刚好命中到候选人准备的点上等情况，像上面这种问题应该还是比较少吧？

 秋招存在不老实的行为现象

我遇到过两三个候选人面试过程中让我感觉存在“可疑行为”。一种是眼神飘忽不定，上下看或者左右看，仿佛旁边有参考资料；一种是写代码或者回答问题时断断续续，突然变得流利或下笔如有神。候选人还是太自作聪明了，这种视频面试一举一动都是清楚的，面试官也不是傻子；而且面试时也会拿到一份笔试的作弊判断报告。

寒气

手上简历的“硬度”还算是不错，60% 的候选人是硕士，60% 的候选人是 211 以上，我感觉这个节点应该不算秋招的早期吧，基本大家都还没有拿到 offer。40% 的候选人有大厂的实习经历，无一转正，原因清一色的今年没有转正名额。

Comments: