你好,我是四火。

“工欲善其事,必先利其器”,在专栏前面的部分,我们已经讲了怎样理解团队的需要,怎样做面试计划,以及怎样设计合适的技术问题,这些,可以说都是在正式面试之前需要搞定的事情。

今天这节课,我将会和你分享面试流程把控的基本思路,以及一些常用技巧。只有把控好流程,我们前面辛苦设计的面试计划、技术问题才能真正派上用场。

流程把控的反面例子

先来问一个开门见山的问题,究竟谁来把控面试流程,候选人还是面试官?

有人说是候选人,当候选人带着自由度表现的时候,才能发挥自己的实力;有人说是面试官,因为面试官需要按照预想,领着候选人来推进面试进展。

好像都有道理对不对?我卖个关子,先不回答这个问题,带着这个问题,我们来看看几个流程把控的反面例子。看看这些例子中,有没有你熟悉的。

收尾时间狂飙代码

这可能是一个一下就映入脑海的反面例子了,也是我见到的最多的一种流程把控的反面例子。

无论是由于问题过于复杂、沟通出现误会、候选人解决问题能力不强,或是候选人或面试官迟到等等原因,到了白板编码环节,候选人有了思路,也开始写了,可时间快没了。

这时候直接放弃吧,有点可惜,于是候选人就擦擦额头上的汗珠,颤抖地拿起记号笔,开始马力十足地在白板上狂奔,字也是越写越龙飞凤舞;而面试官呢,也颇为体谅,让下一位面试官在门外稍加等待,要求延期“就五分钟”,并不断提醒候选人时间越来越少。

最后,无论代码是否写完,面试匆匆结束,就仿佛一场大战结束,候选人累得瘫坐下来,这一轮的面试官一只脚刚迈出会议室,下一轮的面试官另一只脚就迈进来。若是代码基本写完了,候选人心里想,我去,真够紧张刺激,幸亏老子搞定了;若是没写完,可得失落和恍惚好一阵子。结束的时候,双方礼貌性地握手,手心满是汗。

寒暄时间占比不当

这里的“寒暄时间”,指的是技术面试中,正儿八经讨论技术问题以外的时间,一般发生在面试开始时和结束前。

一种极端情况是这个时间过短,甚至没有。候选人和面试官见了面,握个手,就开始做题,连个过渡都没有,让人觉得颇为唐突——“是不是这个团队都是老古板啊?”。

另一种极端情况是,打个招呼,互相介绍一下,聊两句感兴趣的话题,或是最近的热点新闻。扯扯淡,聊聊天,帮助候选人放松一下。本来这些都是挺好的“操作”,但问题是这个时间如果拖得太长,原本的技术考察重点就打了折扣。

我分享一个我shadow(观摩)的经历,有一位面试官在面试中和候选人“闲聊”,面试的一半时间过去了,候选人终于忍不住了,她主动问面试官,“咱们不谈点什么技术问题吗?还是继续这样随便聊吗?”,他们这才开始讨论技术。

考虑到在面试计划的时候,这位面试官是确定要考察算法和数据结构的,因此事后我问面试官,我理解这也是一种面试风格,可既然面试计划已经确定了,你为什么没有主导这个面试过程,让技术方面的讨论早一点开始?面试官回答说,他想看看候选人有没有足够的主动性主导这个面试过程。

对于这个案例,我的想法是,面试官这样做,虽然考察了他所关心的“候选人的主动性”这个数据点,但也使得这个面试偏离了原本的计划,也就是说,在我看来,确有所得,但得不偿失。

踌躇不定的思路选择

这个例子是来自于我自己。

一个问题往往有很多解决的思路,有一次,候选人和我讨论某个问题的算法,这个过程一开始还挺顺利,候选人选择使用Map+数组排序的思路做,方案虽然略有一些硬伤,但是也行得通;期间他忽然想到,使用一个二叉搜索树数据结构的思路更好,于是我们又放弃了前面的思路,沿着这条路推进;结果忙活到一半,他忽然再一次“恍然大悟”,觉得可以用一个Map+链表的方式来做更简单。

