Abbiamo analizzato migliaia di interviste di programmazione. Ecco cosa abbiamo imparato.

Nota: ho scritto la maggior parte delle parole in questo post, ma il leggendario Dave Holtz ha fatto il duro lavoro sul lato dati. Vedi più del suo lavoro sul suo blog.

Se stai leggendo questo post, c'è una buona possibilità che stai per rientrare nel mondo pazzo e spaventoso delle interviste tecniche.

Forse sei uno studente universitario o un nuovo laureato che sta attraversando il processo di intervista per la prima volta. Forse sei un ingegnere informatico esperto che non ha nemmeno pensato alle interviste per alcuni anni.

Ad ogni modo, il primo passo nel processo di intervista è in genere leggere un sacco di guide di intervista online (specialmente se sono scritte da aziende a cui sei interessato) e chattare con gli amici sulle loro esperienze con il processo di intervista (sia come un intervistatore e intervistato).

Molto probabilmente, ciò che leggi e apprendi in questa prima fase "esplorativa" del processo di intervista ti informerà su come scegli di prepararti ad andare avanti.

Esistono alcuni problemi con questo tipico approccio alla preparazione del colloquio:

  • La maggior parte delle guide per le interviste sono scritte dal punto di vista di un'azienda. Mentre la società A può davvero valorizzare il codice efficiente, la società B può porre maggiormente l'accento sulle capacità di risoluzione dei problemi di alto livello. A meno che il tuo cuore non sia impostato sull'azienda A, probabilmente non vorrai dare troppo peso a ciò che apprezzano.
  • Le persone mentono a volte, anche se non intendono farlo. Per iscritto, le aziende potrebbero dire di essere agnostiche nel linguaggio o che vale la pena spiegare il processo di pensiero, anche se la risposta non è corretta. Tuttavia, non è chiaro se questo è in realtà il loro comportamento! Non stiamo dicendo che le aziende tecnologiche siano dei bugiardi malvagi che stanno cercando di fuorviare il loro pool di candidati. Stiamo solo dicendo che a volte i pregiudizi impliciti si insinuano e le persone non ne sono nemmeno consapevoli.
  • Molte delle "conoscenze popolari" che sentite da amici e conoscenti potrebbero non basarsi di fatto. Molte persone credono che brevi interviste facciano incantesimi. Allo stesso modo, tutti possono ricordare una lunga intervista dopo la quale hanno pensato tra loro: "L'ho davvero colpito con quell'intervistatore, passerò sicuramente alla fase successiva". In passato, abbiamo visto che le persone sono veramente male nel valutare come hanno fatto nelle interviste. Questa volta, volevamo esaminare direttamente gli indicatori come la durata dell'intervista e vedere se quelli effettivamente contano.

Nella mia azienda, intervistando.io, siamo in una posizione unica per affrontare le interviste tecniche e i loro risultati in modo guidato dai dati. Abbiamo una piattaforma in cui le persone possono esercitarsi in colloqui tecnici in forma anonima. E se le cose vanno bene, possono sbloccare la possibilità di intervistare in modo anonimo, ogni volta che lo desiderano, con le migliori aziende come Uber, Lyft e Twitch.

La cosa interessante è che all'interno dell'ecosistema intervistamento si svolgono sia interviste pratiche che interviste reali con aziende. Di conseguenza, siamo in grado di raccogliere un bel po 'di dati sul colloquio e analizzarli per comprendere meglio le interviste tecniche, il segnale che portano, cosa funziona e cosa no e quali aspetti di un colloquio potrebbero essere importanti per il risultato .

Ogni intervista, che sia pratica o reale, inizia con l'intervistatore e l'intervistato che si incontrano in un ambiente di codifica collaborativa con voce, chat di testo e una lavagna, a quel punto passano direttamente a una domanda tecnica.

Le domande di intervista tendono a rientrare nella categoria di ciò che potresti incontrare in uno schermo del telefono per un ruolo di ingegneria del software di back-end.

