Vi analyserede tusindvis af kodende interviews. Her er hvad vi lærte.

Bemærk: Jeg skrev de fleste af ordene i dette indlæg, men den legendariske Dave Holtz gjorde det tunge løft på datasiden. Se mere af hans arbejde på hans blog.

Hvis du læser dette indlæg, er der en anstændig chance for, at du er ved at komme ind i den skøre og skræmmende verden af ​​tekniske interviews.

Måske er du en universitetsstuderende eller en ny grad, der gennemgår interviewprocessen for første gang. Måske er du en erfaren softwareingeniør, der ikke engang har tænkt på interviews i et par år.

Uanset hvad er det første trin i interviewprocessen normalt at læse en masse online interviewguider (især hvis de er skrevet af virksomheder, du er interesseret i) og chatte med venner om deres erfaringer med interviewprocessen (både som en interviewer og en interviewperson).

Mere sandsynligt end ikke, hvad du læser og lærer i denne første "udforskende" fase af interviewprocessen vil informere om, hvordan du vælger at forberede dig fremad.

Der er et par problemer med denne typiske tilgang til interviewforberedelse:

  • De fleste interviewguider er skrevet ud fra et selskabs perspektiv. Mens firma A virkelig kan værdsætte effektiv kode, kan virksomhed B lægge mere vægt på højtstående problemløsningsfærdigheder. Medmindre dit hjerte er rettet mod firma A, vil du sandsynligvis ikke give for meget vægt på det, de værdsætter.
  • Folk lyver nogle gange, selvom de ikke betyder det. Skriftligt siger virksomheder måske, at de er sprogagnostikere, eller at det er værd at forklare din tankeproces, selvom svaret ikke er helt rigtigt. Det er dog ikke klart, om det faktisk er sådan, de handler! Vi siger ikke, at teknologivirksomheder er skumle løgnere, der forsøger at vildlede deres ansøgerpulje. Vi siger bare, at undertiden sniger implicitte forstyrrelser ind, og folk er ikke engang klar over dem.
  • Meget af den "folkelige viden", som du hører fra venner og bekendte, er måske slet ikke baseret. Mange antager, at korte interviews stave undergang. På samme måde kan alle huske et langt interview, hvorefter de har tænkt over for sig selv: "Jeg slog det virkelig sammen med den interviewer, jeg bliver bestemt sendt videre til næste trin." Tidligere har vi set, at folk virkelig er dårlige til at måle, hvordan de gjorde det i interviews. Denne gang ville vi se direkte på indikatorer som interviewlængde og se, om de faktisk betyder noget.

Hos mig, interviewing.io, er vi entydigt positioneret til at nærme tekniske interviews og deres resultater på en datadrevet måde. Vi har en platform, hvor folk kan øve teknisk samtale anonymt. Og hvis tingene går godt, kan de låse op for muligheden for at interviewe anonymt, når som helst de vil, med topfirmaer som Uber, Lyft og Twitch.

Det seje er, at både praksisinterviews og rigtige interviews med virksomheder finder sted inden for interviewing.io-økosystemet. Som et resultat er vi i stand til at indsamle en hel del interviewdata og analysere dem for bedre at forstå tekniske interviews, signalet de bærer, hvad der fungerer og hvad der ikke fungerer, og hvilke aspekter af et interview der faktisk kan have betydning for resultatet .

Hvert interview, hvad enten det er praksis eller ægte, starter med intervieweren og interviewpersonens møde i et samarbejdende kodemiljø med stemme, tekstchat og en whiteboard, på hvilket tidspunkt de springer lige ind i et teknisk spørgsmål.

Interviewspørgsmål har en tendens til at falde i kategorien for, hvad du vil støde på på en telefonskærm for en back-end software engineering-rolle.

