近期面试观摩的一些思考

作为软件工程师,工作有一些年头了,在不同的公司,也面试过不少人。以前没觉得这事儿多有意思,但是这几年想法改变了,我发现在一家公司,去面试不同的候选人,是一个非常有价值的增长阅历、经验,让自己成长的机会,还有机会见识到各种各样的人的,获知他们不同的思考问题的方式。特别是作为 bartender(在 Oracle,bartender 基本上就是面试的技术负责人,所有团队招人,都必须有一个来自别的团队的 bartender 来保证候选人的水准,具体的面试流程你可以参考一下我写过的 这个专栏 ),这样的机会有很多,虽然会占用一些自己团队和项目的时间,但是和收获比起来,显然是很有价值的。

最近跟一些公司内一些经验特别丰富的 bartender 交流,并实际地 shadow(包括 reverse shadow)了一些他们的面试,学习了一些面试方法,包括其间的各种思路和套路,感觉有不少收获。有几个 bartender 是 IC-6 的级别,这个基本上就是 Oracle 的工程师技术上升通道上理论上能够达到的最高级别了,整个公司也没几个人;还有几个则是在 Oracle 有了几百次面试的经验,也可以说是阅人无数了。因此无论从哪个角度说,这样的学习机会都是很难得的。这里说的 shadow,就是 “观摩”,指的是这些经验丰富的工程师面试,我旁观,结束之后大家再切磋一下;而 reverse shadow,则是反过来,我面试,他们中的某一个旁观,结束之后再切磋一下。

这里面有几个思路、观点,我在这里记录和分享一下,有一些是来自别的同事,有一些则是自己的。当然,需要明确的是,面试没有什么 “最佳实践”,在这么短的时间内要对一个候选人定性,本来就是一件非常困难的事情。

采纳推荐人的意见

有时候候选人有公司内的员工推荐,大家都认为推荐人的意见往往非常有价值,因为面试官可能就花了一个小时和候选人接触,而推荐人则可能和候选人一起工作过很长时间,显然这样的评估更为全面。

在 debrief(相当于面试之后所有面试者聚到一起,评估应聘者的的讨论会)的时候,我看到了一些不同的做法。而我的方法是, 请推荐人进入这个会议,接受 “拷问”,但是询问清楚几个问题以后,就请他离开 ,以避免他知道任何 debrief 的进程和结果——因为这些既是对于候选人隐私的泄露,又可能造成他被候选人询问时而可能出现的为难。因此我们让他离开可以让这个状况变得简单,同时我们要让推荐人知道,这些内容是严格保密的。这几个问题是:

  • 你对候选人的推荐程度是什么,为什么?我们知道有些候选人的推荐 “只是认识而已”,有些对于候选人的推荐则 “愿意赌上我的名义”。
  • 你觉得候选人有哪些优缺点?这些优缺点我们可以重点结合面试的反馈做出进一步的评估。
  • 你和候选人是否熟悉,你们是否一起工作过,什么时候工作过,有多长时间?
  • 你在公司、团队工作多长时间了,你的职位和角色是什么?这也是一个必要的问题,显然一个更熟悉本公司、本团队的员工,更熟悉文化,理解产品,这样的推荐往往更有价值。

对,就这些问题,其实 这些问题基本上就是为了明确两个事情:(1)推荐人对候选人的评价本身,以及(2)到底这个评价到底在对候选人的整个评估体系中赋予多大的权重。 当然,也可以询问其他问题,但是上面这几个问题是必须要覆盖到的。

分析问题的角度

对于一些有经验的程序员候选人,在得到一个粗略的、缺乏整理的问题的时候,他会一层一层地抽丝剥茧,把问题梳理清楚。在设计的时候也是如此,而不是很快地跳进问题解决的泥潭中。当然也有很多候选人,也许是大多数候选人,他们上来就开始动手,行动的意愿极其强烈,仿佛只有这样才算有了进展,心里才感到安心。

以往,当我遇到上述后者这样的候选人的时候,我可能会尝试中断候选人这样的做法,并问到,“你想清楚了吗?”,或者是,“你实现的思路是否已经明确?”,以希望候选人 “想清楚了再动手”。

但我现在觉得更好的做法,特别是对于一些经验相对较为缺乏的程序员来说,是顺其自然。尽管这意味着可能会出现设计上大量的反复,可能会出现实现上大量的涂改,候选人可能也将不得不磕磕绊绊,面对并解决一个一个的问题,并低效和曲折地逐步接近他的目标。这没有错,但是 如果你强行改变候选人的思维方式,他可能将因此迷失 。因为每个人的思维方式是不一样的,一般说来,比较理想的方式可能是自上而下的,更有统筹和规划性,可是自下而上却更为容易思考、更容易开始。

