我们分析了成千上万的编程访谈。 这就是我们学到的东西。

by Aline Lerner

通过艾琳·勒纳(Aline Lerner)

我们分析了成千上万的编程访谈。 这就是我们学到的东西。 (We analyzed thousands of coding interviews. Here’s what we learned.)

Note: I wrote most of the words in this post, but the legendary Dave Holtz did the heavy lifting on the data side. See more of his work on his blog.

注意：我在这篇文章中写下了大部分的文字，但是传奇人物Dave Holtz在数据方面做了很多工作。 在博客上查看他的更多作品。

If you’re reading this post, there’s a decent chance that you’re about to re-enter the crazy and scary world of technical interviewing.

如果您正在阅读这篇文章，那么您很有可能会重新进入疯狂而可怕的技术面试世界。

Maybe you’re a college student or fresh grad who is going through the interviewing process for the first time. Maybe you’re an experienced software engineer who hasn’t even thought about interviews for a few years.

也许您是大学生或应届毕业生，这是您第一次参加面试过程。 也许您是一位经验丰富的软件工程师，几年来甚至都没有考虑过采访。

Either way, the first step in the interviewing process is usually to read a bunch of online interview guides (especially if they’re written by companies you’re interested in) and to chat with friends about their experiences with the interviewing process (both as an interviewer and interviewee).

无论哪种方式，面试过程的第一步通常是阅读一堆在线面试指南(特别是如果它们是由您感兴趣的公司撰写的)，并与朋友聊天以了解他们在面试过程中的经历(两者均为采访者和受访者)。

More likely than not, what you read and learn in this first, “exploratory” phase of the interview process will inform how you choose to prepare moving forward.

在面试过程的第一个“探索性”阶段中阅读和学习的内容很有可能会告诉您如何选择准备前进。

There are a few issues with this typical approach to interview preparation:

这种典型的面试准备方法存在一些问题：

• Most interview guides are written from the perspective of one company. While Company A may really value efficient code, Company B may place more of an emphasis on high-level problem-solving skills. Unless your heart is set on Company A, you probably don’t want to give too much weight to what they value.
  大多数面试指南都是从一家公司的角度撰写的。 虽然公司A可能确实重视高效的代码，但公司B可能会更加注重高级问题解决技能。 除非您对A公司坚定不移，否则您可能不想过多地重视他们的价值。
• People lie sometimes, even if they don’t mean to. In writing, companies may say they’re language agnostic, or that it’s worthwhile to explain your thought process, even if the answer isn’t quite right. However, it’s not clear if this is actually how they act! We’re not saying that tech companies are nefarious liars who are trying to mislead their applicant pool. We’re just saying that sometimes implicit biases sneak in and people aren’t even aware of them.
  人们有时会撒谎，即使他们不是故意的。 在写作中，公司可能会说他们与语言无关，或者即使答案不太正确，也有必要解释您的思维过程。 但是，目前尚不清楚这是否是他们的行为方式！ 我们并不是说科技公司是邪恶的骗子，试图误导其申请者。 我们只是说有时隐性偏见会潜入，人们甚至不知道它们。

• A lot of the “folk knowledge” that you hear from friends and acquaintances may not be based in fact at all. A lot of people assume that short interviews spell doom. Similarly, everyone can recall one long interview after which they’ve thought to themselves, “I really hit it off with that interviewer, I’ll definitely get passed onto the next stage.” In the past, we’ve seen that people are really bad at gauging how they did in interviews. This time, we wanted to look directly at indicators like interview length and see if those actually matter.

  实际上，您从朋友和熟人那里听到的许多“民间知识”可能根本没有根据。 许多人认为简短的采访会带来厄运。 同样，每个人都可以回想起一次漫长的面试，然后他们对自己进行了思考：“我真的和那个面试官达成了共识，我肯定会进入下一阶段。” 过去， 我们已经看到人们在评估采访中的表现时真的很糟糕 。 这次，我们希望直接查看诸如采访时长之类的指标，看看这些指标是否真正重要。

At my company, interviewing.io, we’re uniquely positioned to approach technical interviews and their outcomes in a data-driven way. We have a platform where people can practice technical interviewing anonymously. And if things go well, they can unlock the ability to interview anonymously, whenever they’d like, with top companies like Uber, Lyft, and Twitch.

