数据分析了数千个程序猿求职案例，解读程序员面试秘籍

来源：微信公众号（ID：BigDataDigest）作者：Aline Lerner
编译：大力，高宁
凡莉，赵倩南，宁云州

这篇文章将带你重回那些疯狂又让心惊胆战的编程者求职面试现场。

也许你大学或者研究生刚毕业，正面临第一次求职面试，又或者你是个软件工程老鸟，已经有些年没有想过求职面试这种事了。

不管你属于哪种情况，求职面试的第一步都是在网上浏览一堆面试指南（尤其是涉及到你感兴趣的公司），并和好朋友们聊聊他们的面试经验（不仅包括作为求职者还包括作为面试官的经验）。

在这第一步“探究性”阶段所学到的有关面试流程的信息，很可能会指导你如何开展下一步的准备工作。

以下干货将告诉你准备这类面试的正确打开方式，敲黑板！

大多数面试指南都是从一家公司的角度出发的。A公司可能非常注重程序开发效率，而B公司可能更看重解决高层次问题的能力。如果已你经把目标瞄准了A公司，那就得好好研究他们的看重什么了。

人在不经意的时候会心口不一。在写面试指南的时候，公司可能会说他们不在乎编程语言，或者会希望你试着还原你的思考过程，即使说得可能不太对也没关系。但是事实他们的标准可能并不是他们说的那样。也不是说那些技术公司是穷凶极恶的骗子，要恶意误导求职者。有时，人们在毫无意识的情况下可能会产生难以察觉的偏见。

很多你从朋友或熟人那里听来的“秘籍”可能完全不属实。很多人认为面试很短代表没戏了。同样，当他们认为“我和那个面试官很聊得来，我肯定会进入下一轮面试”的时候，他们会觉得面试时间很长。之前我们已经说到了人们经常会误判自己的面试表现。这一次，我们就来直观地看看像面试时间长短这种指标是否真的能说明什么吧。

我们公司（interviewing.io）独家推出了一种基于数据的方法来评估技术型面试和面试结果之间的关系。我们有一个平台可以供人们在上面匿名地练习技术型面试。不出意外的话，人们可以解锁并随时匿名练习像优步、Lyft（优步在北美的主要竞争对手）和Twitch（北美的一个游戏直播平台）这些顶级公司的技术型面试。

更厉害的是，面试模拟训练和真正的面试都能在我们的interviewing.io的生态中进行。所以，我们可以对收集到的大量面试数据进行分析，从而更好地理解技术型面试，如面试中哪些信号是有效的哪些是无效的、以及面试中哪些方面可能真正对结果产生影响。

不论是真实或者模拟面试，每一场我们都会确保求职者和面试官在一个可协作的编程环境里，通过语音、文字和白板进行交流，期间穿插着技术型问答。

你很可能会遇到在后端软件工程师的电话面试里经常出现的那种技术问题。

我们收集了面试中出现的所有数据，包括语音记录的文字版本，求职者编写并运行的程序数据、元数据，以及求职者和面试官各自对这场面试和对对方及这场面试的反馈意见。

如果对此感兴趣的话，你可以看到下面求职者和面试官各自的反馈表 — 除了设置是/否这样单选问题，我们还设置了一些用1-4的梯度来衡量面试表现的问题。

除此外，我们还对求职者设置了一些附加题，但这些问题不对面试官开放，其中一个问题是：求职者以前是否见到过这些题。

给面试官的反馈表

求职者的反馈表

结果

注意，下面的结论都是基于观察数据，也就是说我们不能下很确切的定论…但我们还是想分享我们观察到的一些有意思情况，看完后相信你自己可以得出相应的结论。

以前见过同样的面试题——

“我们谈论的是训练！”Allen Iverson ( 阿伦·艾弗森前美国职业篮球运动员，司职后卫（双能卫）)

首先，众所周知，想要在面试中做的更好，最好的方法之一就是进行面试训练。网上有非常丰富的渠道和资源可以帮助你训练，我们就是其中之一。面试训练最主要的一个好处就是它可以帮你减少你碰上从来没见过问题的可能性。如果你事先练习过一两遍，平衡二叉搜索树问题会变得远没有那么可怕。