Under disse interviews indsamler vi alt, hvad der sker, inklusive lydudskrifter, data og metadata, der beskriver koden, som interviewpersonen skrev og forsøgte at køre, og detaljeret feedback fra både intervieweren og den interviewede om, hvordan de synes, interviewet gik, og hvad de tænkte på hinanden.

Hvis du er nysgerrig, kan du se, hvordan feedbackformularerne for interviewere og interviewpersoner ser ud nedenfor - ud over et direkte ja / nej-spørgsmål spørger vi også om et par forskellige aspekter af interviewpræstation ved hjælp af en skala fra 1–4.

Vi stiller også interviewpersoner nogle ekstra spørgsmål, som vi ikke deler med deres interviewere, og en af ​​de ting, vi stiller, er, om en interviewperson tidligere har set det spørgsmål, de lige har arbejdet med.

Resultaterne

Inden vi går i dybden med det, er det værd at bemærke, at konklusionerne nedenfor er baseret på observationsdata, hvilket betyder, at vi ikke kan fremsætte stærke årsagskrav ... men vi kan stadig dele overraskende forhold, vi har observeret, og forklare, hvad vi fandt, så kan drage dine egne konklusioner.

Efter at have set interviewspørgsmålet før

"Vi taler om praksis!" -Allen Iverson

Første ting først. Det tager ikke en raketforsker at antyde, at en af ​​de bedste måder at gøre det bedre i interviews er at ... øve sig på interviews. Der er en række ressourcer derude for at hjælpe dig med at øve, vores blandt dem. En af de største fordele ved at arbejde gennem praksisproblemer er, at du reducerer sandsynligheden for at blive bedt om at løse noget, du aldrig har set før. At balancere det binære søgetræ vil være meget mindre skræmmende, hvis du allerede har gjort det en eller to gange.

Vi så på en prøve på ~ 3000 interviews og sammenlignede resultatet med, om interviewpersonen havde set interviewspørgsmålet før. Du kan se resultaterne i plottet nedenfor.

Ikke overraskende var interviewpersoner, der havde set spørgsmålet, 16,6% mere tilbøjelige til at blive anset for ansættelige af deres interviewere. Denne forskel er statistisk signifikant - alle fejlfelt i dette indlæg repræsenterer et 95% konfidensinterval.

Betyder det noget hvilket sprog du koder på?

"Den, der ikke elsker sproget i sin fødsel, er lavere end et dyr og en ildelugtende fisk." - Jose Rizal

Du kan forestille dig, at forskellige sprog fører til bedre interviews. For eksempel giver måske læsbarheden af ​​Python dig et ben op i interviews. Eller måske gør det faktum, at visse sprog håndterer datastrukturer på en særdeles ren måde, almindelige interviewspørgsmål lettere. Vi ønskede at se, om der var statistisk signifikante forskelle i interviewpræstationer på tværs af forskellige interviewsprog.

For at undersøge grupperede vi interviews på vores platform efter interviewsprog og filtrerede alle sprog, der blev brugt i færre end 5 interviews (dette kastede kun en håndfuld interviews ud). Efter at have gjort dette var vi i stand til at se på interviewresultatet, og hvordan det varierede som en funktion af interviewsproget.

Resultaterne af denne analyse findes i nedenstående skema. Alle ikke-overlappende tillidsintervaller repræsenterer en statistisk signifikant forskel i, hvor sandsynligt en interviewperson er til at 'bestå' et interview som en funktion af interviewsproget.

Selvom vi ikke foretager en parvis sammenligning for hvert muligt sprogpar, antyder nedenstående data, at der generelt ikke er statistisk signifikante forskelle mellem succesraten, når interviews gennemføres på forskellige sprog. (Der var flere sprog end disse på vores platform, men jo mere uklart sproget, jo færre datapunkter har vi. For eksempel var alle interviews i Brainf *** klart vellykkede. Sjov.)

Når det er sagt, er en af ​​de mest almindelige fejl, vi har observeret kvalitativt, folk, der vælger sprog, de ikke er fortrolige med, og derefter ødelægger de grundlæggende ting som opslag i array-længde, iterer over et array, instanterer et hash-bord osv.