在我的公司访谈(io)中 ，我们处于以数据驱动方式进行技术访谈及其结果的独特位置。 我们有一个平台，人们可以在该平台上匿名进行技术面试。 如果事情进展顺利，他们可以随时随地与Uber，Lyft和Twitch等顶级公司进行匿名面试。

The cool thing is that both practice interviews and real interviews with companies take place within the interviewing.io ecosystem. As a result, we’re able to collect quite a bit of interview data and analyze it to better understand technical interviews, the signal they carry, what works and what doesn’t, and which aspects of an interview might actually matter for the outcome.

最酷的是，在公司访谈系统中，对公司的实践访谈和真实访谈都发生在该访谈系统中。 结果，我们能够收集大量的访谈数据并进行分析，以更好地了解技术访谈，它们所传达的信号，有效和无效的内容以及访谈的哪些方面可能对结果产生实质性影响。

Each interview, whether it’s practice or real, starts with the interviewer and interviewee meeting in a collaborative coding environment with voice, text chat, and a whiteboard, at which point they jump right into a technical question.

每次访谈(无论是实践访谈还是实际访谈)都始于在语音，文本聊天和白板等协作编码环境中的访谈者和受访者会议，此刻他们直接跳入技术问题。

Interview questions tend to fall into the category of what you’d encounter in a phone screen for a back-end software engineering role.

面试问题通常属于您在电话屏幕上遇到的后端软件工程角色的类别。

During these interviews, we collect everything that happens, including audio transcripts, data and metadata describing the code that the interviewee wrote and tried to run, and detailed feedback from both the interviewer and interviewee about how they think the interview went and what they thought of each other.

在这些访谈中，我们收集发生的一切，包括音频记录，描述受访者编写并尝试运行的代码的数据和元数据，以及访谈者和受访者关于他们如何看待访谈以及他们如何思考的详细反馈彼此。

If you’re curious, you can see what the feedback forms for interviewers and interviewees look like below — in addition to one direct yes/no question, we also ask about a few different aspects of interview performance using a 1–4 scale.

如果您感到好奇，您可以看到下面的针对访调员和被访者的反馈表是什么—除了一个直接的是/否问题外，我们还使用1-4的量表询问访谈表现的几个不同方面。

We also ask interviewees some extra questions that we don’t share with their interviewers, and one of the things we ask is whether an interviewee has previously seen the question they just worked on.

我们还会向受访者询问一些我们不会与受访者分享的其他问题，而我们要问的问题之一是受访者以前是否曾见过他们刚刚处理过的问题。

结果 (The results)

Before getting into the thick of it, it’s worth noting that the conclusions below are based on observational data, which means we can’t make strong causal claims… but we can still share surprising relationships we’ve observed and explain what we found so you can draw your own conclusions.

在深入探讨之前，值得注意的是，以下结论是基于观察数据的，这意味着我们无法做出有力的因果主张……但我们仍然可以分享我们观察到的令人惊讶的关系，并解释发现的事实，以便您可以得出自己的结论。

之前看过面试问题 (Having seen the interview question before)

“We’re talking about practice!” -Allen Iverson

“我们正在谈论练习！” -艾弗森(Allen Iverson)

First thing’s first. It doesn’t take a rocket scientist to suggest that one of the best ways to do better in interviews is to… practice interviewing. There are a number of resources out there to help you practice, ours among them. One of the main benefits of working through practice problems is that you reduce the likelihood of being asked to solve something you’ve never seen before. Balancing that binary search tree will be much less intimidating if you’ve already done it once or twice.

首先是第一。 不需要火箭科学家建议在面试中做得更好的最好方法之一就是……练习面试。 有很多资源可以帮助您练习，其中包括我们的资源。 解决实践问题的主要好处之一是，您可以减少被要求解决从未见过的问题的可能性。 如果您已经完成了一两次，那么平衡二进制搜索树就不会那么吓人了。

We looked at a sample of ~3000 interviews and compared the outcome to whether the interviewee had seen the interview question before. You can see the results in the plot below.

我们查看了约3000个访谈的样本，并将结果与​​受访者之前是否看过采访问题进行了比较。 您可以在下面的图中查看结果。

