Colloquio tecnico e capacità del programmatore [chiuso]

Quello che dirò potrebbe essere un po 'controverso in natura, ma oggi sono molto scoraggiato - e quindi lo chiederò.

Ho appena avuto un colloquio con una grande azienda tecnologica per una posizione di tirocinio, dove mi sono state poste molte domande di intervista orientate all'algoritmo. Ora, dato il mio background, mi considero forte negli algoritmi (ho anche ottenuto buoni voti negli algoritmi di livello laureato - roba che comprende completezza NP e oltre (algoritmi di approssimazione e randomizzati), ma sfortunatamente ho bocciato l'intervista. penso a un metodo molto efficace per risolvere un problema con le stringhe in circa ~ 10 minuti. Una volta terminato il colloquio, ho bevuto un bicchiere d'acqua, ho mangiato una banana e mi sono rilassato per un po 'e ho provato di nuovo il problema. E vola! risposta, potrei arrivare in meno di 5 minuti. E la cosa peggiore è che in realtà ero su quella pista e l'intervistatore mi ha accennato, ma troppa pressione mi ha provocato. Tutta la mia esperienza mi ha fatto pensare alle interviste tecnologiche. Ho avuto alcune domande e volevo porle in questo forum -

1. È davvero possibile giudicare l'abilità tecnica di qualcuno in mezz'ora? Onestamente? O è solo un tiro di dadi?

2. Le domande di intervista tecnica misurano la capacità di problem solving? Questo punto è molto discutibile? Come studente di dottorato so che il problem solving matematico comporta la risoluzione di qualcosa di cui non hai mai sentito parlare prima. D'altra parte, domande come: unire due elenchi collegati in ordine ordinato o stampare tutti gli elementi di un albero binario al livello kth diventano "semplici esercizi" una volta che qualcuno ha visto la soluzione o risolto il problema in anticipo?

3. Le persone che escono a pieni voti in questa intervista diventano grandi programmatori? Continuano e progettano motori di gioco eleganti, librerie grafiche, scrivono framework fork-join veloci? Esistono prove per indicare una correlazione positiva tra il fare bene nelle interviste tecniche e l'effettiva capacità di programmazione? O queste interviste sono più orientate alla ricerca del tipo di persona "fare le cose" (Spolsky)?

Posso scommettere che molti accademici che pubblicano idee rivoluzionarie in - ICML, VLDB, Mobicom - respingeranno queste interviste. Ma posso assicurarti che sono alcune delle persone più intelligenti che troverai su questo pianeta.

Sono principalmente nel mondo accademico (studente universitario) - quindi apprezzerò molto alcuni percettivi da qualcuno dall'altra parte della recinzione. Qualcuno che effettivamente conduce queste interviste?

[Ok a tutti. Grazie per tutte le risposte gentili e ponderate. Dal momento che non voglio fare un'altra domanda, ti chiederò di rispondere a questa domanda per me.

Supponiamo che il candidato X abbia un buon portafoglio pubblico di lavori in cui ha contribuito ad alcuni noti progetti open source in cui - puoi effettivamente andare a verificare le sue patch, verificare i bug che ha chiuso e dare un'occhiata ai progetti che ha creato. In tal caso, la domanda è: quanto peso sei disposto a dare al suo lavoro pubblicamente disponibile / verificabile rispetto a quanto riesce a rispondere a una domanda di intervista sull'albero binario molto ingegnosa in meno di 15 minuti?]

Tieni presente che...

1. L'obiettivo principale di un processo di intervista non è quello di arrivare alla verità assoluta sull'abilità personale di ciascun intervistato, ma di selezionare pochi candidati da un pool di molti.
2. È MOLTO, MOLTO più costoso assumere un cattivo sviluppatore che non passarne uno buono.

Quindi molte volte durante l'intervista, vengono prese scorciatoie imperfette (come i quiz tecnici) perché, come hai detto, non esiste un processo perfetto per essere in grado di giudicare una persona in 30 minuti. Ma dal momento che la maggior parte non ha il lusso di lavorare fianco a fianco, dovresti semplicemente accettare che è quello che è, un gioco di probabilità a cui tutti giocano.

È davvero possibile giudicare l'abilità tecnica di qualcuno in mezz'ora?

Non esattamente. È possibile eliminare le persone che non possono programmare affatto e quelle che non possono spiegare le cose nel loro CV. Oltre a ciò, di solito sto solo cercando di valutare l'intelligenza generale e l'interesse per il campo. È difficile commentare ulteriormente la tua situazione senza conoscere il problema che ti è stato chiesto di risolvere.

Le domande di intervista tecnica misurano la capacità di problem solving?

Questo non è l'obiettivo delle mie domande tecniche. Invece sto cercando di scoprire se il candidato ha una comprensione dei fondamenti dell'informatica. Per valutare la capacità di risoluzione dei problemi, chiedo a un candidato di parlare di un problema interessante a cui hanno lavorato.

Le persone che escono a pieni voti in questa intervista diventano grandi programmatori? O queste interviste sono più orientate alla ricerca del tipo di persona "fare le cose" (Spolsky)?

Questo è tutto. La grandezza è rara. Sono felice di trovare qualcuno competente.

1. Sì. Sì, onestamente. Questo non vuol dire che 30 minuti sono sufficienti per avere un quadro completo di ciò di cui una persona è capace. Il lavoro dell'intervistatore è quello di fare del proprio meglio per farsi un'idea di chi è l'intervistato e di cosa può fare. Trovare persone che mettono qualcosa nel loro curriculum che non sapevano davvero è semplice. Scoprire esattamente cosa può fare l'intervistato, comprese tutte le sue capacità e punti di forza.

