职业生涯迄今做了也有2，3百场的面试，过程中也一直在摸索该如何识别合适的候选人。正好最近启动了Bytebase的对外招聘工作，所以也借此写一点长期以来对于程序员面试招聘的思考。

程序员的面试通常会有2～4轮的技术面试再加上一轮HR的面试。其中技术面试的类型大致有这么几种：

  • 白板代码面试 (whiteboard live coding)，就是直接出算法题，让候选人现场写出来，大公司内部通常会有自己做的系统（基本都做的很烂）。外部的话，倒是最近发现了showmebug.com这款不错的面试工具。
  • 系统设计面试（system design)，比如如何设计一个搜索系统，一个秒杀系统。
  • 知识点面试，比如一些编程语言语法点和数据结构的考察，一些算法的复杂度。
  • 过往经历面试，根据候选人过往项目经历进行提问。

白板代码面试

我参与的绝大多数都是白板代码面试，如果去大厂应聘初中级职位的话，基本都会遇到这个类型的面试。国外的Google，国内的字节都是以白板面试的难度而出名。白板面试一直是一个比较有争议的话题，之前Homebrew作者因为不会实现反转二叉树而被Google拒绝也是上过twitter热搜。

首先白板面试有他的好处，就是过滤完全不靠谱的程序员，我在面试生涯中屡次碰到简历很好，结果连基本算法都写不清楚的候选人。

但白板面试也有他严重的局限性，它很像我们的高考，需要在极短的时间内，在无法借助任何外部资源的情况下，完成一些不太切合实际的题目。应对这样的测试，往往需要题海战术，所以也导致了现在大家面试前先要去leetcode上面刷题准备。就拿我自己来说，没有预先的演练，我是无法在考场上脑洞大开，突然划出那条辅助线。也同样的无法在白板上手撕红黑树。

白板面试考察的是在非常有限的时间内，在不借助任何外部资源的帮助下，解决一道相当确定的代码题目。这个很适合挑选参加算法比赛的选手，但在公司里，大家也都知道，日常工作中面临的问题和算法比赛是完全不同的。日常工作中，我们是在一个半开放的时间段内（有deadline，但也至少以天计，而不是以分钟计），解决一个有特定范围但还相对模糊的命题，更重要的是，我们是在一个开放的环境中，可以借助包括网络和同事的各种外部资源。所以说白板面试考察的技能和实际工作需要的技能并不那么匹配，而且采用越难的算法题目，这种不匹配度就越明显。就像高考一样，通过这种方法筛选出来的可能是一堆堆的做题家。当然能通过应试的，各方面的素质都还不错的，但未必能找到真正的product builder。所以我个人觉得这套面试手段更加适合校招的同学，对于社招来说并不是那么有效，很难挑中在工作中积累起product build能力的候选人。

不过总的来说，我对白板面试还是持中立偏正向的态度，当然我还是比较抵制leetcode中等以上难度的算法题。道理也和高考一样，这是唯一大规模招聘下还能做到相对公平，也能保证平均质量的招聘方法。上规模的公司一旦没有白板面试这道相对客观的招聘门槛，各种滥竽充数者会立马源源不断地涌入（这个涉及到组织的运行机制，有机会以后单独再写一篇）。

系统设计面试

这是我个人比较喜欢的面试类型，如果之前的面试官已经覆盖了白板测试，那我通常会选择这个类型。因为系统设计面试其实是可以涵盖其他几个类型的面试，同时系统设计面试中会产生更多的对话，所以也能更好地评估候选人的沟通技能。不过系统面试也有他的几个局限性：

  • 只适合考察有一定工作经验的候选人，毕竟需要实战的积累。
  • 对于面试官的要求比较高，白板面试因为是确定性的试题，所以面试官通常能做充分的准备。但系统设计属于开放性的问题，控场能力不足，是有可能被反杀的。受制于面试官的数量，公司也往往缺乏大规模采用系统设计面试的实操性。