Unsurprisingly, interviewees who had seen the question were 16.6% more likely to be considered hirable by their interviewer. This difference is statistically significant — all error bars in this post represent a 95% confidence interval.

毫不奇怪，已经看到问题的受访者被访调员认为可以雇用的可能性增加了16.6％。 这种差异在统计上非常显着-这篇文章中的所有误差线都代表95％的置信区间。

使用哪种语言有关系吗？ (Does it matter what language you code in?)

“Whoever does not love the language of his birth is lower than a beast and a foul smelling fish.” — Jose Rizal

“谁不喜欢他的出生语言，谁都比野兽和闻到鱼腥味的人低。” — Jose Rizal

You might imagine that different languages lead to better interviews. For instance, maybe the readability of Python gives you a leg up in interviews. Or perhaps the fact that certain languages handle data structures in a particularly clean way makes common interview questions easier. We wanted to see whether or not there were statistically significant differences in interview performance across different interview languages.

您可能会想象，不同的语言会带来更好的面试机会。 例如，也许Python的可读性使您在采访中站出来了。 也许某些语言以特别干净的方式处理数据结构的事实使常见的面试问题变得更加容易。 我们想了解不同面试语言的面试表现在统计上是否存在显着差异。

To investigate, we grouped interviews on our platform by interview language and filtered out any languages that were used in fewer than 5 interviews (this only threw out a handful of interviews). After doing this, we were able to look at interview outcome and how it varied as a function of interview language.

为了进行调查，我们在平台上通过访谈语言对访谈进行了分组，并过滤​​了少于5次访谈中使用的所有语言(这仅剔除了少数访谈)。 完成此操作后，我们可以查看面试结果以及其随面试语言的变化。

The results of that analysis are in the chart below. Any non-overlapping confidence intervals represent a statistically significant difference in how likely an interviewee is to ‘pass’ an interview, as a function of interview language.

该分析的结果在下表中。 任何不重叠的置信区间都代表了根据访问语言的不同，被访者“通过”访问的可能性在统计学上的显着差异。

Although we don’t do a pairwise comparison for every possible pair of languages, the data below suggest that generally speaking, there aren’t statistically significant differences between the success rate when interviews are conducted in different languages. (There were more languages than these on our platform, but the more obscure the language, the less data points we have. For instance, all interviews in Brainf*** were clearly successful. Kidding.)

尽管我们并未针对每种可能的语言对进行成对比较，但以下数据表明，一般而言， 使用不同语言进行的面试成功率之间在统计学上没有显着差异。 (在我们的平台上，有比这些语言更多的语言，但是语言越晦涩，我们得到的数据点就越少。例如， Brainf ***中的所有访谈显然都很成功。开玩笑。)

That said, one of the most common mistakes we’ve observed qualitatively is people choosing languages they’re not comfortable in and then messing up basic stuff like array length lookup, iterating over an array, instantiating a hash table, and so on.

也就是说，我们从质量上观察到的最常见错误之一是，人们选择了自己不熟悉的语言，然后弄乱了诸如数组长度查找，对数组进行迭代，实例化哈希表之类的基本内容。

This is especially mortifying when interviewees purposely pick a fancy-sounding language to impress their interviewer. Trust us, wielding your language of choice comfortably beats out showing off in a fancy-sounding language you don’t know well, every time.

当受访者故意选择一种听起来听起来很花哨的语言来打动他们的采访者时，这尤其使人沮丧。 相信我们，挥舞着您选择的语言，每次都会用您不太熟悉的花哨的语言来表现出来。

即使语言无关紧要……使用公司选择的语言进行编码是否有利？ (Even if language doesn’t matter… is it advantageous to code in the company’s language of choice?)

“God help me, I’ve gone native.” — Margaret Blaine

“上帝帮助我，我已经成为本地人。” —玛格丽特·布莱恩

It’s all well and good that, in general, interview language doesn’t seem particularly correlated with performance. However, you might imagine that there could be an effect depending on the language that a given company uses. You could imagine a Ruby shop saying “we only hire Ruby developers, if you interview in Python we’re less likely to hire you.”

总的来说，面试语言似乎与表现没有特别的关系，这一切都很好。 但是，您可能会想到，根据给定公司使用的语言，可能会产生影响。 您可以想象一个Ruby商店说：“我们只雇用Ruby开发人员，如果您使用Python进行面试，我们不太可能雇用您。”