2. Sì. Ti fanno vedere come pensa l'intervistato. Ottenere la risposta corretta non è sempre necessario. Vedere qualcuno affrontare un problema con cui ha difficoltà è altrettanto utile che vedere qualcuno rispondere correttamente a un problema senza troppi problemi. Faccio sempre una domanda a cui penso che l'intervistato potrebbe non essere in grado di rispondere.

3. Non conosco alcuna prova empirica che dica che le interviste tecniche trovano i migliori candidati, ma è la cosa migliore che abbia mai provato. Persone diverse sono brave in cose diverse e ottenere risposte tecniche corrette non è l'unica cosa che decide se qualcuno viene assunto. Anche essere una buona scelta per l'azienda è molto importante.

Sulla base della tua domanda, penso che la cosa più importante che devi capire è che i giorni di feedback chiaramente definiti come un voto in lettere sono finiti. Ottenere la risposta giusta è solo una parte del risultato. Scrivere un buon codice, comunicare le tue idee e ascoltare gli altri è altrettanto importante. Tuttavia, queste aree sono più soggettive e devono essere trattate come tali.

Proprio come hai risolto il problema, fai un passo indietro e schiarisci la testa. Molto va in un'intervista e l'intervistatore sa che non è un sistema perfetto. Stanno cercando di fare il meglio che possono per l'azienda, proprio come tu stai cercando di fare il meglio per te.

In mezz'ora puoi giudicare l'abilità tecnica di una persona almeno pari a x. Cioè, la loro abilità potrebbe essere superiore a quanto hanno dimostrato, ma puoi essere abbastanza sicuro che non sia peggio. Se x è superiore alle tue esigenze, le assumi. Sì, è ingiusto se dimostri sotto le tue reali capacità. Tutto quello che posso dire è migliorare a dimostrazione.

Se qualcuno scuotesse una risposta praticamente memorizzata, darei loro un problema più difficile. In ambito accademico la memorizzazione è un'abilità importante. In un lavoro, è in gran parte ridondante quando hai Google proprio lì.

Vedendo come vengono impiegati i più grandi programmatori, è sicuro supporre che ad un certo punto abbiano superato un colloquio di lavoro. No, non puoi dire se qualcuno sarà un grande programmatore da un'intervista di mezz'ora. Fortunatamente, la maggior parte delle aziende non ha bisogno di programmatori eccezionali. Vanno d'accordo con programmatori solidi e affidabili che non hanno paura di affrontare compiti appena fuori dalla loro zona di comfort.

Il motivo per cui i pensatori rivoluzionari potrebbero rifiutare le interviste di lavoro è che le opportunità di risolvere problemi appariscenti e pionieristici sono molto rare, e ti fiderai di risolverli solo dopo aver dimostrato di poter risolvere i problemi banali, ma difficili dei tuoi colleghi impossibile, come il motivo per cui il software si arresta in modo anomalo quando supera il 16% di carico.

Pochissime persone sanno se le loro tecniche di intervista funzionano davvero, perché non imparano mai di più su coloro che hanno fallito. Ma quando nulla smentisce la loro ipotesi, la prendono come conferma che sono vere. Quindi c'è un elemento preciso nel lanciare i dadi.

Se le teorie economiche che affermano che i mercati sono razionali ed efficienti fossero vere, allora le aziende cercherebbero di assumere persone che erano cattive durante un colloquio in modo da non renderle cattive nel loro lavoro. Quindi qualcuno che indossava una tuta inadatta, sudava, sembrava molto nervoso e aveva problemi a fare problemi tecnici sotto la pressione di un'intervista - se c'erano prove esterne avrebbero potuto altrimenti fare problemi tecnici e le pressioni del lavoro non erano come quelle di un'intervista (come generalmente non lo sono) - rappresenterebbe la migliore possibilità per un'azienda di ottenere un candidato migliore di quello che altrimenti potrebbe attrarre e agirebbe di conseguenza. (Pensa a Money-ball per il mondo aziendale). Alla fine i pregiudizi dell'intervista svanirebbero.

In pratica questo va contro la natura umana. Agli intervistatori piacciono gli estroversi fiduciosi, indipendentemente dalla posizione, e anche se l'intervista tecnica fornisce informazioni peggiori rispetto al curriculum e ai riferimenti (come forse è vero nel tuo caso), ne terranno conto.

Per quanto riguarda le tue domande:

1. Un po '. I test hanno un rapporto segnale / rumore scarso ma possono essere regolati per eliminare completamente il non qualificato a scapito delle interviste qualificate ma non valide in occasione di colloqui tecnici.

2. Vedi # 1. Parte del rumore deriva dalla variazione nel fatto che le persone abbiano già visto il problema in precedenza.

3. Vedi # 1. C'è probabilmente una minuscola correlazione positiva tra questi test e diventare un grande programmatore.

Il mio consiglio: studia alcune domande tecniche di esempio per acquisire familiarità di base. Ricorda che è un po 'un tiro di dadi, quindi durante l'intervista cerca di essere fiducioso. Se riesci a spiegare cosa stai pensando senza distrarti dal pensare veramente, allora fallo. Se sta davvero andando male, ammetti di essere nervoso durante le interviste e di far loro sapere che sembra qualcosa che normalmente non avresti avuto problemi - forse dando un esempio di un problema simile ma più difficile che hai risolto.