如何轻松通过 ArcBlock 的招聘流程

以下内容，则是让对 ArcBlock 有兴趣的应聘者更好地了解我们的招聘流程，更轻松地通过我们的面试。

ArcBlock 的招聘流程

ArcBlock 目前的招聘流程是我对微软招聘流程的优化。

微软各个组的流程略有不同，但总体上都是非常严格的，每一个 hire（雇用） 公司都需要花费很多人力和时间。而我原来所在的微软研究院又以面试非常严格而知名。

•HR 简历筛选
•电话技术筛选（2 轮，每轮约 45 分钟，电话/skype/屏幕共享核实简历中的技术内容，一般也会有 coding（编程），相对比较简单）
•Coding Test（编程测试，自动计时，约 1 小时，完成代码提交）
•面试 （3 ～ 5 轮，coding，设计，未来的团队成员、下属、经理，通常包括一轮共进午餐的面试）
•经理面试（如果之前面试结论是 hire）
•发出 offer（电话）

面试的那天，一般而言如果有两轮 no hire（不雇用），就不会继续，下面的面试全部取消。因此一个候选人如果 HR 通知计划 5 轮面试，却没有面满，那么基本上就是 no hire 了。反之，通常到达最后一轮面试，意味着有相当大的可能会 hire。

微软的面试每轮之间是交换意见的，也就是下一轮面试者知道上一轮面试的结果，以及上一轮会建议下一轮注重什么问题，ArcBlock 也采用这种做法。据说 Google 采用不同的做法，每一轮面试都是独立的，然后统一由一个委员会来综合评估。

ArcBlock 现在的招聘流程：

•简历筛选
•电话（30 ～ 45 分钟左右，互相介绍为主）
•Coding Test（允许多达一周的时间）
•面试 （如果上一轮代码测试通过，至少 2 轮）
•经理面试 （如果前面的面试结论一致为 hire）
•发出 offer

可见我们的流程基本类似，但是在轮次时间上减少了不少，另一个特点是我们的 Coding Test 环节有更高的要求，但同时也给了更充分的时间，让应聘者有更充分的机会展现自己的实力。

ArcBlock 的代码测试

无论在微软还是在创业公司，我都会遇到一些人不太认可我们的招聘面试方式。比如我们的 Coding Test，在我们看来是最重要的环节，因为这是在一个轻松、无压力的环境下解决一个目标明确的小问题，又给予非常足够的自由度。当然对某些人而言，这种“自由度”恰恰就是“目标模糊”——其实哪一种观点都是正确的，但是我们模拟的正是我们团队的工作方式，希望任务的规定非常细致的人可能在其他团队是非常宝贵的人力资源，但在 ArcBlock 团队却不会那么契合。

我在过去某大公司工作时曾经碰到过候选人拒绝一个系统设计的题目，提出除非我们和他签署保密协议或者公司雇佣他之后才会分享他的“绝妙”思路；也有候选人认为我们要求做 Coding Test 是借机推广我们的技术，甚至有写文章公开我们的题目并且公开批评我们的做法等。这些看起来好像是负面的，但实际上正充分说明了这个筛选流程的有效性，这些候选人也许的确有不凡的思路和个性，但至少表明他们和我们有着不同的价值观和认知，及早发现并终止，不浪费双方的时间，不雇佣不合适的人选，这对双方都是最大的收获。

ArcBlock 的面试：没有刷题的必要

除了 Coding Test，我们每轮面试都会让候选人写一些比较“简单”的代码。现在科技公司的编程面试已经很普及了，因此可能大家已经比较适应了。

过去 10 多年来，很多科技公司喜欢在面试中出一些“高难度”烧脑的算法题，导致“刷题”变得越来越严重，但是最近大家普遍不再搞这些靠刷题训练可以绕过的 Coding Test 了，ArcBlock 也不例外。ArcBlock 的编程测试，无论是上述 Coding Test 里的，还是面试中的（基本我们每轮面试，都不可避免要写一些代码），我们都力图以比较简单直接的题目来面试， 即便是算法类型的代码测试， 我们也力图避免那种没有“复习”过就不会的题目。

举一个面试中我用过的实例，例如：实现一个把整数字符串转换为整数的函数（C 相当于 C 语言里的 itoa），这是一个非常简单的题目，即使没有学过算法的知识也应该能够实现。但实际上我发现在我过去的面试里有超过 80%的人不能正确完整写出这个代码，主要是在一些边界条件上考虑不足（例如带符号的整数的处理、超大整数的处理等）。

我们另外一种题目是答案“开放”的题目，通常从一个非常简单的程序开始，逐渐加大难度，直到变成一个非常难的题目。例如我实际面试中会拿 T9 输入法来实现，从一个最简单的版本，然后逐渐要求实现带有联想输入，考虑各种优化的版本。这种开放类型的面试题没有标准答案，而且会越来越难，可以充分考察一个人的综合能力。

面试是双向选择的过程

面试不仅仅是公司在面试求职者， 也是求职者在面试公司。