On the flip side, you could imagine that a company that writes all of their code in Python is going to be much more critical of an interviewee in Python — they know the ins and outs of the language, and might judge the candidate for doing all sorts of “non-pythonic” things during their interview.

另一方面，您可以想象一家用Python编写所有代码的公司对使用Python的受访者的批评要严格得多，他们知道这种语言的来龙去脉，并可能会判断应聘者是否会做所有事情。在他们的采访中出现了一些“非Python性”的事情。

The chart below is similar to the chart which showed differences in interview success rate (as measured by interviewers being willing to hire the interviewee) for C++, Java, and Python. However, this chart also breaks out performance by whether or not the interview language is in the company’s stack.

下图类似于显示C ++，Java和Python的面试成功率(由面试官愿意聘用被访者衡量)的差异。 但是，此图表还根据面试语言是否在公司堆栈中来区分绩效。

We restrict this analysis to C++, Java and Python because these are the three languages where we had a good mixture of interviews where the company did and did not use that language. The results here are mixed. When the interview language is Python or C++, there’s no statistically significant difference between the success rates for interviews where the interview language is or is not a language in the company’s stack. However, interviewers who interviewed in Java were more likely to succeed when interviewing with a Java shop (p=0.037).

我们将这种分析限制在C ++，Java和Python，因为这是我们使用和不使用该语言的三种语言，我们进行了很好的混合采访。 这里的结果好坏参半。 当面试语言是Python或C ++时，无论面试语言是否是公司堆栈中的一种语言，面试的成功率在统计上都没有显着差异。 但是，使用Java进行访问的访问者在访问Java商店时更有可能获得成功 (p = 0.037)。

So, why is it that coding in the company’s language seems to be helpful when it’s Java, but not when it’s Python or C++? One possible explanation is that the communities that exist around certain programming languages (such as Java) place a higher premium on previous experience with the language. Along these lines, it’s also possible that interviewers from companies that use Java are more likely to ask questions that favor those with a pre-existing knowledge of Java’s idiosyncrasies.

那么，为什么在公司语言中使用Java语言编写代码似乎有帮助，而在Python或C ++中却没有帮助呢？ 一种可能的解释是，围绕某些编程语言(例如Java)存在的社区比以前使用该语言的经验更高。 沿着这些思路，使用Java的公司的访问者也可能会提出一些问题，以青睐那些已经具备Java特质知识的人。

您使用哪种语言编程以及您被认为是一个良好的沟通者之间的关系如何？ (What about the relationship between what language you program in and how good of a communicator you’re perceived to be?)

“To handle a language skillfully is to practice a kind of evocative sorcery.” — Charles Baudelaire

“熟练地使用一种语言就是一种令人回味的魔术。” —查尔斯·鲍德莱尔

Even if language choice doesn’t matter that much for overall performance (Java-wielding companies notwithstanding), we were curious whether different language choices led to different outcomes in other interview dimensions.

即使语言选择对整体绩效没有多大的影响(尽管使用Java的公司也是如此)，但我们很好奇，不同的语言选择是否会导致其他面试维度的不同结果。

For instance, an extremely readable language, like Python, may lead to interview candidates who are assessed to have communicated better. On the other hand, a low-level language like C++ might lead to higher scores for technical ability.

例如，一种极易读的语言(如Python)可能会导致面试候选人被评估为沟通能力更好。 另一方面，像C ++这样的低级语言可能会导致更高的技术能力分数。

Furthermore, very readable or low-level languages might lead to correlations between these two scores (for instance, maybe they’re a C++ interview candidate who can’t explain at all what he or she is doing but who writes very efficient code). The chart below suggests that there isn’t really any observable difference between how candidates’ technical and communication abilities are perceived, across a variety of programming languages.

此外，可读性强或低级的语言可能会导致这两个分数之间的相关性(例如，他们可能是C ++面试候选人，他们根本无法解释自己在做什么，但编写的代码非常有效)。 下表表明，在各种编程语言中，如何看待候选人的技术和沟通能力之间确实没有任何可观察的差异。

