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/