回顾我们收集的3000+的面试案例，对比以前见过面试题的求职者与没见过那些题的求职者的面试结果，得到以下结果。

标题：见过面试题的对面试结果影响

横轴：求职者是否见过面试题

纵轴：成功率

果不其然，见过面试题的求职者被面试官认可的可能性比没有见过的高出16.6%。这个区别在统计学上十分显著——这篇文章的所有误差线都是95%的置信区间内的情况（95%置信区间就是总体参数在这个范围的可能性大概是95%,或者说总体参数在这个范围,但其可信程度只有95%）。

你用什么语言编程很重要吗？

“不爱自己母语的人，无论是谁，卑贱堪比禽兽和臭鱼”——荷西·黎萨（菲律宾近代反抗西班牙统治的民族英雄）。你可能会以为用不同的编程语言会有更好的面试结果。例如，也许更易读的Python会助力你的面试。或者觉得特定语言能有简洁的方法处理数据结构，使普通的面试问题更简单。我们想用统计学的方法知道面试表现和使用不同的面试语言之间是否有足够大的区别。

为了研究，我们根据不同的面试语言将我们平台上的面试进行了分组，并剔除了面试使用次数低于五次的编程语言（这只排除了个别几个面试）。之后，我们得到了面试结果与使用的编程语言之间的变化函数。

分析结果如下表。任意非重叠的置信区间代表了统计学上很大的区别，显示了在不同的面试语言情况下，求职者有多大几率可以“通过”面试。

虽然我们没有对这些编程语言进行成对对比。总的来讲，以下数据显示，就求职者遇到不同语言的情况下的面试成功率之间，并没有明显的统计学上的区别。（我们的平台上列出了更多编程语言，但越小众的语言我们能收集到的数据就越少。例如，用Brainf***语言面试保证你百分之百成功，开个玩笑。）

面试时使用的编程语言与面试成功率之间的关系

纵轴：面试成功率

横轴：所使用的编程语言

我们观察到的一个最常见的问题是求职者会选择自己并不熟悉的编程语言，然后在一些很基本的问题上出错，例如，查询数组长度，迭代数组，实例化哈希表等等。

当求职者有意选择一个看起来很“高端”的编程语言，想要给面试官留下深刻印象的时候，都会让面试官感到很失望。相信我们，在每一次面试时，都请使用自己熟悉的语言尽情发挥，而不是去用你并不熟悉的“高端”语言炫技。

即使编程语言无关紧要……那如果我选择所面试公司使用的编程语言会有优势吗？

“上帝帮帮我，我是原住民”– Margaret Blaine注：暗指求职者使用的编程语言所面试的公司也在用，是想要让面试官认为自己已具备成为公司一员的能力。

普遍来说，面试时所使用的语言与面试表现之间似乎没有特别的关联。但是，大家可能还是会认为如果面试时使用对方公司习惯的编程语言会对面试结果产生一定的影响，比如Ruby Shop招聘时可能会说，“我们只招Ruby的开发人员，如果你在面试时使用的是Python，我们很可能不会录用你。”

另一方面，如果一个公司所有的代码都是用Python完成的，那么他们在面试时对于Python的要求会十分苛刻，因为他们对这门编程语言里里外外都很清楚。同时，他们也会在面试中评估对求职者的所有非Python相关的能力。

下面的图表与之前展示面试成功率的差异（根据面试官是否愿意雇佣求职者来衡量的）与在面试时使用不同编程语言之间的关系的图表类似（C++，Java，Python）。无论如何，这个图表也说明了面试表现与所面试公司是否使用某种语言之间并没有必然联系。

我们将分析范围限定在C++，Java和Python，因为我们可以基于这三种语言构建一个良好的面试组合，有些公司使用这三种语言，有些公司不用。调查的结果并不一致，当面试时使用的编程语言为Python或者C++时，所求职公司是否使用这种语言与面试成功率之间并没有统计学上显著差异。然而，当所求职公司是使用Java的，那么面试时使用Java更可能面试成功。（P=0.037）