Dette er især dødbringende, når interviewpersoner med vilje vælger et fancy-klingende sprog for at imponere deres interviewer. Stol på os, når du bruger dit valgte sprog, slår det komfortabelt ud og viser dig på et smukt sprog, du ikke kender godt, hver gang.

Selvom sprog ikke betyder noget ... er det fordelagtigt at kode på virksomhedens valgsprog?

"Gud hjælper mig, jeg er blevet hjemmehørende." - Margaret Blaine

Det er godt og godt, at interviewsprog generelt ikke synes at være særlig korreleret med ydeevne. Du kan dog forestille dig, at der kan være en effekt afhængigt af det sprog, en given virksomhed bruger. Du kan forestille dig en Ruby-butik, der siger "vi ansætter kun Ruby-udviklere, hvis du interviewer i Python, er vi mindre tilbøjelige til at ansætte dig."

På bagsiden kan du forestille dig, at et firma, der skriver al deres kode i Python, vil være meget mere kritisk over for en interviewet i Python - de kender sprogets ind og ud og måske bedømmer kandidaten for at gøre alt slags "ikke-pythoniske" ting under deres interview.

Diagrammet nedenfor svarer til diagrammet, som viste forskelle i interviewets succesrate (målt ved at interviewere var villige til at ansætte interviewpersonen) til C ++, Java og Python. Imidlertid bryder dette diagram også præstation ved, om interviewsproget er i virksomhedens stak eller ej.

Vi begrænser denne analyse til C ++, Java og Python, fordi det er de tre sprog, hvor vi havde en god blanding af interviews, hvor virksomheden gjorde og ikke brugte dette sprog. Resultaterne her er blandede. Når interviewsproget er Python eller C ++, er der ingen statistisk signifikant forskel mellem succesraterne for interviews, hvor interviewsproget er eller ikke er et sprog i virksomhedens stak. Interviewere, der interviewede i Java, var imidlertid mere tilbøjelige til at få succes, når de interviewede med en Java-butik (p = 0,037).

Så hvorfor er det, at kodning på virksomhedens sprog synes at være nyttigt, når det er Java, men ikke når det er Python eller C ++? En mulig forklaring er, at de samfund, der findes omkring bestemte programmeringssprog (såsom Java), lægger en højere præmie på tidligere erfaringer med sproget. På denne linje er det også muligt, at interviewere fra virksomheder, der bruger Java, er mere tilbøjelige til at stille spørgsmål, der favoriserer dem med en eksisterende viden om Java's idiosynkrasier.

Hvad med forholdet mellem hvilket sprog du programmerer på og hvor god en kommunikator, du opfattes at være?

"At håndtere et sprog dygtigt er at praktisere en slags stemningsfuld trolddom." - Charles Baudelaire

Selvom sprogvalg ikke betyder så meget for den samlede præstation (trods Java-svingende virksomheder), var vi nysgerrige efter, om forskellige sprogvalg førte til forskellige resultater i andre interviewdimensioner.

For eksempel kan et ekstremt læsbart sprog som Python føre til interviewkandidater, der vurderes at have kommunikeret bedre. På den anden side kan et lavt sprog som C ++ føre til højere score for teknisk evne.

Desuden kan meget læsbare eller lavniveausprog føre til sammenhænge mellem disse to scores (for eksempel er de måske en C ++ - interviewkandidat, der slet ikke kan forklare, hvad han eller hun laver, men som skriver meget effektiv kode). Diagrammet nedenfor antyder, at der ikke virkelig er nogen observerbar forskel mellem, hvordan kandidaternes tekniske og kommunikative evner opfattes på tværs af en række programmeringssprog.