Furthermore, no matter what, poor technical ability seems highly correlated with poor communication ability — regardless of language, it’s relatively rare for candidates to perform well technically but not effectively communicate what they’re doing (or vice versa), largely (and fortunately) debunking the myth of the incoherent, fast-talking, awkward engineer.

此外，无论如何，技术能力差似乎与沟通能力差密切相关-不管使用哪种语言，候选人在技术上表现良好但不能有效地传达他们正在做的事情(反之亦然)的情况相对较少(主要是(幸运的是))揭露不连贯，说话Swift，笨拙的工程师的神话。

(The best engineers I’ve met have also been legendarily good at breaking down complex concepts and explaining them to laypeople. Why the infuriating myth of the socially awkward, incoherent tech nerd continues to exist, I have absolutely no idea.)

(我遇到的最好的工程师在传说中也擅长分解复杂的概念，并向外行人解释它们。为什么社会上笨拙，不连贯的技术书呆子的令人毛骨悚然的神话继续存在，我绝对不知道。)

面试时间 (Interview duration)

“It’s fine when you careen off disasters and terrifyingly bad reviews and rejection and all that stuff when you’re young; your resilience is just terrific.” — Harold Prince

“当您年轻时关心灾难，可怕的糟糕评论和拒绝以及所有这些东西，这很好。 您的应变能力真棒。” —哈罗德·普林斯

We’ve all had the experience of leaving an interview and just feeling like it went poorly. Often, that feeling of certain underperformance is motivated by rules of thumb that we’ve either come up with ourselves or heard repeated over and over again. You might find yourself thinking, “the interview didn’t last long? That’s probably a bad sign… ” or “I barely wrote anything in that interview! I’m definitely not going to pass.” Using our data, we wanted to see whether these rules of thumb for evaluating your interview performance had any merit.

我们都有离开面试的经验，只是觉得面试不好。 通常，某些性能不佳的感觉是由经验法则引起的，这些经验法则是我们自己提出来或反复听过。 您可能会发现自己在想：“采访持续了很长时间吗？ 这可能是一个不好的信号……”或“在那次采访中我几乎什么都没写！ 我绝对不会过去。” 使用我们的数据，我们想看看这些评估您的面试表现的经验法则是否有任何优点。

First, we looked at the length of the interview. Does a shorter interviewer mean you were such a train wreck that the interviewer just had to stop the interview early? Or was it maybe the case that the interviewer had less time than normal, or had seen in just a short amount of time that you were an awesome candidate? The plot below shows the distributions of interview length (measured in minutes) for both successful and unsuccessful candidates.

首先，我们看了采访的时间。 较短的面试官是否意味着您是如此残酷，以至于面试官只能提早停止面试？ 还是面试官的时间比平常少，或者只是在很短的时间内就看到你是一个很棒的候选人？ 下图显示了成功和不成功候选人的面试时长分布(以分钟为单位)。

A quick look at this chart suggests that there is no difference in the distribution of interview lengths between interviews that go well and interviews that don’t — the average length of interviews where the interviewer wanted to hire the candidate was 51.00 minutes, whereas the average length of interviews where the interviewer did not was 49.95 minutes. This difference is not statistically significant.

快速浏览一下此图，表明进行得不错的面试与不愉快的面试之间的面试时长分布没有差异-面试官想聘用候选人的平均面试时长为51.00分钟，而平均水平采访者未参加的采访时长为49.95分钟。 这种差异在统计上并不显着 。

(For every comparison of distributions in this post, we use both a Fisher-Pitman permutation test to compare the difference in the means of the distributions.)

(对于本文中的分布的每次比较，我们都使用Fisher-Pitman排列检验来比较分布均值的差异。)

编写的代码量 (Amount of code written)

“Brevity is the soul of wit.” -William Shakespeare

“简洁是机智的灵魂。” -威廉·莎士比亚

You may have experienced an interview where you were totally stumped. The interviewer asks you a question you barely understand, you repeat back to him or her “binary search what?”, and you basically write no code during your interview. You might hope that you could still pass an interview like this through sheer wit, charm, and high-level problem-solving skills. In order to assess whether or not this was true, we looked at the final character length of code written by the interviewee. The plot below shows the distributions of character length for both successful and unsuccessful. A quick look at this chart suggests that there is a difference between the two — interviews that don’t go well tend to have less code. There are two phenomena that may contribute to this. First, unsuccessful interviewers may write less code to begin with. Additionally, they may be more prone to delete large swathes of code they’ve written that either don’t run or don’t return the expected result.