Durante queste interviste, raccogliamo tutto ciò che accade, tra cui trascrizioni audio, dati e metadati che descrivono il codice che l'intervistato ha scritto e cercato di eseguire e feedback dettagliati sia dell'intervistatore che dell'intervistato su come pensano che l'intervista sia andata e cosa hanno pensato l'un l'altro.

Se sei curioso, puoi vedere come appaiono i moduli di feedback per gli intervistatori e gli intervistati di seguito: oltre a una domanda diretta sì / no, ti chiediamo anche alcuni aspetti diversi del rendimento dell'intervista usando una scala 1-4.

Facciamo anche agli intervistati alcune domande extra che non condividiamo con i loro intervistatori, e una delle cose che chiediamo è se un intervistato ha già visto la domanda su cui ha appena lavorato.

Modulo di feedback per gli intervistatoriModulo di feedback per gli intervistati

I risultati

Prima di approfondire, vale la pena notare che le conclusioni che seguono sono basate su dati osservativi, il che significa che non possiamo fare forti affermazioni causali ... ma possiamo ancora condividere relazioni sorprendenti che abbiamo osservato e spiegare ciò che abbiamo trovato in modo da te puoi trarre le tue conclusioni.

Dopo aver visto la domanda dell'intervista prima

"Stiamo parlando di pratica!" -Allen Iverson

Cominciando dall'inizio. Non ci vuole uno scienziato missilistico a suggerire che uno dei modi migliori per fare meglio nelle interviste sia ... esercitarsi nell'intervista. Ci sono un certo numero di risorse là fuori per aiutarti a praticare, la nostra tra queste. Uno dei principali vantaggi di risolvere problemi pratici è la riduzione della probabilità che ti venga chiesto di risolvere qualcosa che non hai mai visto prima. Bilanciare l'albero di ricerca binario sarà molto meno intimidatorio se lo hai già fatto una o due volte.

Abbiamo esaminato un campione di circa 3000 interviste e confrontato il risultato se l'intervistato aveva già visto la domanda dell'intervista. Puoi vedere i risultati nella trama qui sotto.

Non sorprende che gli intervistati che avevano visto la domanda avessero il 16,6% in più di probabilità di essere considerati desiderabili dal loro intervistatore. Questa differenza è statisticamente significativa: tutte le barre di errore in questo post rappresentano un intervallo di confidenza del 95%.

Importa in quale lingua codifichi?

"Chi non ama la lingua della sua nascita è inferiore a una bestia e un pesce maleodorante." - Jose Rizal

Potresti immaginare che lingue diverse conducano a interviste migliori. Ad esempio, forse la leggibilità di Python ti dà un vantaggio nelle interviste. O forse il fatto che alcune lingue gestiscano le strutture di dati in modo particolarmente pulito rende più semplici le domande più frequenti sulle interviste. Volevamo vedere se ci fossero o no differenze statisticamente significative nelle prestazioni dell'intervista in diversi linguaggi di intervista.

Per indagare, abbiamo raggruppato le interviste sulla nostra piattaforma in base al linguaggio delle interviste e abbiamo filtrato tutte le lingue utilizzate in meno di 5 interviste (ciò ha generato solo una manciata di interviste). Dopo averlo fatto, siamo stati in grado di esaminare i risultati dell'intervista e come variava in funzione del linguaggio dell'intervista.

I risultati di tale analisi sono nella tabella seguente. Eventuali intervalli di confidenza non sovrapposti rappresentano una differenza statisticamente significativa nella probabilità che un intervistato debba "superare" un'intervista, in funzione del linguaggio dell'intervista.