Desuden virker uanset hvad, dårlig teknisk evne stærkt korreleret med dårlig kommunikationsevne - uanset sprog er det relativt sjældent, at kandidater klarer sig godt teknisk, men ikke effektivt kommunikerer, hvad de laver (eller omvendt) stort set (og heldigvis) debunking myten om den usammenhængende, hurtigt talende, akavede ingeniør.

(De bedste ingeniører, jeg har mødt, har også legendarisk været gode til at nedbryde komplekse koncepter og forklare dem for lægfolk. Hvorfor den oprørende myte om den socialt akavede, usammenhængende teknologinerd fortsætter med at eksistere, har jeg absolut ingen idé om.)

Interviewets varighed

“Det er fint, når du passer på katastrofer og skræmmende dårlige anmeldelser og afvisning og alt det der, når du er ung; din modstandsdygtighed er bare fantastisk. ” - Harold Prince

Vi har alle oplevet at forlade et interview og bare føle, at det gik dårligt. Ofte er følelsen af ​​en vis underpræstation motiveret af tommelfingerregler, som vi enten er kommet op med os selv eller hørt gentaget igen og igen. Du tænker måske, ”interviewet varede ikke længe? Det er sandsynligvis et dårligt tegn ... ”eller” Jeg skrev næppe noget i det interview! Jeg vil bestemt ikke bestå. ” Ved hjælp af vores data ønskede vi at se, om disse tommelfingerregler til evaluering af din interviewpræstation havde nogen fortjeneste.

Først så vi på længden af ​​interviewet. Betyder en kortere interviewer, at du var sådan et togvrag, at intervieweren bare var nødt til at stoppe interviewet tidligt? Eller var det måske sådan, at intervieweren havde kortere tid end normalt, eller på kort tid havde set, at du var en fantastisk kandidat? Diagrammet nedenfor viser fordelingen af ​​interviewlængde (målt i minutter) for både vellykkede og mislykkede kandidater.

Et hurtigt kig på dette diagram antyder, at der ikke er nogen forskel i fordelingen af ​​interviewlængder mellem interviews, der går godt, og interviews, der ikke gør - gennemsnitslængden af ​​interviews, hvor intervieweren ønskede at ansætte kandidaten, var 51,00 minutter, mens gennemsnittet længden af ​​interviews, hvor intervieweren ikke gjorde det, var 49,95 minutter. Denne forskel er ikke statistisk signifikant .

(For hver sammenligning af distributioner i dette indlæg bruger vi både en Fisher-Pitman permutationstest til at sammenligne forskellen i middel til distributionerne.)

Mængde kode skrevet

"Brusethed er sjælens humor." -William Shakespeare

Du har muligvis oplevet et interview, hvor du blev fuldstændig stubbet. Intervieweren stiller dig et spørgsmål, du næppe forstår, du gentager tilbage til ham eller hende "binær søgning hvad?", Og du skriver stort set ingen kode under dit interview. Du håber måske, at du stadig kan bestå et interview som dette gennem ren humor, charme og højt niveau problemløsning færdigheder. For at vurdere, om dette var sandt eller ej, kiggede vi på den endelige karakterlængde af kode skrevet af interviewpersonen. Plottet nedenfor viser fordelingen af ​​karakterlængde for både vellykket og mislykket. Et hurtigt kig på dette diagram antyder, at der er forskel på de to - interviews, der ikke går godt, har tendens til at have mindre kode. Der er to fænomener, der kan bidrage til dette. For det første kan mislykkede interviewere måske skrive mindre kode til at begynde med. Derudoverde er måske mere tilbøjelige til at slette store dele af kode, de har skrevet, som enten ikke kører eller ikke returnerer det forventede resultat.

I gennemsnit havde succesrige interviews den sidste interviewkode, der gennemsnitligt var 2045 tegn lang, mens de mislykkede i gennemsnit var 1760 tegn lange. Det er en stor forskel! Dette fund er statistisk signifikant og sandsynligvis ikke særlig overraskende.

