La domanda n. 11 del test Joel è: "I nuovi candidati scrivono codice durante il colloquio?". Quali sono gli argomenti a favore e contro per chiedere ai nuovi candidati di scrivere codice durante il colloquio e di prendere una decisione in merito?
Risposte:
Non vedo i contro. Un'intervista ha molte parti e un candidato dovrebbe essere sostenuto "in cima alla catena" alcune volte.
Intervisto ~ 10 persone a settimana. Apprezzo davvero moltissimo il fatto che le risorse umane abbiano svolto tutto il lavoro di base e mi abbiano presentato molte note. Quando arrivano da me, è ora che io valuti i loro test.
I test dipendono interamente dalla posizione. In generale, provo a sondare:
Abilità di programmazione generale. Puoi usare gli operatori in modo efficace? Riesci a concepire un sistema numerico che ha una radice che non è 10?
Sai come fare quello che ti stiamo assumendo per fare?
Valutazione dei tuoi contributi a tutti i progetti open source che hai elencato
Cerco di mantenerlo breve e divertente. Quando entro in ufficio, afferro le risposte, le guardo e conduco un colloquio secondario. Per essere assunto, in genere devi superare tre interviste.
Misuro anche quanto bene ti unirai alla squadra che ti riceverà. Quella squadra conta su di me per farlo efficacemente.
Una cosa è rispondere alle domande in forma meta, un'altra è effettivamente produrre codice. Se ho intenzione di assumerti, ho davvero bisogno di vederti produrre codice.
Con scuse a Scott Whitlock:
Contro:
Professionisti:
Se avessi assunto un giocoliere, saresti pazzo a non farlo fare da giocoliere per te. O un musicista avresti avuto un provino. Altrimenti ottieni cose come il fantastico "maestro" yo-yo "maestro" .
Camminare attraverso qualcosa su una lavagna è l'equivalente dei programmatori di una giocoleria demo veloce.
Penso che sia super utile, e lo faccio sempre, ma dal momento che i benefici sono stati coperti così bene parlerò solo degli aspetti negativi (apparenti).
Penso che sia improbabile che i test del codice ti diano falsi positivi: le probabilità sono basse che qualcuno che non è in grado di scrivere codice riuscirà a falsarlo in un'intervista, almeno se hai una scala di domande di crescente difficoltà. (Forse lo scenario più probabile è che imbrogliano chiedendo a un amico, se non è un'intervista faccia a faccia.)
I problemi sono più sul lato falso negativo: i test del codice ti porteranno a rifiutare la persona che è in realtà il miglior candidato?
Paura del palcoscenico
Potresti avere qualcuno che è davvero uno sviluppatore davvero bravo, ma che è molto nervoso per questa intervista e hanno essenzialmente paura del palcoscenico. Esibirsi sotto pressione è importante in una certa misura, ma affrontare la paura del palcoscenico non è una parte fondamentale dell'essere un programmatore (rispetto ad altre professioni), e sarebbe sfortunato rifiutare qualcuno che ne soffre gravemente. Questo può aggravarsi: se la persona non è in grado di rispondere a una domanda a cui sa che dovrebbe rispondere, potrebbe alzarsi di più. Oppure, come in questa domanda , sentono di non poter parlare e programmare contemporaneamente.
mitigazione: inizia con alcune domande per conoscerti sul loro background, obiettivi, ecc., prima di passare alle domande tecniche. Forse inizia con alcune domande tecniche più semplici in modo da ottenere un po 'di slancio. Non fare il coglione durante l'intervista (cavilli su punti e virgola ecc.).
È una misura rumorosa
Interessanti domande sul codice potrebbero avere più di una risposta corretta. Se una persona scrive una risposta corretta e un'altra scrive una risposta corretta e più efficiente, quanto peso dovresti mettere su quella?
In una certa misura questo è come il problema con alcune domande "enigmistiche": la persona o ha l'intuizione o no e si ottiene un risultato quasi binario. L'intelligenza probabilmente influenza la probabilità di avere quella intuizione, ma campionare solo poche volte ti dà una misura approssimativa.
Questo mi dà fastidio riguardo alle domande sul codice (anche se le uso ancora.) La migliore soluzione che mi viene in mente è di avere il più possibile una rampa di possibili soluzioni: la persona può almeno scrivere una risposta di forza bruta grezza o una risposta per una parte del problema. Capire che è meglio di niente è un buon segno. Quindi, se ne scoprono di più, possono renderlo più efficiente o più elegante. Per quanto possibile, evitare di porre domande che ottengano risposte binarie.
Non è davvero rappresentativo
La programmazione non è un lavoro per risolvere i problemi algoritmici di dieci minuti uno dopo l'altro: c'è molto più lavoro sulla comprensione e la progettazione di sistemi più grandi e la concentrazione per lunghi periodi di tempo, per non parlare delle capacità interpersonali. Le domande sul codice non lo verificano davvero.
Ma le domande sul codice non sono le uniche domande che farai: puoi vedere il loro background, i loro riferimenti, il loro lavoro open source (se presente), per trovare prove di uno sforzo prolungato, creatività, abilità interpersonali.
Sapere come risolvere piccoli problemi algoritmici e come ridurli a codice è una condizione necessaria ma non sufficiente: se non puoi risolvere piccoli problemi e non puoi scrivere codice non banale, allora tutto il pensiero generale nel mondo non lo è ti renderà uno sviluppatore produttivo.
Chiunque potrebbe risolverlo
No, apparentemente no. Come sottolinea il famoso post di FizzBuzz , i problemi che potresti pensare sono banali trappole non solo di neolaureati, ma di persone con anni di esperienza nel settore. Non so perché. O il test del codice è una misura scadente (il che è possibile, anche se penso sia improbabile), o non stavano contribuendo molto ai progetti sul loro curriculum, o stavano facendo molto facendo copiando e incollando non- codice algoritmico (che è possibile.)
Vale la pena riconoscere che puoi davvero fare molto senza scrivere alcun codice algoritmico. Le persone fanno molti soldi con le app il cui valore è nella grafica o nella logica aziendale non in quella che potresti chiamare "programmazione", e va bene. Ma, se in realtà hai bisogno di programmatori, non è adatto.
Potrebbe non essere ben calibrato
Se ti viene in mente una domanda, la risposta potrebbe sembrarti molto semplice. Tuttavia, se ti viene posta una domanda altrimenti comparabile di punto in bianco o una domanda che non è distorta rispetto ai tuoi interessi e al tuo background particolare, potrebbe essere molto più difficile.
mitigazione: esegui i test su alcuni sviluppatori che già conosci e vedi come lo fanno. Forse qualcuno già nella tua squadra, che sai essere molto intelligente, avrà problemi con uno di loro e puoi prendere in considerazione la possibilità di adattarlo. Forse penseranno a una risposta migliore o diversa.
È troppo simile a curiosità
Penso che le domande sul codice possano certamente entrare in curiosità, se insisti che le persone conoscano a memoria le API oscure a memoria, o ottengano la sintassi perfetta o ricordi l'esatta definizione di un algoritmo non banale. Sono tutti ragionevoli fare affidamento su documenti, ricerche Web o errori del compilatore per raccogliere e avere poca correlazione con la vera esperienza. Non sapere nemmeno dove sia probabile che sia l'API è forse un indizio che la persona non ha usato di recente, ma questo non è necessariamente un problema se non stanno mentendo sul loro curriculum.
Quindi la risposta a questa domanda è piuttosto semplice: non porre domande banali e non rimanere bloccati su errori banali. Ricordare al candidato come si chiama l'API o lasciarlo cercare; correggere errori di sintassi; non testare le persone che memorizzano le definizioni della struttura dei dati.
Come si confronta?
Se hai due candidati ed entrambi rispondi bene alle domande, come scegli tra di loro? Potresti scegliere quello che ha finito più velocemente, ma forse lì inizi a raccogliere lepri sopra le tartarughe. Potresti fare un altro giro e porre domande molto più difficili, ma non ne sono nemmeno sicuro. Forse dai a entrambi un A + e provi a scegliere tra loro su altri criteri (o prova a trovare i soldi per assumerli entrambi).
Una cosa che mi viene in mente è che è difficile "codificare ad alta voce" di fronte ad altre persone. Trovo difficile persino scrivere con qualcuno che mi guarda alle spalle e non sono solo. Ho notato che quando qualcuno mi chiama alla sua postazione di lavoro per aiutare con qualcosa, improvvisamente iniziano a fare errori di battitura, selezionando il codice errato di completamento, persino facendo errori assolutamente - nessuno dei quali avrebbero fatto se non fossi stato seduto lì. Diavolo, ho visto le persone iniziare a usare il menu per le operazioni taglia e incolla, solo perché erano sotto osservazione. Questo non è un comportamento normale e i programmatori di cui sto parlando sono programmatori eccellenti e abbastanza intelligenti.
Di recente ho avuto un'intervista in cui l'intervistatore mi ha chiesto come avrei programmato una determinata operazione e mi ha detto: "Fammi vedere la matematica". Beh, ho dovuto pensare al problema prima di arrivare alla matematica, quindi mi ha fatto orlare e sgridare. Quello che ho messo sulla lavagna all'inizio è stato imbarazzante, e ho sentito che stavo perdendo a quel punto. Alla fine ho avuto il momento A-ha e ho trovato la risposta (in realtà quando finalmente mi è venuto in mente quello che mi stava davvero chiedendo), ma il "disordine" che ho fatto prima di arrivare lì mi ha fatto sentire molto a disagio. Tuttavia, ho ottenuto il lavoro, ma se l'intervistatore fosse stato meno paziente, non avrei potuto.
Penso che se dai agli intervistati un compito di codifica, dai loro un po 'di tempo da solo per elaborarlo su un computer, forse anche in un IDE con cui hanno familiarità. Lascia che scrivano il codice per te e poi parlane. Chiedi loro perché hanno fatto le cose in un certo modo e se un altro modo potrebbe non essere migliore. Scoprirai di più da quel tipo di processo piuttosto che chiedendo loro di (in senso figurato) fare pipì in una tazza proprio di fronte a te.
Contro: nessuno. Ogni volta che impieghi a configurare un PC, a progettare un test del codice e a rivederlo, in futuro si risparmierà un indicibile mal di testa.
Pro: "Fidati, ma verifica" - Ronald Regan. Quante volte ho visto e sentito parlare di persone che alla fine lasciavano andare una posizione, dove nell'intervista pensavi di ottenere una rock star. La prova è nel budino; Voglio vedere cosa possono fare. Rappresenterà ciò che accade una volta investito tempo e denaro assumendo qualcuno e attaccando un nuovo progetto di fronte a loro.
Contro:
Professionisti:
Quando ho intervistato per il mio attuale lavoro, mi è stato dato un elenco di domande per cui scrivere il codice per il reclutatore. Sono rimasto molto colpito perché le domande sono state ovviamente scritte da qualcuno che aveva una profonda conoscenza di SQL, quindi funziona in entrambi i modi.
Vuoi davvero che la persona scriva il codice nell'intervista - ancora meglio, fai in modo che accoppi il programma con un membro del tuo team per X tempo (qualunque cosa tu possa permetterti comodamente in tempo / manodopera).
È praticamente uno degli unici modi in cui puoi dire se quella persona può programmare o no.
Preferisco leggermente la programmazione della coppia in quanto mostrerà il loro lavoro di gruppo, darà loro un IDE reale con cui lavorare e li permetterà di lavorare su un problema "reale" (l'altra persona nella coppia può guidarli oltre le specifiche ambientali che l'intervistato non potrei mai ragionevolmente saperlo).
Abbiamo iniziato a utilizzare questa politica di assunzione e siamo davvero soddisfatti dei risultati.
Giudichi un uccello dalle sue piume e un programmatore dal suo codice.
Quando ho iniziato con l'attuale compagnia per cui sto lavorando, mi hanno chiesto di scrivere del codice C che genera o controlla il bit di parità di alcuni input binari (a seconda che tu stia codificando o decodificando). Questa è stata una domanda di intervista proprio perché questi tipi di problemi vengono risolti durante il lavoro. Ovviamente sto pensando di non controllare la parità ma piuttosto di lavorare a un livello basso.
Tutte le risposte finora (che ho letto) non hanno affrontato il fatto che il Joel Test NON è (solo) un elenco delle migliori pratiche per gli imprenditori ma un elenco di controllo per facilitare la valutazione di un potenziale datore di lavoro .
Il fatto è ... se testano a fondo i loro candidati, probabilmente assumono persone che conoscono le loro cose ... questo significa per te
invece di correggere i bug dopo di loro ...
Direi:
Professionisti
Contro
Reversemetodo incorporato o simile, o per prove scritte cose come" Quali sono gli argomenti al Foometodo della Barclasse ", quando qualsiasi idiota potrebbe Google che utilizza o la documentazione) al contrario di domande di architettura / design che mostrano il candidato può fare le cose e risolvere i problemi aziendali .Un pro è che mostra che qualcuno ha una conoscenza di base della programmazione o altro (l'ultima volta che l'ho incontrato, sono rimasto sorpreso da quanto fosse basilare la domanda SQL). Può anche servire come base per una discussione tecnica, chiedendo perché il candidato ha fatto questo e così, e come potrebbe essere migliorato.
L'intervista richiede tempo, che potrebbe essere utilizzata per altre cose. Inoltre, scrivere codice su una lavagna non è un ambiente naturale e alcune persone avranno problemi sempre più gravi. Potrebbe farti perdere uno sviluppatore che si innervosisce senza normali strumenti o riferimenti.
La programmazione è un'abilità altamente tecnica con una serie di chiari "risultati". O un candidato può o non può consegnarli. Quindi non ci sono "svantaggi" nel porre domande tecniche. È interamente per dire "mostrami un po 'di codice per questa applicazione o" mostrami il codice per un'applicazione che hai GIÀ scritto ".
NON farlo potrebbe portare a un risultato simile al seguente: Un uomo ricco ha intervistato un tutor per insegnare ai suoi figli a giocare a scacchi (come un esercizio di espansione della mente). Il tutor aprì una scacchiera e iniziò a parlare dei 64 quadrati ma non toccò un pezzo di scacchi. Premuto per il tempo, il padre assunse comunque il tutor. E il tutor ha insegnato ai bambini a giocare a CHECKERS.