这整个过程其实没有太大的问题,整个思路的转变,反映了候选人很好的思考能力,能够跳出具体实现,重新审视问题。

但是由于这一系列的思路调整耽误了太长时间,导致到面试结束的时候,我们只讨论了思路,连完整的方案都没有讨论清楚,自然原本计划的编码根本没有时间开展。从考察角度来说的话,我们就丢失了相当一部分考察项的覆盖。

流程把控的技巧

不知道刚才那几个例子是否给你带来了似曾相识的感觉?其实这些反例说到底还是因为流程把控没做好。

那既然如此,下面我就来正面谈一谈我的理解,带你一起看看有哪些流程把控的技巧。这些技巧能够帮助我们在面试中,保证最核心的考察项能够覆盖到,同时,还能够给候选人留下一个好印象。毕竟,如同我们在专栏前文中所说,面试是“双向”的。

有头有尾,有礼有节

首先我要谈的,不是什么复杂的技巧,而是礼节。

什么,礼节?对,你没有看错。我认为,面试官有义务确保考察过程的完整性,这能让候选人心情愉悦,在友好的氛围里完成面试的过程。

不知你是否听说过,有一些面试的风格颇为激进,甚至不尊重人,观察候选人在极端压力下的表现。也许这确实可以让面试官得到他想要的考察数据,但我认为这是非常不妥的。

面试,说到底是社交活动的一种,我们必须建立在平等和尊重的基础上,我们要达到目的,但不能不择手段,因此在我看来,这就是一个根本性的错误。

我觉得面试就有点像是江湖上相逢,缘分一场,我们客客气气地切磋武艺,点到为止,你我互相尊重,为的也是来日好再相见。

面试应该做到有头有尾,在面试开始时,我们可以:

而在面试结束前,我们可以:

对于电话面试,或者是特殊时期的线上面试,不能握手了,可上面大部分礼节还是一样的。上述这样的过程也许用不了5分钟、10分钟,但是面试的整个过程显得自然、得体,并且也能够帮助候选人放松。

你看,这些有什么特别的技巧吗?完全没有,上面这些哪是在说面试啊,其实只是礼仪之邦的待客之道对不对?

没错!其实,要做到上面这些,只需要细心,并不需要多么高深的技巧,但是却能够令候选人大大提升印象分。还是那句话,面试是双向的。面对多家竞争对手的时候,你肯定希望优秀的候选人能够选择你的公司和团队。

我说一个我自己的故事,那是在好几年前了,我在找工作期间,在国内几个城市都面试了几家公司,只有当时在北京的亚马逊,面试的过程中,面试官主动给我倒水,面试完毕后送我离开(当时需要上出租车,赶去机场)。且不说面试的内容,这些细节给了我非常正面的印象,我相信无论业务和技术怎样,面试我的团队至少是非常懂得尊重人的。

做一个完整的项目

对于技术面试而言,面试官要抱着和候选人一起做一个有头有尾的迷你项目的心态。

这里,“迷你项目”这四个字可以说是重中之重,即所谓“麻雀虽小而五脏俱全”。这个问题的解决过程要完整,从需求澄清,到分解、设计、抽象、落地、验证、改进,有头有尾。

举例来说,前文所谈到的这个网约车的问题,我们考察的是数据结构和算法,在代码层面“落地”的思路沟通清楚以后,就可以写白板代码了。

在代码完成后,候选人可以使用一个简单用例走读代码,验证正确性。再之后,面试官还可以提出“follow-up”问题,比如聊一聊有什么瓶颈,怎么改进。

好,我想从中你可以看到这样一个完整的过程,而理想的面试,确实也不应该在中间的某一个过程戛然而止。

比方说,如果代码实现的思路讨论清楚了,但是因为没有时间完成代码实现,想必候选人也会觉得沮丧;而只有一个完整的过程,才会让候选人如释重负,有一种“项目完成了”的成就感。