Kodemodularitet

"Mærket for en moden programmør er villighed til at smide kode, du brugte tid på, når du indser, at den er meningsløs." - Bram Cohen

Ud over at bare se på hvor megetkode, du skriver, kan vi også tænke over, hvilken type kode du skriver. Konventionel visdom antyder, at gode programmører ikke genbruger kode - de skriver modulær kode, der kan genbruges igen og igen. Vi ønskede at vide, om den slags adfærd faktisk blev belønnet under interviewprocessen. For at gøre det så vi på interviews gennemført i Python5 og tællede, hvor mange funktionsdefinitioner der var i den endelige version af interviewet. Vi ønskede at vide, om succesrige interviewpersoner definerede flere funktioner - mens det at have flere funktionshåndterere ikke er definitionen af ​​modularitet, er det efter vores erfaring et ret stærkt signal om det. Som altid,det er umuligt at fremsætte stærke kausale påstande om dette - det kan være tilfældet, at visse interviewere (som er mere eller mindre lempelige) stiller interviewspørgsmål, der egner sig til flere eller færre funktioner. Ikke desto mindre er det en interessant tendens at undersøge!

Diagrammet nedenfor viser fordelingen af ​​antallet af Python-funktioner defineret for både kandidater, som intervieweren sagde, at de ville ansætte, og kandidater, som intervieweren sagde, at de ikke ville ansætte. Et hurtigt kig på dette diagram antyder, at der er en forskel i fordelingen af ​​funktionsdefinitioner mellem interviews, der går godt, og interviews, der ikke gør det. Succesrige interviewpersoner ser ud til at definere flere funktioner.

I gennemsnit definerer vellykkede kandidater, der interviewer i Python, 3,29 funktioner, mens mislykkede kandidater definerer 2,71 funktioner. Dette fund er statistisk signifikant. Resultatet her er, at interviewere virkelig belønner den slags kode, de siger, at de vil have dig til at skrive.

Betyder det noget, om din kode kører?

”Gå hurtigt og knæk ting. Medmindre du bryder ting, bevæger du dig ikke hurtigt nok. ” - Mark Zuckerberg "Det mest effektive fejlretningsværktøj er stadig omhyggelig tanke kombineret med skønsmæssigt placerede udskriftserklæringer." - Brian Kernighan

En almindelig afståelse i tekniske interviews er, at interviewere ikke er ligeglad med, om din kode kører - det, de bryr sig om, er problemløsningskompetencer. Da vi indsamler data om den kode, interviewpersoner kører, og om koden kompileres eller ej, ville vi se, om der var beviser for dette i vores data. Er der nogen forskel mellem procentdelen af ​​kode, der kompilerer fejlfri i succesrige interviews versus mislykkede interviews? Desuden kan interviewpersoner faktisk stadig blive ansat, selvom de laver masser af syntaksfejl?

For at komme til dette spørgsmål så vi på dataene. Vi begrænsede vores datasæt til interviews længere end 10 minutter med mere end 5 unikke forekomster af kode, der blev udført. Dette hjalp med at filtrere interviews, hvor interviewere faktisk ikke ønskede, at interviewpersonen skulle køre kode, eller hvor interviewet af en eller anden grund blev afbrudt. Vi målte derefter procentdelen af ​​kodekørsler, der resulterede i fejl. 5 Naturligvis er der nogle begrænsninger for denne tilgang - for eksempel kan kandidater udføre kode, der kompilerer, men giver et lidt forkert svar. De kunne også få det rigtige svar og skrive det til stderr! Ikke desto mindre bør dette give os en retningsbestemt fornemmelse af, om der er en forskel eller ej.