这让我想起了 TDD(测试驱动开发),它就鼓励(即便这种鼓励并非出于 TDD 的本意)问题没想清楚之前,就动手,然后逐步往上迭代进新的分支用例。不可否认这种方式有它的好处,但是我依然认为,还是 “想清楚了再动手” 更为理想,至少要把大致思路和重要的分支用例想清楚,在面试中其实也是如此,可是我们当然应当容许不同的思维方式。

另一方面,如果通过这种自下而上的相对低效的方式,候选人能够不断地发现问题,思考解决方案,并不需要面试官较多的指引,就可以独立不断地解决这一个一个的小困难,这就是一个很明确的闪光点了。但这大多是对于经验较少、级别较初级的程序员来说的,他们如果通过了面试,在团队中还需要得到进一步的引导,慢慢改进自己的问题分析和解决方法。相应地,对于一些已经是 “老司机” 的候选人,如果还使用这种自底向上方式来分析解决问题,而没有一个俯瞰的、纵览的视图,这显然就不是一件好事了。

问项目、挖简历的占比

我们的面试中,有一项内容就是挖掘简历和项目,就是说根据候选人的项目经验,找到一个点往深了挖,以了解他是怎样工作的,完成了怎样的成就,从中可以看出很多问题,特别是能够把那些实际做事的人和那些口若悬河的人给区分开。

这个方法其实很好,但是需要注意的是,针对不同的候选人,这种方式在整个面试过程中的占比应该有所不同。具体说,对于经验较少的候选人来说,这个过程可以短一些,因为经验较少,能问出的内容和价值也相对较低;而对于那些几十年经验的程序员,则要多问,不但容易发现闪光点,也容易发现问题。而且,有趣的一点是, 对于特别有经验的程序员,你去仔细挖掘他的简历,还往往是一种 “尊重” 的体现 ,我听说有的面试官,面试一位工作了二十几年的程序员,上来就让写快排,这立马就把对方惹恼了。我们且不说这种面试方法对不对、好不好,也不说候选人的气量如何,但显然把对方惹恼这件事情是很容易理解的。面试过程毕竟是双向的,面试官有义务尽量保持候选人一个愉快的体验,这一点,下文我还会讲到。

主要问题的选择

对于面试过程中,时间占比比较大的那个 “主要问题”,我们都知道要选择一个模糊的、最好是实际的问题,面试官会和候选人花费几十分钟时间,一起来解决这个问题,期间会考察多个方面。但是除此之外,还有一些要点:

  • 不要一味避开那些常见问题,更重要的是要选择自己有着透彻思考的问题,可以是实际项目的问题;
  • 从算法和设计的角度来说,都要允许存在多个解,并且它们可以进行 trade-off;
  • 最好能够存在一些特殊的 case 以考察候选人思考问题的全面性;
  • 可以使用同一个问题问不同级别和经验的候选人,这样以便于把候选人放到一定纵深的实例集合中去比较考察。

快乐,不要沮丧

无论是成功还是失败,都不要让候选人觉得沮丧。最理想的面试,是能够通过一步一步引导,总让候选人觉得不断在进展,并且 问题,或者是子问题的难度总是处于 “垫脚尖能够到” 的程度 ,难了容易灰心丧气,容易了又不能考察出候选人的能力边界。无论候选人能够通过面试,还是不能通过,希望这个过程对他来说,是快乐的,是一次正面的体验。

有人会质疑这一点,如果候选人觉得体验很好,但是最后却没能通过面试,这样的对比是不是更糟?有道理,但是,和留下糟糕的经历这样的印象比较起来,还是留下好的体验更值得。即便候选人没有通过面试,但是他依然可以去和他的朋友说,虽然我没有通过,还是推荐你去。另外,不要在面试的进程中放出任何通过、或是不通过面试的信号。

在面试讨论问题的进程中,需要尽量给候选人一定的自由度。有时候我们希望得到更多的候选人的数据,就会接连发问,可是,这样却可能适得其反,候选人会疲于应付接二连三抛出的问题,而失去靠自己独立去思考和发现问题的机会。

最后,我要说的是,在一个面试的 loop 中,除了 Hiring Manager(招聘经理),其它面试官一般都来自招聘经理自己的团队,唯有 bartender 是个例外,他必须来自其他团队,这是为了避免利益相关性上过度的集中,必须引入的一种分散机制(其实我认为这种机制的分散程度还是不足够的,我知道有一些其它的互联网公司有更好的办法)。因此,bartender 必须要有足够的 backbone,其肩上的担子也会尤其重,这个角色的重要性不言而喻。

我来评几句
登录后评论

已发表评论数()

相关站点

+订阅
热门文章