Sebbene non effettuiamo un confronto a coppie per ogni possibile coppia di lingue, i dati seguenti suggeriscono che in generale, non ci sono differenze statisticamente significative tra il tasso di successo quando le interviste sono condotte in lingue diverse. (C'erano più lingue di queste sulla nostra piattaforma, ma più oscura è la lingua, meno punti dati abbiamo. Ad esempio, tutte le interviste in Brainf *** hanno avuto chiaramente successo. Scherzo.)

Detto questo, uno degli errori più comuni che abbiamo osservato qualitativamente è che le persone scelgono le lingue in cui non si sentono a proprio agio e quindi rovinano cose di base come la ricerca della lunghezza dell'array, iterando su un array, istanziando una tabella hash e così via.

Ciò è particolarmente mortificante quando gli intervistati scelgono di proposito un linguaggio dal suono elaborato per impressionare il loro intervistatore. Fidati di noi, maneggiare comodamente la tua lingua preferita batte esibirsi in un linguaggio dal suono fantasioso che non conosci bene, ogni volta.

Anche se la lingua non ha importanza ... è vantaggioso programmare nella lingua scelta dall'azienda?

"Dio mi aiuti, sono diventato nativo." - Margaret Blaine

È positivo che, in generale, il linguaggio delle interviste non sembri particolarmente correlato alle prestazioni. Tuttavia, potresti immaginare che potrebbe esserci un effetto a seconda della lingua utilizzata da una determinata azienda. Potresti immaginare un negozio di Ruby che dice "assumiamo solo sviluppatori di Ruby, se intervisti in Python abbiamo meno probabilità di assumerti."

Il rovescio della medaglia, si potrebbe immaginare che una società che scrive tutto il loro codice in Python sarà molto più critica nei confronti di un intervistato in Python: conoscono i dettagli della lingua e potrebbero giudicare il candidato per aver fatto tutto una sorta di cose "non pitoniche" durante la loro intervista.

La tabella seguente è simile alla tabella che mostrava differenze nella percentuale di successo dell'intervista (misurata dagli intervistatori disposti a assumere l'intervistato) per C ++, Java e Python. Tuttavia, questo grafico mostra anche le prestazioni indipendentemente dal fatto che il linguaggio dell'intervista sia o meno nello stack dell'azienda.

Limitiamo questa analisi a C ++, Java e Python perché questi sono i tre linguaggi in cui abbiamo avuto una buona combinazione di interviste in cui la società ha fatto e non ha usato quel linguaggio. I risultati qui sono misti. Quando il linguaggio dell'intervista è Python o C ++, non esiste alcuna differenza statisticamente significativa tra le percentuali di successo delle interviste in cui il linguaggio dell'intervista è o non è una lingua nello stack dell'azienda. Tuttavia, gli intervistatori che hanno intervistato in Java hanno maggiori probabilità di avere successo quando intervistano un negozio Java (p = 0,037).

Quindi, perché la codifica nel linguaggio della società sembra essere utile quando è Java, ma non quando è Python o C ++? Una possibile spiegazione è che le comunità esistenti intorno a determinati linguaggi di programmazione (come Java) attribuiscono un valore più elevato alla precedente esperienza con il linguaggio. In questo senso, è anche possibile che gli intervistatori di aziende che usano Java abbiano maggiori probabilità di porre domande a favore di coloro che hanno una conoscenza preesistente delle idiosincrasie di Java.

Che dire del rapporto tra la lingua in cui programmi e quanto sei bravo in un comunicatore?

"Gestire abilmente una lingua è praticare una specie di magia evocativa". - Charles Baudelaire

Anche se la scelta della lingua non è molto importante per le prestazioni complessive (nonostante le aziende che utilizzano Java), eravamo curiosi di sapere se scelte linguistiche diverse hanno portato a risultati diversi in altre dimensioni dell'intervista.

Ad esempio, un linguaggio estremamente leggibile, come Python, può portare a intervistare candidati che si ritiene abbiano comunicato meglio. D'altra parte, un linguaggio di basso livello come il C ++ potrebbe portare a punteggi più alti per capacità tecnica.

Inoltre, linguaggi molto leggibili o di basso livello potrebbero portare a correlazioni tra questi due punteggi (ad esempio, forse sono candidati al colloquio in C ++ che non possono spiegare affatto quello che stanno facendo ma che scrivono codici molto efficienti). La tabella seguente suggerisce che non c'è davvero alcuna differenza osservabile tra il modo in cui le capacità tecniche e di comunicazione dei candidati sono percepite, attraverso una varietà di linguaggi di programmazione.