举例来说,一个模糊的问题,一个代码层面考察(例如算法和数据结构)的路径,一轮面试总时间为1小时,而去除寒暄和收尾的环节,核心时间为50分钟,那么可以参考这样一个时间分配的思路:

你可能会问,现场编码只有15分钟,这么短的时间,够吗?

够。这里我必须说明的是,在编码前,我们期待候选人和面试官已经将思路大体上沟通清楚了,那么这个编码过程,其实只不过是一个将思路“翻译”成代码的过程而已。

我们在编码前对于思路和逻辑的讨论,目的就是要保证编码能够顺利进行,所有的关于“problem solving”的部分基本已经解决,于是就只剩编码过程。

值得注意的是,编码前的思路和讨论,以及编码本身,我们考察的侧重点是不一样的。比方说,有的候选人就是具备很强的逻辑能力,来解决问题,但是就是无法将思路落实到代码上。因此,别看过程很短暂,却是不可缺少的。

你可能也注意到,在需求确认以后,很多候选人都喜欢上来就立马落笔写代码,但作为面试官来说,是不是可以落笔,需要着重关注候选人是不是已经有了清晰的思路,否则很可能浪费时间。这样急于落笔也很难一蹴而就,来回涂改,会做很多无用功。

如果你留意到,候选人即便有了清晰的思路,在基础编码能力具备的情况下,代码的实现依然要花费超过15分钟,那么你就应该考虑调整这个问题的设计了,是不是要求代码实现的部分过于复杂,从而最终导致在限定时间内,整个问题的解决流程无法完成。

如果是这种情况,我们可以要求只实现代码片段,例如算法的核心部分,或者是涉及到的几个重要的类,而不是整段代码。通过这种方式,我们可以将预期的编码时长降下来。

举例来说,如果实现一个完整的LRU缓存颇为耗时,那么算法实现可以要求写出数据结构,以及其中缓存更新的部分。

另外,你可能还听说过,在有些面试中,面试官会在一轮面试中,要求实现两个较为简单的算法。这种情况确实有,但是我一般是不推荐的,原因就是,这整个问题的讨论和解决过程已经颇为耗时了,很难在一轮面试中覆盖一个以上的算法实现。

如果硬要塞进两个算法题的实现,那就要问非常简单的问题,那么,即便勉强做到了,用意又何在呢?

选择合适的介入时机

还记得这一讲一开始,我开门见山地问的那个问题吗?“究竟谁来把控面试流程,候选人还是面试官?”

我打个比方,一个国家的经济活动有强有弱,走势有高有低,通常情况下,从大体上看,市场经济可以自然地发展,但是在某些特殊环节,或者极端情况下,国家需要介入,需要调控。

面试也是如此。我认为,在核心时间中,面试官应该关注于大的层面上,是不是能够顺利完成今天的考察内容,是不是能够得到自己关心的考察数据。

如果候选人能力很强,对于问题的推进合理有效,那么面试官就要学会做“绿叶”,给对方更多的发挥空间,让对方去主导问题的解决,这当然是最理想的情况,候选人能跟着自己的计划走,自然也最舒服。

反之,如果遇到了困难(还记得我们上一讲在“设定‘踮踮脚能够到’的最高难度”部分,谈到的降低难度的方法吗?),或者看着路线要“跑偏”,或者时间进度已经大大落后,那么面试官就要毫不犹豫地及时介入,主动调控,从而保证整个方向和时间的可控。

总结与思考

好,今天我们开始讲怎样主导技术面试,把控流程了,既谈到了一些常见的反面例子,又介绍了我们应该掌握怎样的技巧,完成一个成功的技术面试。

在这一讲的最后,我想再次强调“互相尊重”的重要性,虽然我不会在专栏中再反复强调它,但请记得它是我们面试等一切职业行为的最基本要求。

最后,我有一个问题,正在阅读的你,能否在评论区和大家一起聊一聊,你作为候选人参与过的面试,都有哪一些有意思的细节呢?期待你的分享。

好,我是四火,我们下一讲见!

评论