by Aline Lerner

通過艾琳·勒納(Aline Lerner)

我們分析了成千上萬的編程訪談。 這就是我們學(xué)到的東西。 (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在數(shù)據(jù)方面做了很多工作。 在博客上查看他的更多作品。

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.

如果您正在閱讀這篇文章，那么您很有可能會(huì)重新進(jìn)入瘋狂而可怕的技術(shù)面試世界。

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.

也許您是大學(xué)生或應(yīng)屆畢業(yè)生，這是您第一次參加面試過程。 也許您是一位經(jīng)驗(yàn)豐富的軟件工程師，幾年來甚至都沒有考慮過采訪。

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).

無論哪種方式，面試過程的第一步通常是閱讀一堆在線面試指南(特別是如果它們是由您感興趣的公司撰寫的)，并與朋友聊天以了解他們?cè)诿嬖囘^程中的經(jīng)歷(兩者均為采訪者和受訪者)。

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.

在面試過程的第一個(gè)“探索性”階段中閱讀和學(xué)習(xí)的內(nèi)容很有可能會(huì)告訴您如何選擇準(zhǔn)備前進(jìn)。

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

這種典型的面試準(zhǔn)備方法存在一些問題：

• 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.
  大多數(shù)面試指南都是從一家公司的角度撰寫的。 雖然公司A可能確實(shí)重視高效的代碼，但公司B可能會(huì)更加注重高級(jí)問題解決技能。 除非您對(duì)A公司堅(jiān)定不移，否則您可能不想過多地重視他們的價(jià)值。
• 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.
  人們有時(shí)會(huì)撒謊，即使他們不是故意的。 在寫作中，公司可能會(huì)說他們與語言無關(guān)，或者即使答案不太正確，也有必要解釋您的思維過程。 但是，目前尚不清楚這是否是他們的行為方式！ 我們并不是說科技公司是邪惡的騙子，試圖誤導(dǎo)其申請(qǐng)者。 我們只是說有時(shí)隱性偏見會(huì)潛入，人們甚至不知道它們。

• 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.

  實(shí)際上，您從朋友和熟人那里聽到的許多“民間知識(shí)”可能根本沒有根據(jù)。 許多人認(rèn)為簡短的采訪會(huì)帶來厄運(yùn)。 同樣，每個(gè)人都可以回想起一次漫長的面試，然后他們對(duì)自己進(jìn)行了思考：“我真的和那個(gè)面試官達(dá)成了共識(shí)，我肯定會(huì)進(jìn)入下一階段。” 過去， 我們已經(jīng)看到人們?cè)谠u(píng)估采訪中的表現(xiàn)時(shí)真的很糟糕 。 這次，我們希望直接查看諸如采訪時(shí)長之類的指標(biāo)，看看這些指標(biāo)是否真正重要。

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)中 ，我們處于以數(shù)據(jù)驅(qū)動(dòng)方式進(jìn)行技術(shù)訪談及其結(jié)果的獨(dú)特位置。 我們有一個(gè)平臺(tái)，人們可以在該平臺(tái)上匿名進(jìn)行技術(shù)面試。 如果事情進(jìn)展順利，他們可以隨時(shí)隨地與Uber，Lyft和Twitch等頂級(jí)公司進(jìn)行匿名面試。

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.

最酷的是，在公司訪談系統(tǒng)中，對(duì)公司的實(shí)踐訪談和真實(shí)訪談都發(fā)生在該訪談系統(tǒng)中。 結(jié)果，我們能夠收集大量的訪談數(shù)據(jù)并進(jìn)行分析，以更好地了解技術(shù)訪談，它們所傳達(dá)的信號(hào)，有效和無效的內(nèi)容以及訪談的哪些方面可能對(duì)結(jié)果產(chǎn)生實(shí)質(zhì)性影響。

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.

每次訪談(無論是實(shí)踐訪談還是實(shí)際訪談)都始于在語音，文本聊天和白板等協(xié)作編碼環(huán)境中的訪談?wù)吆褪茉L者會(huì)議，此刻他們直接跳入技術(shù)問題。

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.