为什么所求职公司使用Java对于面试成功率有正向影响，而使用Python和C++却没有呢？一个可能的原因是使用特定语言（如Java）的组织对于该编程语言的历史实施经验有较高的认可度。根据这些规则，如果面试官所在公司使用Java，那么他们在面试时更可能围绕Java自身已有的知识体系进行提问。

面试成功率与所使用的编程语言的相关性

纵轴：面试成功率

横轴：编程语言

图例：公司使用某种语言，公司不使用某种语言

你使用的编程语言和面试官对你的沟通能力的评价有什么关系呢？

熟练的掌握一种语言，就像是练习一种唤醒巫术一样。- Charles Baudelaire （夏尔·皮埃尔·波德莱尔，法国十九世纪最著名的现代派诗人，象征派诗歌先驱，代表作有《恶之花》）即使使用哪种语言对于面试表现没有大的影响（除了使用Java的公司），我们仍然很好奇选择不同的编程语言对于其他面试考察点而言，是否会有不同的结果。

例如，如果求职者选择的是可读性很强的编程语言，例如Python，面试官可能会对他的沟通能力有很高的期待。如果使用的是比较底层的语言，例如C++，那么他可能在技术能力方面会获得更高的分数。

此外，可读性很强的语言和底层语言可能影响这两项分数的相关性。（例如，使用C++的求职者所编写的代码的执行效率可能很高，但却不能清楚地解释他（她）在做什么）。下面的图表说明对于使用不同语言的求职者的技术能力和沟通能力的评估结果，二者间并没有显著性差异。

使用不同编程语言的人的沟通能力和编码能力的对比分析

横轴：编码能力

纵轴：沟通能力

图例：通过面试的百分比

此外，从图表中看来不论是使用什么语言，如果编码能力差的人，很可能沟通能力也很差。而编程能力很强沟通能力弱的人相对很少（反之亦然）。这在很大程度上（也很幸运地）揭穿了工程师都讲话语无伦次，语速很快，而且看起来很笨拙的谣言。

（我见过的最好的工程师不仅非常擅长将复杂的概念进行分解，并且能够讲解给非专业人士听。不是很懂为什么总会有那些关于工程师都具有社交恐惧，是语无伦次的技术宅这样的传言。）

面试时长

当你年轻的时候，面对灾难性差评、拒绝以及其他所有负面事务时，你能够很快满血复活。- Harold Prince我们都有过面试完后觉得自己表现不太好的经历。通常，这种不好的感觉源于我们给自己或听别人反复说的攻略的心理暗示。你可能会想，“为什么这次面试时间这么短，这是一个不好的信号……”或者，“这次面试我好像什么都没写，肯定会被淘汰了”。通过数据分析，我们想知道这些攻略对于求职者的面试表现是否有受用。

首先，我们来看面试时长。一个很短的面试是否意味着你的能力很弱所以面试官决定提前结束？或者是否是因为面试官这次只有比较短的时间进行面试，或者他（她）是否已经在很短的时间内就认定你是一个优秀的求职者？下图显示了成功通过面试和面试失败的求职者的面试时长（以分钟计时）的分布情况。

一眼就可以看出，顺利通过者和面试失败者的面试时长分布并没有很大不同。顺利通过者的平均面试时长是51分钟，面试失败者的平均面试时长是49.95分钟，这两个数据并没有显著的差异。

（对于本篇文章中的所有分布的对比，我们都将使用Fisher-Pitman排列检验法来对比分布的平均值的差异。）

标题：面试时长和面试结果是否相关

横轴：面试时长（分钟）

纵轴：面试数量

图例：面试官愿意雇佣、面试官不会雇佣

编写代码的长度