Inoltre, a prescindere da cosa, la scarsa capacità tecnica sembra altamente correlata con una scarsa capacità comunicativa - indipendentemente dalla lingua, è relativamente raro che i candidati si comportino bene tecnicamente ma non comunichino efficacemente ciò che stanno facendo (o viceversa), in gran parte (e fortunatamente) sfatare il mito dell'ingegnere incoerente, che parla in modo rapido e imbarazzante.

(I migliori ingegneri che ho incontrato sono stati anche leggendariamente bravi a scomporre concetti complessi e spiegarli ai laici. Perché il mito esasperante del nerd tecnologico socialmente imbarazzante e incoerente continua a esistere, non ne ho assolutamente idea.)

Durata del colloquio

"Va bene quando si eliminano le catastrofi e le recensioni e il rifiuto terribilmente cattivi e tutte quelle cose quando si è giovani; la tua resilienza è semplicemente fantastica. ”- Harold Prince

Abbiamo tutti avuto l'esperienza di lasciare un'intervista e sentirci come se fosse andata male. Spesso, quel sentimento di una certa sottoperformance è motivato da regole empiriche che abbiamo escogitato con noi stessi o ascoltato ripetutamente ancora e ancora. Potresti trovarti a pensare: "l'intervista non è durata a lungo? Questo è probabilmente un brutto segno ... "o" Ho appena scritto nulla in quella intervista! Sicuramente non lo farò. "Utilizzando i nostri dati, volevamo vedere se queste regole empiriche per la valutazione delle prestazioni del tuo colloquio avevano qualche merito.

Innanzitutto, abbiamo esaminato la durata dell'intervista. Un intervistatore più breve significa che eri un tale disastro ferroviario che l'intervistatore ha dovuto interrompere l'intervista in anticipo? O era forse il caso in cui l'intervistatore avesse meno tempo del normale, o avesse visto in poco tempo che eri un candidato fantastico? La trama seguente mostra le distribuzioni della durata del colloquio (misurate in minuti) sia per i candidati vincenti che per i non riusciti.

Un rapido sguardo a questo grafico suggerisce che non vi è alcuna differenza nella distribuzione delle lunghezze delle interviste tra interviste che vanno bene e interviste che non lo fanno - la durata media delle interviste in cui l'intervistatore voleva assumere il candidato era di 51,00 minuti, mentre la media la durata delle interviste in cui l'intervistatore non lo ha fatto è stata di 49,95 minuti. Questa differenza non è statisticamente significativa.

(Per ogni confronto delle distribuzioni in questo post, utilizziamo sia un test di permutazione di Fisher-Pitman per confrontare la differenza nei mezzi delle distribuzioni.)

Quantità di codice scritto

"La brevità è l'anima dell'ingegno." -William Shakespeare

Potresti aver vissuto un'intervista in cui eri totalmente perplesso. L'intervistatore ti pone una domanda che riesci a malapena a capire, ripeti a lui o alla sua "ricerca binaria cosa?" E praticamente non scrivi codice durante l'intervista. Potresti sperare di poter ancora passare un'intervista come questa attraverso pura intelligenza, fascino e capacità di risoluzione dei problemi di alto livello. Per valutare se ciò fosse vero, abbiamo esaminato la lunghezza del carattere finale del codice scritto dall'intervistato. La trama seguente mostra le distribuzioni della lunghezza dei caratteri sia per il successo che per il fallimento. Un rapido sguardo a questo grafico suggerisce che c'è una differenza tra i due: le interviste che non vanno bene tendono ad avere meno codice. Ci sono due fenomeni che possono contribuire a questo. In primo luogo, gli intervistatori che non hanno successo possono scrivere meno codice per cominciare. Inoltre, potrebbero essere più inclini a eliminare ampie fasce di codice che hanno scritto che non vengono eseguite o non restituiscono il risultato previsto.

In media, le interviste di successo avevano un codice di intervista finale che era lungo in media 2045 caratteri, mentre quelli senza successo erano, in media, lunghi 1760 caratteri. Questa è una grande differenza! Questa scoperta è statisticamente significativa e probabilmente non molto sorprendente.