在這些訪談中，我們收集發(fā)生的一切，包括音頻記錄，描述受訪者編寫并嘗試運(yùn)行的代碼的數(shù)據(jù)和元數(shù)據(jù)，以及訪談?wù)吆褪茉L者關(guān)于他們?nèi)绾慰创L談以及他們?nèi)绾嗡伎嫉脑敿?xì)反饋彼此。

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.

如果您感到好奇，您可以看到下面的針對(duì)訪調(diào)員和被訪者的反饋表是什么—除了一個(gè)直接的是/否問題外，我們還使用1-4的量表詢問訪談表現(xiàn)的幾個(gè)不同方面。

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.

我們還會(huì)向受訪者詢問一些我們不會(huì)與受訪者分享的其他問題，而我們要問的問題之一是受訪者以前是否曾見過他們剛剛處理過的問題。

結(jié)果 (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.

在深入探討之前，值得注意的是，以下結(jié)論是基于觀察數(shù)據(jù)的，這意味著我們無法做出有力的因果主張……但我們?nèi)匀豢梢苑窒砦覀冇^察到的令人驚訝的關(guān)系，并解釋發(fā)現(xiàn)的事實(shí)，以便您可以得出自己的結(jié)論。

之前看過面試問題 (Having seen the interview question before)

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

“我們正在談?wù)摼毩?xí)！” -艾弗森(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.

首先是第一。 不需要火箭科學(xué)家建議在面試中做得更好的最好方法之一就是……練習(xí)面試。 有很多資源可以幫助您練習(xí)，其中包括我們的資源。 解決實(shí)踐問題的主要好處之一是，您可以減少被要求解決從未見過的問題的可能性。 如果您已經(jīng)完成了一兩次，那么平衡二進(jìn)制搜索樹就不會(huì)那么嚇人了。

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個(gè)訪談的樣本，并將結(jié)果與??受訪者之前是否看過采訪問題進(jìn)行了比較。 您可以在下面的圖中查看結(jié)果。

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.

毫不奇怪，已經(jīng)看到問題的受訪者被訪調(diào)員認(rèn)為可以雇用的可能性增加了16.6％。 這種差異在統(tǒng)計(jì)上非常顯著-這篇文章中的所有誤差線都代表95％的置信區(qū)間。

使用哪種語言有關(guān)系嗎？ (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.

您可能會(huì)想象，不同的語言會(huì)帶來更好的面試機(jī)會(huì)。 例如，也許Python的可讀性使您在采訪中站出來了。 也許某些語言以特別干凈的方式處理數(shù)據(jù)結(jié)構(gòu)的事實(shí)使常見的面試問題變得更加容易。 我們想了解不同面試語言的面試表現(xiàn)在統(tǒng)計(jì)上是否存在顯著差異。

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.

為了進(jìn)行調(diào)查，我們?cè)谄脚_(tái)上通過訪談?wù)Z言對(duì)訪談進(jìn)行了分組，并過濾??了少于5次訪談中使用的所有語言(這僅剔除了少數(shù)訪談)。 完成此操作后，我們可以查看面試結(jié)果以及其隨面試語言的變化。

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.

該分析的結(jié)果在下表中。 任何不重疊的置信區(qū)間都代表了根據(jù)訪問語言的不同，被訪者“通過”訪問的可能性在統(tǒng)計(jì)學(xué)上的顯著差異。

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.)