正常情况下，IT 行业招聘和应聘双方是相当平等的。作为求职者毫无疑问希望能通过面试获得 Offer，也许这是一份自己很喜欢的工作，也许团队里有自己向往的技术氛围和同事，因此其迫切的心情是可以理解的。其实作为招聘者的公司也同样的迫切，有很多的任务需要人手来完成或开拓，巴不得马上找到合适的人选。在招聘的时候，公司会想方设法了解应聘者。应聘者也应该利用这个机会多了解公司，判断这是否是适合自己的地方。

在面试的时候，我们可能会问应聘者“你有些什么问题？”，这是提问的好时机。一般在一个 60 分钟的面试，我会 2 ～ 3 分钟寒暄几句，然后花 30 ～ 50 分钟做 coding 和 design 相关的问题，其余的时候留在回答问题。

面试不是“考试”，而是日常工作的缩影

面试的时候遇到困难卡住了怎么办？要记住面试不是考试，而是实际工作中的浓缩。遇到问题卡住了，可以自己思考解决，也可以寻求帮助。在面试的时候通常面试者会乐意给你帮助。

因此，面试的时候一定要把想法说出来，而不要闷不作声思考或者上来就噼里啪啦写代码，即便胸有成竹，也可以先简单说明一下自己对题目的理解，解决问题的思路然后才开始写代码；如果在答题的时候遇到了困难，可以告诉面试者你在什么地方卡住了，遇到什么问题，一般面试者都会给你帮助。想象这就是在正常工作的时候——你和同事合作解决一个问题，作为一个团队，你一定应该告诉你的同事你准备怎么做，遇到了问题可以问同事，可以和他讨论请他帮忙。

几乎所有面试者的心态其实是希望你能通过，而不是给你制造障碍。这其实是公司面试的一个“秘密”，对每个来面试的人，我都巴不得你能顺利通过，因此面试者的心态完全不是给你制造阻碍，相反是衷心希望你能表现出色通过面试。如果你能顺利通过，我们可以快速把空缺职位填补上，就不需要再花时间面试更多的人。尤其某些职位可能面试了很多人，花了很久的时间精力，这种心愿更为真切。

ArcBlock 内部如何评审面试？

对于高科技公司，人才是公司最重要的资产。而招了不合适的人将是公司巨大的损失，有时候损失是难以估量的，因此严格把好招聘关是非常重要的。

我们的招聘面试评价只有 Yes 或 No 两个选择。可以是 Strong hire（强烈建议雇用），或者 Strong No hire（潜力建议不雇用，只要有 Strong no hire，那么结论肯定是 no hire）。我们不允许出现模棱两可的判断，或者说自己不确定要其他人判断。

我在微软第一次参加招聘的培训有一个原则给我深刻的印象：Whenever in doubt，No hire，这个原则在 ArcBlock 也继承下来了，因此只要一个面试觉得不是很确定，或者某些地方感觉不对劲，那么就是 No hire。

这么严格的要求，是不是因为着我们只找“完美无暇”的人？其实并不是，事实上，我们会 hire 面试中明显暴露出了问题的人——人无完人，我们不会因为你面试的时候偶尔一条算法没写对就 no hire，很多时候这是可以理解的。但例如有面试者表现出非常强的沟通能力，过去有很多 blog 和文章也体现出非常好的理解水平，然而在我们数次的编码和算法上却表现得与其能力不匹配，那么这时候我们就会有疑虑——一旦有这样的疑虑，通常我们都选择 No hire。

没有被录用，不表示您的能力有任何问题
求职没有被录用，不表示求职者有任何能力的问题，仅仅是说明和这个工作岗位或者公司团队不匹配。我建议所有没有通过我们或者其他公司面试的同学，无需纠结，也不存在任何的信心打击，直接转移注意力、集中精力去寻找其他更适合自己的职位。

对于不喜欢我们的招聘流程，尤其对我们 Coding Test 方式有意见的，对我们每轮面试都要写很简单的代码感觉和自己的丰富经验不匹配的同学，这恰恰说明我们的工作方式和风格与你不相匹配，大可及时退出而节省大家的时间。不认同我们这些做法，并不是说你的看法有任何错误，只是表明大家行事风格不一致而已。

ArcBlock 的招聘流程是实用主义和经验主义的产物，是我们在过去的工作中积累总结的自认为的最佳实践，也会在未来实践中不断调整迭代。我们的目标是寻找到双方都觉得合适的人才共同发展。

如果你刚刚加入 ArcBlock，估计你已经历过了上述过程，恭喜你！未来你在 ArcBlock 团队将还会有很多机会再次经历这个过程，只不过处于另一个位置：招聘者。

说明： 这篇关于 ArcBlock 招聘和面试培训的文章既面向社会公众也面向我们团队内部。在新的 IT 时代，未来我们将在内部团队建设中逐渐采用公开透明策略，培训内容和课程不再有内外之别，同时也会逐步整理公开过去的内部培训的资料和视频。