“言以简为贵” – 威廉莎士比亚（英国诗人、作家）很多人可能都经历过面试时僵住的情况。面试官问了一个你不太懂的问题，然后你问回他（她）“使用二分法查询什么？”，而且在整个面试中你可能一句代码都没有写。但你还是想灵机一动，展现出很好的问题解决能力，从而成功通过面试。为了评估这是否有效，我们分析了求职者最终提交的代码的字符长度。下图显示了面试成功者和面试失败者的字符长度的分布情况。快速地浏览下就可以看出这两种方式的不同，面试失败者最终所提交的代码长度会更短。有两种可能的情况与之相关，第一种，面试失败的求职者在一开始就只写了很少的代码；第二种，他们很可能在代码没有运行成功或者运行后没有返回预期结果时删除了大段的代码。

标题：代码的长度和面试结果是否相关

横轴：最终提交的代码长度（字符数）

纵轴：面试数量

图例：面试官愿意雇佣、面试官不会雇佣

成功的求职者最终提交代码的平均长度是2045个字符，而面试失败者最终提交的代码的平均长度是1760个字符，二者间有很大不同！这个结果在统计学上是有很大的差异的，也是我们意料之中的。

代码模块化

一个成熟的程序员的标志是，当意识自己花时间写的代码没有意义时，就将它抛弃。

除了求职者编写的代码长度，我们还调研了代码类型。

业内公认的观点是好程序员不会重复写同样的代码 — 他们写那些可以被重复利用很多次的模块化代码。

我们想知道这种行为是否也能在面试中获得青睐。于是，我们看了那些考察Python5的面试，并且在面试代码的最终版本里统计了出现的定义函数数量。

我们想要知道成功的求职者是否定义了更多的函数—尽管拥有更多的函数处理程序并不是代码模块化的定义，但据我了解，这已经很能说明问题了。

照例，这里也很难得出强因果关系的结论，因为求职者有可能会在面试官的提示下增加或者减少函数。但是，这次的观察还是很有趣的。

下面这张图展示了面试官表示会录用的求职者和不会被录用的求职者他们代码中的Python定义函数数量的分布。

粗看这张图就能发现定义函数的分布曲线在两类求职者之间是不同的。

成功的求职者倾向于定义更多的函数。

成功的求职者能编写更多的模块代码么？

纵轴：面试通过率

横轴：定义函数数量

在Python面试中成功的求职者平均定义了3.29个函数，而不成功的求职者只定义2.71个函数。这个差异在统计学上非常明显。也就是说，面试官们真的会像他们说的那样喜欢那些他们在指南中让你写的代码。

代码能否运行对面试结果影响大么？

快速前进，自然会搞砸一些事情。没有犯过什么错，就是说明你前进地不够迅速。—— Mark Zuckerberg （Facebook（脸书）的创始人兼首席执行官）最有效的调试工具就是认真地思考，再加上详尽精确的批注说明。—— Brian Kernighan (一位加拿大计算机科学家，同时它也是开发Unix的主要贡献者)

技术面试中常常听到的评论是，面试官并不关心你的代码是否能够运行—他们真正关心的是你解决问题的能力。

由于我们收集面试代码中无法检测它是否编译成功，我们想在数据中看看是否能够找到相应的证据。

那些没有出错的编译代码影响面试的成功和失败的概率吗？此外，如果求职者的代码中出现很多语法错误，他还会被雇佣吗？

为了解答这些疑问，在观察完数据后，我们把数据集限定在那些面试时间超过10分钟并且运行了5次以上代码的面试中。

这帮助我们把那些面试官不想让求职者运行代码和由于某些原因面试时长被缩短的面试过滤掉。

我们统计了运行过程中出现错误的代码比例。

当然，这个方法有一些局限性——比如，求职者的确给出了能够编译的代码，但给的答案不完全正确。也可能他们给出了正确的答案，却标准输出到了设备上。尽管如此，这样的分析还是能让我们有一个直观上的大致感受。

下图给出了这些数据的总结。X轴表示一场面试中代码正确运行的比例。比如，一场面试中运行了三次代码，其中有一次错误，它的正确率就会减少“30%-40%”。

Y轴表示在特定百分比区间里成功和失败求职者的各自的比例。大致浏览下面的图，我们可以看到，成功的求职者平均来看代码错误率更小。但这种差异在统计学上显著吗？