Diagrammet nedenfor giver et resumé af disse data. X-aksen viser procentdelen af ​​kodeudførelser, der var fejlfri i et givet interview. Så et interview med 3 kodeudførelser og 1 fejlmeddelelse tæller med i "30% -40%" bucket. Y-aksen angiver procentdelen af ​​alle interviews, der falder i den spand, for både vellykkede og mislykkede interviews. Bare ved at kigge på nedenstående diagram får man en fornemmelse af, at succesrige kandidater i gennemsnit kører mere kode, der går ud uden en fejl. Men er denne forskel statistisk signifikant?

I gennemsnit kørte succesrige kandidaters kode med succes (resulterede ikke i fejl) 64% af tiden, mens mislykkede kandidaters forsøg på at kompilere kode kørte med succes 60% af tiden, og denne forskel var faktisk betydelig. Igen, mens vi ikke kan fremsætte nogen årsagskrav, er den vigtigste afhentning, at succesrige kandidater normalt skriver kode, der løber bedre, på trods af hvad interviewere måske fortæller dig i starten af ​​et interview.

Skal du vente og samle dine tanker, før du skriver kode?

"Glem aldrig magten i stilhed, den massivt foruroligende pause, der fortsætter og fortsætter, og som til sidst kan få en modstander til at snakke nervøst." - Lance Morrow

Vi var også nysgerrige efter, om succesrige interviewpersoner havde tendens til at tage deres tid i interviewet. Interviewspørgsmål er ofte komplekse! Efter at være blevet præsenteret for et spørgsmål kan der være en fordel ved at tage et skridt tilbage og komme med en plan snarere end at springe lige ind i tingene. For at få en fornemmelse af, om dette var sandt eller ej, målte vi, hvor langt ind i et givet interview kandidater først udførte kode. Nedenfor er et histogram, der viser, hvor langt i interviews både succesrige og mislykkede interviewpersoner først løb kode. Når man ser hurtigt på histogrammet, kan man fortælle, at succesrige kandidater faktisk venter lidt længere på at køre kode, selvom effekten af ​​effekten ikke er enorm.

Mere specifikt kører kandidater med succesfulde interviews i gennemsnit først 27% af vejen gennem interviewet, mens kandidater med mislykkede interviews først kører 23,9% af vejen ind i interviewet, og denne forskel er signifikant . Selvfølgelig er der alternative forklaringer på, hvad der sker her. For eksempel er vellykkede kandidater måske bedre til at tage sig tid til at snakke deres interviewer. Desuden gælder den sædvanlige advarsel, som vi ikke kan fremsætte årsagskrav - hvis du bare sidder i et interview i yderligere 5 minutter i fuldstændig stilhed, hjælper det ikke dine chancer. Ikke desto mindre synes der at være en forskel mellem de to kohorter.

Konklusioner

Alt i alt var dette indlæg vores første forsøg på at forstå, hvad der gør og ikke typisk fører til, at en interviewer siger "ved du hvad, jeg vil virkelig gerne ansætte denne person." Fordi alle vores data er iagttagende, er det svært at gøre årsagskrav om, hvad vi ser.

Mens succesrige interviewpersoner kan udvise visse adfærd, garanterer det ikke succes at vedtage denne adfærd. Ikke desto mindre tillader det os at støtte (eller ringe til BS) en masse af de råd, du vil læse på internettet om, hvordan man bliver en succesrig interviewperson.

Når det er sagt, er der meget, der stadig skal gøres. Dette var et første, kvantitativt overskridelse af vores data (som på mange måder er en skat af interviewhemmeligheder), men vi er glade for at lave et dybere, kvalitativt dyk og faktisk begynde at kategorisere forskellige spørgsmål for at se, hvilken bærer mest signal såvel som virkelig få vores hoved omkring 2. ordens adfærd, som du ikke let kan måle ved at køre en regex over en kodeeksempel eller måle, hvor lang tid et interview tog.

Hvis du vil hjælpe os med dette og er glade for at lytte til en masse tekniske interviews, så send mig en linje!

Vil du blive fantastisk til tekniske interviews og lande dit næste job i processen? Deltag i interviewing.io!