Modularità del codice

"Il segno di un programmatore maturo è la volontà di buttare via il codice su cui hai trascorso il tempo quando ti rendi conto che è inutile". - Bram Cohen

Oltre a guardare solo quanto codice scrivi, possiamo anche pensare al tipo di codice che scrivi. La saggezza convenzionale suggerisce che i bravi programmatori non riciclano il codice, ma scrivono codice modulare che può essere riutilizzato più volte. Volevamo sapere se quel tipo di comportamento è stato effettivamente premiato durante il processo di intervista. Per fare ciò, abbiamo esaminato le interviste condotte in Python5 e abbiamo contato quante definizioni di funzioni sono apparse nella versione finale dell'intervista. Volevamo sapere se gli intervistati di successo hanno definito più funzioni - pur avendo più gestori di funzioni non è la definizione di modularità, nella nostra esperienza, ne è un segnale piuttosto forte. Come sempre, è impossibile fare forti affermazioni causali a riguardo - potrebbe accadere che alcuni intervistatori (che sono più o meno indulgenti) facciano domande di intervista che si prestano a più o meno funzioni. Tuttavia, è una tendenza interessante da indagare!

La trama seguente mostra la distribuzione del numero di funzioni Python definite sia per i candidati che l'intervistatore ha dichiarato di voler assumere sia per i candidati che l'intervistatore ha dichiarato di non assumere. Un rapido sguardo a questo grafico suggerisce che c'è una differenza nella distribuzione delle definizioni delle funzioni tra interviste che vanno bene e interviste che non lo fanno. Gli intervistati di successo sembrano definire più funzioni.

In media, i candidati di successo che intervistano in Python definiscono 3.29 funzioni, mentre i candidati senza successo definiscono 2.71 funzioni. Questa scoperta è statisticamente significativa. Il risultato qui è che gli intervistatori premiano davvero il tipo di codice che dicono di voler scrivere.

Importa se il tuo codice viene eseguito?

“Muoviti velocemente e spezza le cose. A meno che tu non stia rompendo cose, non ti stai muovendo abbastanza velocemente. ”- Mark Zuckerberg
"Lo strumento di debug più efficace è ancora un attento pensiero, unito a dichiarazioni di stampa posizionate con giudizio." - Brian Kernighan

Un ritornello comune nelle interviste tecniche è che gli intervistatori in realtà non si preoccupano se il tuo codice viene eseguito, ciò che interessa sono le capacità di risoluzione dei problemi. Dato che raccogliamo dati sulla corsa degli intervistati di codice e sulla compilazione del codice, desideriamo vedere se ci sono prove di ciò nei nostri dati. C'è qualche differenza tra la percentuale di codice che compila senza errori nelle interviste riuscite rispetto alle interviste senza successo? Inoltre, gli intervistati possono ancora essere assunti, anche se fanno tonnellate di errori di sintassi?

Per arrivare a questa domanda, abbiamo esaminato i dati. Abbiamo limitato il nostro set di dati a interviste di durata superiore a 10 minuti con l'esecuzione di oltre 5 istanze univoche di codice. Ciò ha contribuito a filtrare le interviste in cui gli intervistatori non volevano che l'intervistato eseguisse il codice o in cui l'intervista è stata interrotta per qualche motivo. Abbiamo quindi misurato la percentuale di esecuzioni di codice che ha provocato errori.5 Naturalmente, ci sono alcune limitazioni a questo approccio: ad esempio, i candidati potrebbero eseguire codice che viene compilato ma fornisce una risposta leggermente errata. Potrebbero anche ottenere la risposta giusta e scriverla a stderr! Tuttavia, questo dovrebbe darci un senso direzionale se c'è o meno una differenza.

La tabella seguente fornisce un riepilogo di questi dati. L'asse x mostra la percentuale di esecuzioni di codice prive di errori in una determinata intervista. Quindi un'intervista con 3 esecuzioni di codice e 1 messaggio di errore conterebbe per il bucket "30% -40%". L'asse y indica la percentuale di tutte le interviste che rientrano in quel bucket, sia per le interviste riuscite che per quelle non riuscite. Basta guardare la tabella qui sotto, si ha la sensazione che in media, i candidati di successo eseguano più codice che si spegne senza errori. Ma questa differenza è statisticamente significativa?