盡管我們并未針對(duì)每種可能的語言對(duì)進(jìn)行成對(duì)比較，但以下數(shù)據(jù)表明，一般而言， 使用不同語言進(jìn)行的面試成功率之間在統(tǒng)計(jì)學(xué)上沒有顯著差異。 (在我們的平臺(tái)上，有比這些語言更多的語言，但是語言越晦澀，我們得到的數(shù)據(jù)點(diǎn)就越少。例如， 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.

也就是說，我們從質(zhì)量上觀察到的最常見錯(cuò)誤之一是，人們選擇了自己不熟悉的語言，然后弄亂了諸如數(shù)組長度查找，對(duì)數(shù)組進(jìn)行迭代，實(shí)例化哈希表之類的基本內(nèi)容。

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.

當(dāng)受訪者故意選擇一種聽起來聽起來很花哨的語言來打動(dòng)他們的采訪者時(shí)，這尤其使人沮喪。 相信我們，揮舞著您選擇的語言，每次都會(huì)用您不太熟悉的花哨的語言來表現(xiàn)出來。

即使語言無關(guān)緊要……使用公司選擇的語言進(jìn)行編碼是否有利？ (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

“上帝幫助我，我已經(jīng)成為本地人。” —瑪格麗特·布萊恩

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.”

總的來說，面試語言似乎與表現(xiàn)沒有特別的關(guān)系，這一切都很好。 但是，您可能會(huì)想到，根據(jù)給定公司使用的語言，可能會(huì)產(chǎn)生影響。 您可以想象一個(gè)Ruby商店說：“我們只雇用Ruby開發(fā)人員，如果您使用Python進(jìn)行面試，我們不太可能雇用您。”

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編寫所有代碼的公司對(duì)使用Python的受訪者的批評(píng)要嚴(yán)格得多，他們知道這種語言的來龍去脈，并可能會(huì)判斷應(yīng)聘者是否會(huì)做所有事情。在他們的采訪中出現(xiàn)了一些“非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的面試成功率(由面試官愿意聘用被訪者衡量)的差異。 但是，此圖表還根據(jù)面試語言是否在公司堆棧中來區(qū)分績效。

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，因?yàn)檫@是我們使用和不使用該語言的三種語言，我們進(jìn)行了很好的混合采訪。 這里的結(jié)果好壞參半。 當(dāng)面試語言是Python或C ++時(shí)，無論面試語言是否是公司堆棧中的一種語言，面試的成功率在統(tǒng)計(jì)上都沒有顯著差異。 但是，使用Java進(jìn)行訪問的訪問者在訪問Java商店時(shí)更有可能獲得成功 (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)存在的社區(qū)比以前使用該語言的經(jīng)驗(yàn)更高。 沿著這些思路，使用Java的公司的訪問者也可能會(huì)提出一些問題，以青睞那些已經(jīng)具備Java特質(zhì)知識(shí)的人。

您使用哪種語言編程以及您被認(rèn)為是一個(gè)良好的溝通者之間的關(guān)系如何？ (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

“熟練地使用一種語言就是一種令人回味的魔術(shù)。” —查爾斯·鮑德萊爾

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.

即使語言選擇對(duì)整體績效沒有多大的影響(盡管使用Java的公司也是如此)，但我們很好奇，不同的語言選擇是否會(huì)導(dǎo)致其他面試維度的不同結(jié)果。

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)可能會(huì)導(dǎo)致面試候選人被評(píng)估為溝通能力更好。 另一方面，像C ++這樣的低級(jí)語言可能會(huì)導(dǎo)致更高的技術(shù)能力分?jǐn)?shù)。

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.

此外，可讀性強(qiáng)或低級(jí)的語言可能會(huì)導(dǎo)致這兩個(gè)分?jǐn)?shù)之間的相關(guān)性(例如，他們可能是C ++面試候選人，他們根本無法解釋自己在做什么，但編寫的代碼非常有效)。 下表表明，在各種編程語言中，如何看待候選人的技術(shù)和溝通能力之間確實(shí)沒有任何可觀察的差異。

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.

此外，無論如何，技術(shù)能力差似乎與溝通能力差密切相關(guān)-不管使用哪種語言，候選人在技術(shù)上表現(xiàn)良好但不能有效地傳達(dá)他們正在做的事情(反之亦然)的情況相對(duì)較少(主要是(幸運(yùn)的是))揭露不連貫，說話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.)