知识点面试

我个人不太采用这种面试，就类似于问世界第二高峰是什么一样。但是一些最基本的知识点还是会快速考察一下，毕竟如果连第一高峰都不知道就有违常识了。之前在Google有碰到过一个合作对象，人家已经在那里干了好几年，居然连RPC都不知道。所以有些基本流程看似多余，其实是有兜底必要的。

过往经历面试

这个面试类型也比较常见，但很大一部分可以留给HR面，技术leader在一旁观察就行。单纯技术面试的话，如果候选人表现的有些紧张，从询问过往经历开始，让对方进入状态也是一种不错的方式。而如果面试过程中，候选人表现的不尽人意，最后也可以用过往经历收尾，平复一下对方的情绪。不过候选人的简历还是应该事先阅读，这样可以有针对性地设计面试题目，达到更好地评估候选人的目的。

技术面试的挑战

要获得心仪的工作对于候选人来说永远是充满挑战的，前期的精心准备，过程中的过关斩将，再到谈offer的拉锯。这里想再说一下面试官的角度，因为这同样是一个很有挑战性的任务，对于一个想认真组建团队（这个前提很关键）的技术leader来说，要能在有限的时间里判断一个候选人是否适合团队是相当困难的事情。而且作为技术leader，是需要能发现简历之外的信号，毕竟仅仅是根据过往经验给offer，HR出马就可以了。尤其是对于那些背景有硬伤的候选人，是否有能力在短短的面试过程中发掘到对方的闪光点，足够到不惜赌上自己的信用，和HR以及主管据理力争。

上面反复提到了时间，因为我认为时间依然是充分评估候选人的最大制约因素，尤其对于大公司来说，流水线的招聘模式锁死了面试官评估候选人的时间。而在这点上，初创公司未必有大公司般时间上的掣肘，所以可以尝试采用不同的面试做法。

我们在Bytebase采取的面试做法

Bytebase目前的招聘流程是这样的：

  1. 简历评估。
  2. 视频初步沟通 15 ～ 30 分钟。
  3. 一个带回去做的小题目，一周的时间，线下完成。
  4. 两轮技术面试，会结合之前做的小题目进行讨论以及其他的技术考察。每轮～1小时。
  5. Offer。

这里的特点是第三步，我们会让候选人带回去做一个我们设计的题目，而后续的技术面试也会涉及这个题目的讨论，这样设计的出发点有这么几个：

  1. 考察候选人的时间大大拉长了，因为我们评估的是对方在一周左右时间跨度的作品以及再结合实时面试的综合表现，而因为这一周是开放的形式，所以也更能全面考察对方过往的所有沉淀。
  2. 因为是开卷的形式，所以我们采用的都是半开放式的命题，考察的也是候选人的综合product build能力，而不是单方面的代码算法能力。前者更符合日常的工作场景，也是Bytebase希望寻找的「成长型」产品工程师。
  3. 也留给候选人更多的时间评估Bytebase，我们相信我们看中的候选人基本上也能拿到其他大厂的offer，而我们毕竟是初创公司，也希望给候选人更多的时间权衡利弊。

当然如何设计合适的题目是需要花一番心思的，因为Bytebase本身是完全开源的，所以我们把目前设计的题目也开源在了https://github.com/bytebase/interview，暂时只想到了3道题，后续我们想到新的题目也会补充上去，也欢迎大家来提PR。

这就是一些关于程序员招聘的思考，如果大家对于这个话题还感兴趣的话，后续我也可以写写自己理解下的Google，蚂蚁集团这些公司的招聘流程，以及他们背后的设计思路，还有如何跳槽和猎头打交道这些实操话题（都算是自己的踩坑经历吧）。

好了写这篇的主要目的其实还是为了Bytebase的招聘，欢迎大家参阅/转发/推荐「Bytebase的第一次对外招聘」，直接推荐成功者最新款iPhone Pro奉上。