您可能经历过一次面试，而您完全被困住了。 面试官问您一个您几乎不理解的问题，您重复给他或她“二进制搜索什么？”，并且在面试过程中您基本上没有编写任何代码。 您可能希望您仍然可以凭借机智，魅力和高水平的解决问题的能力通过这样的面试。 为了评估这是否成立，我们查看了受访者编写的代码的最终字符长度。 下图显示了成功和失败的字符长度分布。 快速浏览一下该图表，可以发现两者之间存在差异-面试不好的访谈往往代码更少。 有两种现象可能导致此现象。 首先，不成功的面试官一开始可能编写更少的代码。 此外，他们可能更倾向于删除他们编写的，无法运行或未返回预期结果的大量代码。

On average, successful interviews had final interview code that was on average 2045 characters long, whereas unsuccessful ones were, on average, 1760 characters long. That’s a big difference! This finding is statistically significant and probably not very surprising.

平均而言，成功的面试的最终面试代码平均长度为2045个字符，而失败的面试代码的平均长度为1760个字符。 那是很大的不同！ 这一发现具有统计意义，可能并不十分令人惊讶。

代码模块化 (Code modularity)

“The mark of a mature programmer is willingness to throw out code you spent time on when you realize it’s pointless.” — Bram Cohen

“成熟的程序员的标志是愿意在发现毫无意义的时候扔掉您花费的时间编写的代码。” —布拉姆·科恩

In addition to just look at how much code you write, we can also think about the type of code you write. Conventional wisdom suggests that good programmers don’t recycle code — they write modular code that can be reused over and over again. We wanted to know if that type of behavior was actually rewarded during the interview process. In order to do so, we looked at interviews conducted in Python5 and counted how many function definitions appeared in the final version of the interview. We wanted to know if successful interviewees defined more functions — while having more function handlers is not the definition of modularity, in our experience, it’s a pretty strong signal of it. As always, it’s impossible to make strong causal claims about this — it might be the case that certain interviewers (who are more or less lenient) ask interview questions that lend themselves to more or fewer functions. Nonetheless, it is an interesting trend to investigate!

除了在你有多少代码编写只是看，我们还可以想想你写的代码的类型。 传统观点认为，优秀的程序员不要回收代码，而是编写可以重复使用的模块化代码。 我们想知道在面试过程中这种行为是否真正得到了回报。 为了做到这一点，我们查看了用Python 5进行的采访，并计算了在采访的最终版本中出现了多少个函数定义。 我们想知道成功的受访者是否定义了更多的功能-虽然拥有更多的函数处理程序并不是模块化的定义，但根据我们的经验，这是一个很强烈的信号。 与往常一样，不可能对此提出强有力的因果主张-某些情况下(某些或多或少宽容的采访者)可能会问一些使他们或多或少发挥作用的采访问题。 尽管如此，这是一个有趣的研究趋势！

The plot below shows the distribution of the number of Python functions defined for both candidates who the interviewer said they would hire and candidates who the interviewer said they would not hire. A quick look at this chart suggests that there is a difference in the distribution of function definitions between interviews that go well and interviews that don’t. Successful interviewees seem to define more functions.

下图显示了针对面试官表示愿意雇用的候选人和面试官表示不愿意雇用的候选人定义的Python函数数量的分布。 就让我们来看看这个图表明，有是顺利的采访，不采访之间的函数定义分布的差异。 成功的受访者似乎定义了更多功能。

On average, successful candidates interviewing in Python define 3.29 functions, whereas unsuccessful candidates define 2.71 functions. This finding is statistically significant. The upshot here is that interviewers really do reward the kind of code they say they want you to write.

平均而言，使用Python进行面试的成功候选人定义了3.29个功能，而失败的候选人定义了2.71个功能。 这一发现具有统计意义。 结果是，面试官确实确实奖励他们说要您编写的那种代码。

代码运行是否重要？ (Does it matter if your code runs?)

“Move fast and break things. Unless you are breaking stuff, you are not moving fast enough.” — Mark Zuckerberg