In media, il codice dei candidati prescelti è stato eseguito correttamente (non ha provocato errori) il 64% delle volte, mentre i tentativi dei candidati non riusciti di compilare il codice sono stati eseguiti con successo il 60% delle volte e questa differenza era effettivamente significativa. Ancora una volta, sebbene non possiamo presentare alcuna rivendicazione causale, la cosa principale da asporto è che i candidati di successo di solito scrivono codice che funziona meglio, nonostante ciò che gli intervistatori possono dirti all'inizio di un'intervista.

Dovresti aspettare e raccogliere i tuoi pensieri prima di scrivere il codice?

"Non dimenticare mai il potere del silenzio, quella pausa massicciamente sconcertante che va avanti e avanti e può finalmente indurre un avversario a mormorare e tornare indietro nervosamente." - Lance Morrow

Eravamo anche curiosi di sapere se gli intervistati di successo tendevano a dedicare il loro tempo all'intervista. Le domande di intervista sono spesso complesse! Dopo aver ricevuto una domanda, potrebbe esserci qualche vantaggio nel fare un passo indietro e elaborare un piano, piuttosto che saltare direttamente alle cose. Per avere un'idea del fatto che ciò fosse vero, abbiamo misurato fino a che punto in un determinato colloquio i candidati hanno eseguito il primo codice. Di seguito è riportato un istogramma che mostra fino a che punto nelle interviste sia gli intervistati di successo che quelli senza successo hanno eseguito il codice per la prima volta. Osservando rapidamente l'istogramma, puoi dire che i candidati di successo in effetti aspettano un po 'di più per iniziare a eseguire il codice, sebbene l'entità dell'effetto non sia enorme.

Più specificamente, in media, i candidati con interviste di successo eseguono per la prima volta il codice 27% dell'intervista, mentre i candidati con interviste senza successo eseguono per la prima volta il codice 23,9% dell'intervista, e questa differenza è significativa. Naturalmente, ci sono spiegazioni alternative per ciò che sta accadendo qui. Ad esempio, forse i candidati di successo sono più bravi a prendersi il tempo per parlare dolcemente del loro intervistatore. Inoltre, si applica la solita avvertenza che non possiamo fare affermazioni causali: se ti fermi in un'intervista per altri 5 minuti in completo silenzio, ciò non aiuterà le tue possibilità. Tuttavia, sembra esserci una differenza tra le due coorti.

conclusioni

Tutto sommato, questo post è stato il nostro primo tentativo di capire cosa fa e in genere non porta a un intervistatore che dice "sai cosa, mi piacerebbe davvero assumere questa persona". Poiché tutti i nostri dati sono osservativi, è difficile fare affermazioni causali su ciò che vediamo.

Mentre gli intervistati di successo possono esibire determinati comportamenti, l'adozione di tali comportamenti non garantisce il successo. Tuttavia, ci consente di supportare (o chiamare BS) molti dei consigli che leggerai su Internet su come essere un intervistato di successo.

Detto questo, c'è ancora molto da fare. Questo è stato un primo passaggio quantitativo sui nostri dati (che è, in molti modi, un tesoro di segreti per le interviste), ma siamo entusiasti di fare un tuffo più profondo e qualitativo e di iniziare effettivamente a categorizzare diverse domande per vedere quali portano il la maggior parte del segnale, oltre a mettere davvero la testa intorno a comportamenti del 2 ° ordine che non puoi misurare facilmente eseguendo una regex su un campione di codice o misurando quanto tempo ha richiesto un'intervista.

Se vuoi aiutarci con questo e sei entusiasta di ascoltare un sacco di interviste tecniche, mandami un messaggio!

Vuoi diventare fantastico durante le interviste tecniche e portare a termine il tuo prossimo lavoro? Partecipa a intervistando.io!