(我遇到的最好的工程師在傳說中也擅長分解復(fù)雜的概念，并向外行人解釋它們。為什么社會(huì)上笨拙，不連貫的技術(shù)書呆子的令人毛骨悚然的神話繼續(xù)存在，我絕對(duì)不知道。)

面試時(shí)間 (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

“當(dāng)您年輕時(shí)關(guān)心災(zāi)難，可怕的糟糕評(píng)論和拒絕以及所有這些東西，這很好。 您的應(yīng)變能力真棒。” —哈羅德·普林斯

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.

我們都有離開面試的經(jīng)驗(yàn)，只是覺得面試不好。 通常，某些性能不佳的感覺是由經(jīng)驗(yàn)法則引起的，這些經(jīng)驗(yàn)法則是我們自己提出來或反復(fù)聽過。 您可能會(huì)發(fā)現(xiàn)自己在想：“采訪持續(xù)了很長時(shí)間嗎？ 這可能是一個(gè)不好的信號(hào)……”或“在那次采訪中我?guī)缀跏裁炊紱]寫！ 我絕對(duì)不會(huì)過去。” 使用我們的數(shù)據(jù)，我們想看看這些評(píng)估您的面試表現(xiàn)的經(jīng)驗(yàn)法則是否有任何優(yōu)點(diǎn)。

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.

首先，我們看了采訪的時(shí)間。 較短的面試官是否意味著您是如此殘酷，以至于面試官只能提早停止面試？ 還是面試官的時(shí)間比平常少，或者只是在很短的時(shí)間內(nèi)就看到你是一個(gè)很棒的候選人？ 下圖顯示了成功和不成功候選人的面試時(shí)長分布(以分鐘為單位)。

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.

快速瀏覽一下此圖，表明進(jìn)行得不錯(cuò)的面試與不愉快的面試之間的面試時(shí)長分布沒有差異-面試官想聘用候選人的平均面試時(shí)長為51.00分鐘，而平均水平采訪者未參加的采訪時(shí)長為49.95分鐘。 這種差異在統(tǒng)計(jì)上并不顯著 。

(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.)

(對(duì)于本文中的分布的每次比較，我們都使用Fisher-Pitman排列檢驗(yàn)來比較分布均值的差異。)

編寫的代碼量 (Amount of code written)

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

“簡潔是機(jī)智的靈魂。” -威廉·莎士比亞

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.

您可能經(jīng)歷過一次面試，而您完全被困住了。 面試官問您一個(gè)您幾乎不理解的問題，您重復(fù)給他或她“二進(jìn)制搜索什么？”，并且在面試過程中您基本上沒有編寫任何代碼。 您可能希望您仍然可以憑借機(jī)智，魅力和高水平的解決問題的能力通過這樣的面試。 為了評(píng)估這是否成立，我們查看了受訪者編寫的代碼的最終字符長度。 下圖顯示了成功和失敗的字符長度分布。 快速瀏覽一下該圖表，可以發(fā)現(xiàn)兩者之間存在差異-面試不好的訪談往往代碼更少。 有兩種現(xiàn)象可能導(dǎo)致此現(xiàn)象。 首先，不成功的面試官一開始可能編寫更少的代碼。 此外，他們可能更傾向于刪除他們編寫的，無法運(yùn)行或未返回預(yù)期結(jié)果的大量代碼。

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個(gè)字符，而失敗的面試代碼的平均長度為1760個(gè)字符。 那是很大的不同！ 這一發(fā)現(xiàn)具有統(tǒng)計(jì)意義，可能并不十分令人驚訝。