“快速行动，打破常规。 除非您破坏东西，否则您的移动速度不够快。” —马克·扎克伯格

“The most effective debugging tool is still careful thought, coupled with judiciously placed print statements.” — Brian Kernighan

“最有效的调试工具仍需慎重考虑，并明智地放置打印语句。” —布赖恩·克尼根( Brian Kernighan)

A common refrain in technical interviews is that interviewers don’t actually care if your code runs — what they care about is problem-solving skills. Since we collect data on the code interviewees run and whether or not that code compiles, we wanted to see if there was evidence for this in our data. Is there any difference between the percentage of code that compiles error-free in successful interviews versus unsuccessful interviews? Furthermore, can interviewees actually still get hired, even if they make tons of syntax errors?

技术面试中的一个常见限制是，面试官实际上并不在乎您的代码是否运行-他们所关心的是解决问题的技能。 由于我们收集有关受访者运行的代码以及该代码是否编译的数据，因此我们想查看我们的数据中是否有证据。 在成功的采访中和没有成功的采访中，无错误编译代码的百分比之间是否有区别？ 此外，即使被访者犯了很多语法错误，他们实际上还能被雇用吗？

In order to get at this question, we looked at the data. We restricted our dataset to interviews longer than 10 minutes with more than 5 unique instances of code being executed. This helped filter out interviews where interviewers didn’t actually want the interviewee to run code, or where the interview was cut short for some reason. We then measured the percent of code runs that resulted in errors.5 Of course, there are some limitations to this approach — for instance, candidates could execute code that does compile but gives a slightly incorrect answer. They could also get the right answer and write it to stderr! Nonetheless, this should give us a directional sense of whether or not there’s a difference.

为了解决这个问题，我们查看了数据。 我们将数据集的访问时间限制在10分钟以上，并且要执行5个以上的唯一代码实例。 这有助于过滤掉访谈者实际上不希望受访者运行代码的地方，或者由于某种原因而缩短了访谈的时间。 然后，我们测量了导致错误的代码运行百分比。 5当然，这种方法有一些局限性-例如，候选人可以执行确实可以编译但给出了稍微错误答案的代码。 他们还可以获得正确的答案并将其写入stderr！ 尽管如此，这应该使我们对是否存在差异有方向性的认识。

The chart below gives a summary of this data. The x-axis shows the percentage of code executions that were error-free in a given interview. So an interview with 3 code executions and 1 error message would count towards the “30%-40%” bucket. The y-axis indicates the percentage of all interviews that fall in that bucket, for both successful and unsuccessful interviews. Just eyeballing the chart below, one gets the sense that on average, successful candidates run more code that goes off without an error. But is this difference statistically significant?

下表总结了这些数据。 x轴显示在给定采访中无错误的代码执行百分比。 因此，对3条代码执行和1条错误消息的采访将计入“ 30％-40％”存储桶。 y轴表示成功和不成功的采访中属于该类别的所有采访的百分比。 仅仅关注下面的图表，就可以感觉到，成功的候选人平均而言会运行更多的代码而不会出错。 但是，这种差异具有统计意义吗？

On average, successful candidates’ code ran successfully (didn’t result in errors) 64% of the time, whereas unsuccessful candidates’ attempts to compile code ran successfully 60% of the time, and this difference was indeed significant. Again, while we can’t make any causal claims, the main takeaway is that successful candidates do usually write code that runs better, despite what interviewers may tell you at the outset of an interview.

平均而言，成功的候选人的代码成功运行(没有导致错误)的时间为64％，而失败的候选人的代码编译尝试成功地运行的时间为60％，而这种差异确实非常明显。 同样，尽管我们不能提出任何因果关系的主张，但主要的结论是，尽管面试官在面试开始时会告诉您什么，但是成功的候选人通常会编写出性能更好的代码。

在编写代码之前，您应该等待并收集想法吗？ (Should you wait and gather your thoughts before writing code?)

“Never forget the power of silence, that massively disconcerting pause which goes on and on and may at last induce an opponent to babble and backtrack nervously.” — Lance Morrow

“永远不要忘记沉默的力量，那令人不安的停顿不断地发生，并最终可能导致对手紧张地ba咽并退缩。” —兰斯·莫罗

We were also curious whether or not successful interviewees tended to take their time in the interview. Interview questions are often complex! After being presented with a question, there might be some benefit to taking a step back and coming up with a plan, rather than jumping right into things. In order to get a sense of whether or not this was true, we measured how far into a given interview candidates first executed code. Below is a histogram showing how far into interviews both successful and unsuccessful interviewees first ran code. Looking quickly at the histogram, you can tell that successful candidates do in fact wait a bit longer to start running code, although the magnitude of the effect isn’t huge.

我们也很好奇，成功的受访者是否倾向于抽时间参加采访。 面试问题通常很复杂！ 提出问题后，退后一步并提出一个计划可能会有些好处，而不是立即着手进行。 为了了解这是否成立，我们测量了候选人首次执行代码到给定面试中的距离。 以下是一个直方图，显示成功和失败的受访者首次运行代码对访谈的距离。 快速查看直方图，您可以看出，成功的候选人实际上等待了更长的时间才能开始运行代码，尽管影响的程度并不大。

More specifically, on average, candidates with successful interviews first run code 27% of the way through the interview, whereas candidates with unsuccessful interviews first run code 23.9% of the way into the interview, and this difference is significant. Of course, there are alternate explanations for what’s happening here. For instance, perhaps successful candidates are better at taking the time to sweet-talk their interviewer. Furthermore, the usual caveat that we can’t make causal claims applies — if you just sit in an interview for an extra 5 minutes in complete silence, it won’t help your chances. Nonetheless, there does seem to be a difference between the two cohorts.

更具体地说， 平均而言，成功进行面试的候选人在面试过程中会先执行代码的27％，而未成功进行面试的候选人会在面试过程中先执行代码的23.9％，这种差异是很明显的 。 当然，对于这里发生的事情，还有其他解释。 例如，也许成功的候选人更擅长花时间与面试官交谈。 此外，我们不能提出因果关系声明的通常警告是适用的-如果您在完全沉默的情况下仅在访谈中多坐了5分钟，那将无济于事。 但是，这两个队列之间似乎确实存在差异。

结论 (Conclusions)

All in all, this post was our first attempt to understand what does and does not typically lead to an interviewer saying “you know what, I’d really like to hire this person.” Because all of our data are observational, its hard to make causal claims about what we see.

总而言之，这篇文章是我们第一次尝试了解做什么和不做什么，通常会导致面试官说：“你知道吗，我真的很想雇用这个人。” 由于我们所有的数据都是观察性的，因此很难对我们所看到的内容进行因果断言。

While successful interviewees may exhibit certain behaviors, adopting those behaviors doesn’t guarantee success. Nonetheless, it does allow us to support (or call BS on) a lot of the advice you’ll read on the internet about how to be a successful interviewee.

尽管成功的受访者可能表现出某些行为，但采用这些行为并不能保证成功。 但是，它确实使我们能够支持(或致电BS)您将在互联网上阅读的许多关于如何成为成功的受访者的建议。

That said, there is much still to be done. This was a first, quantitative pass over our data (which is, in many ways, a treasure trove of interview secrets), but we’re excited to do a deeper, qualitative dive and actually start to categorize different questions to see which carry the most signal as well as really get our head around 2nd order behaviors that you can’t measure easily by running a regex over a code sample or measuring how long an interview took.

也就是说，还有许多工作要做。 这是对我们数据的第一次定量传递(在许多方面，这都是采访秘密的宝库)，但我们很高兴进行更深入，定性的考察，实际上开始对不同的问题进行分类，以了解哪些问题带有大多数信号以及真正引起我们注意的二阶行为，您都无法通过在代码样本上运行正则表达式或衡量采访花费了多长时间来轻松衡量。

If you want to help us with this and are excited to listen to a bunch of technical interviews, drop me a line!

如果您想在此方面为我们提供帮助，并且很高兴听一堆技术访谈，请给我留言 ！

Want to become awesome at technical interviews and land your next job in the process? Join interviewing.io!

想要在技术面试中变得很棒，并在此过程中找到下一份工作吗？ 参加访谈吧！

翻译自: https://www.freecodecamp.org/news/we-analyzed-thousands-of-coding-interviews-heres-what-we-learned-99384b1fda50/