代碼模塊化 (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

“成熟的程序員的標(biāo)志是愿意在發(fā)現(xiàn)毫無意義的時(shí)候扔掉您花費(fèi)的時(shí)間編寫的代碼。” —布拉姆·科恩

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!

除了在你有多少代碼編寫只是看，我們還可以想想你寫的代碼的類型。 傳統(tǒng)觀點(diǎn)認(rèn)為，優(yōu)秀的程序員不要回收代碼，而是編寫可以重復(fù)使用的模塊化代碼。 我們想知道在面試過程中這種行為是否真正得到了回報(bào)。 為了做到這一點(diǎn)，我們查看了用Python 5進(jìn)行的采訪，并計(jì)算了在采訪的最終版本中出現(xiàn)了多少個(gè)函數(shù)定義。 我們想知道成功的受訪者是否定義了更多的功能-雖然擁有更多的函數(shù)處理程序并不是模塊化的定義，但根據(jù)我們的經(jīng)驗(yàn)，這是一個(gè)很強(qiáng)烈的信號(hào)。 與往常一樣，不可能對(duì)此提出強(qiáng)有力的因果主張-某些情況下(某些或多或少寬容的采訪者)可能會(huì)問一些使他們或多或少發(fā)揮作用的采訪問題。 盡管如此，這是一個(gè)有趣的研究趨勢！

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.

下圖顯示了針對(duì)面試官表示愿意雇用的候選人和面試官表示不愿意雇用的候選人定義的Python函數(shù)數(shù)量的分布。 就讓我們來看看這個(gè)圖表明，有是順利的采訪，不采訪之間的函數(shù)定義分布的差異。 成功的受訪者似乎定義了更多功能。

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進(jìn)行面試的成功候選人定義了3.29個(gè)功能，而失敗的候選人定義了2.71個(gè)功能。 這一發(fā)現(xiàn)具有統(tǒng)計(jì)意義。 結(jié)果是，面試官確實(shí)確實(shí)獎(jiǎng)勵(lì)他們說要您編寫的那種代碼。

代碼運(yùn)行是否重要？ (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

“快速行動(dòng)，打破常規(guī)。 除非您破壞東西，否則您的移動(dòng)速度不夠快。” —馬克·扎克伯格

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

“最有效的調(diào)試工具仍需慎重考慮，并明智地放置打印語句。” —布賴恩·克尼根( 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?

技術(shù)面試中的一個(gè)常見限制是，面試官實(shí)際上并不在乎您的代碼是否運(yùn)行-他們所關(guān)心的是解決問題的技能。 由于我們收集有關(guān)受訪者運(yùn)行的代碼以及該代碼是否編譯的數(shù)據(jù)，因此我們想查看我們的數(shù)據(jù)中是否有證據(jù)。 在成功的采訪中和沒有成功的采訪中，無錯(cuò)誤編譯代碼的百分比之間是否有區(qū)別？ 此外，即使被訪者犯了很多語法錯(cuò)誤，他們實(shí)際上還能被雇用嗎？

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.

為了解決這個(gè)問題，我們查看了數(shù)據(jù)。 我們將數(shù)據(jù)集的訪問時(shí)間限制在10分鐘以上，并且要執(zhí)行5個(gè)以上的唯一代碼實(shí)例。 這有助于過濾掉訪談?wù)邔?shí)際上不希望受訪者運(yùn)行代碼的地方，或者由于某種原因而縮短了訪談的時(shí)間。 然后，我們測量了導(dǎo)致錯(cuò)誤的代碼運(yùn)行百分比。 5當(dāng)然，這種方法有一些局限性-例如，候選人可以執(zhí)行確實(shí)可以編譯但給出了稍微錯(cuò)誤答案的代碼。 他們還可以獲得正確的答案并將其寫入stderr！ 盡管如此，這應(yīng)該使我們對(duì)是否存在差異有方向性的認(rèn)識(shí)。

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?

下表總結(jié)了這些數(shù)據(jù)。 x軸顯示在給定采訪中無錯(cuò)誤的代碼執(zhí)行百分比。 因此，對(duì)3條代碼執(zhí)行和1條錯(cuò)誤消息的采訪將計(jì)入“ 30％-40％”存儲(chǔ)桶。 y軸表示成功和不成功的采訪中屬于該類別的所有采訪的百分比。 僅僅關(guān)注下面的圖表，就可以感覺到，成功的候選人平均而言會(huì)運(yùn)行更多的代碼而不會(huì)出錯(cuò)。 但是，這種差異具有統(tǒng)計(jì)意義嗎？

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.

平均而言，成功的候選人的代碼成功運(yùn)行(沒有導(dǎo)致錯(cuò)誤)的時(shí)間為64％，而失敗的候選人的代碼編譯嘗試成功地運(yùn)行的時(shí)間為60％，而這種差異確實(shí)非常明顯。 同樣，盡管我們不能提出任何因果關(guān)系的主張，但主要的結(jié)論是，盡管面試官在面試開始時(shí)會(huì)告訴您什么，但是成功的候選人通常會(huì)編寫出性能更好的代碼。

在編寫代碼之前，您應(yīng)該等待并收集想法嗎？ (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

“永遠(yuǎn)不要忘記沉默的力量，那令人不安的停頓不斷地發(fā)生，并最終可能導(dǎo)致對(duì)手緊張地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.

我們也很好奇，成功的受訪者是否傾向于抽時(shí)間參加采訪。 面試問題通常很復(fù)雜！ 提出問題后，退后一步并提出一個(gè)計(jì)劃可能會(huì)有些好處，而不是立即著手進(jìn)行。 為了了解這是否成立，我們測量了候選人首次執(zhí)行代碼到給定面試中的距離。 以下是一個(gè)直方圖，顯示成功和失敗的受訪者首次運(yùn)行代碼對(duì)訪談的距離。 快速查看直方圖，您可以看出，成功的候選人實(shí)際上等待了更長的時(shí)間才能開始運(yùn)行代碼，盡管影響的程度并不大。

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.

更具體地說， 平均而言，成功進(jìn)行面試的候選人在面試過程中會(huì)先執(zhí)行代碼的27％，而未成功進(jìn)行面試的候選人會(huì)在面試過程中先執(zhí)行代碼的23.9％，這種差異是很明顯的 。 當(dāng)然，對(duì)于這里發(fā)生的事情，還有其他解釋。 例如，也許成功的候選人更擅長花時(shí)間與面試官交談。 此外，我們不能提出因果關(guān)系聲明的通常警告是適用的-如果您在完全沉默的情況下僅在訪談中多坐了5分鐘，那將無濟(jì)于事。 但是，這兩個(gè)隊(duì)列之間似乎確實(shí)存在差異。

結(jié)論 (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.

總而言之，這篇文章是我們第一次嘗試了解做什么和不做什么，通常會(huì)導(dǎo)致面試官說：“你知道嗎，我真的很想雇用這個(gè)人。” 由于我們所有的數(shù)據(jù)都是觀察性的，因此很難對(duì)我們所看到的內(nèi)容進(jìn)行因果斷言。

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.

盡管成功的受訪者可能表現(xiàn)出某些行為，但采用這些行為并不能保證成功。 但是，它確實(shí)使我們能夠支持(或致電BS)您將在互聯(lián)網(wǎng)上閱讀的許多關(guān)于如何成為成功的受訪者的建議。

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.

也就是說，還有許多工作要做。 這是對(duì)我們數(shù)據(jù)的第一次定量傳遞(在許多方面，這都是采訪秘密的寶庫)，但我們很高興進(jìn)行更深入，定性的考察，實(shí)際上開始對(duì)不同的問題進(jìn)行分類，以了解哪些問題帶有大多數(shù)信號(hào)以及真正引起我們注意的二階行為，您都無法通過在代碼樣本上運(yùn)行正則表達(dá)式或衡量采訪花費(fèi)了多長時(shí)間來輕松衡量。

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

如果您想在此方面為我們提供幫助，并且很高興聽一堆技術(shù)訪談，請(qǐng)給我留言 ！

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

想要在技術(shù)面試中變得很棒，并在此過程中找到下一份工作嗎？ 參加訪談吧！

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

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)

總結(jié)

以上是生活随笔為你收集整理的我们分析了成千上万的编程访谈。 这就是我们学到的东西。的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。