Qual è il modo migliore per valutare i nuovi programmatori? [chiuso]

Per quanto riguarda la selezione dei candidati, di solito vado con un piano a tre colpi:

• Test normale con FizzBuzz- come domande di codifica e molte domande di conoscenza in cui devono fornire esempi codificati. A seconda della posizione, possono essere i principi OO, i principi di progettazione SQL, ecc. Aumentare le difficoltà delle domande nel test per vedere fino a che punto possono andare. L'idea non è di avere tutte le risposte alle domande (se lo fanno, meglio è), ma anche di vedere se possono riconoscere quando non sanno qualcosa. La fiducia è essenziale, e non voglio che qualcuno mi stia mentendo nella mia squadra.

• Torna al test con il candidato e discussione attorno alle risposte. Possibile estensione delle domande per raggiungere i limiti del candidato. Questo può essere esteso e più è esteso, meglio è.

• Ultima parte ma non meno importante, La revisione del codice . Chiedo al candidato di portare un pezzo di codice (in genere spazio il precedente test / discussione e questa recensione di qualche giorno, per consentire loro di scrivere e lucidare un pezzo di codice). Quindi eseguiamo una regolare revisione del codice con due persone: una persona che lavorerà direttamente con il candidato e la persona che ha esaminato il test con il candidato in precedenza. Per quanto riguarda la revisione del codice puoi leggere questo articolo da JohnFX .

Alla fine di tutto questo, dovresti essere in grado di decidere se vuoi che questo candidato faccia parte o meno della tua squadra.

Inizia a dare loro FizzBuzz per risolvere . Questo dovrebbe eliminare il peggio di loro.

Quindi qualcosa di un po 'più difficile - per esempio, come invertire una stringa senza funzioni di libreria incorporate. Chiedi loro di parlare mentre risolvono per vedere quale sia il loro modo di pensare.

Puoi continuare a dare problemi più difficili se li trovano molto facili, finché non sei convinto di poter camminare e non parlare solo del discorso.

Cerca la passione per il lavoro.

Per citare Joel, cerca le persone che sono " Smart e ottieni risultati. "

Il resto non ha importanza

Sulla base dei miei 25 anni di programmazione (che, ammette solo 5 o 6 casi di assunzione di altri programmatori):

Indicatori positivi:

• Appassionato di tecnologia

• Programmi come hobby

• Discuterà l'orecchio su un argomento tecnico se incoraggiato

• Significativi (e spesso numerosi) progetti collaterali personali nel corso degli anni

• Impara nuove tecnologie da solo

• Intervistati su quali tecnologie sono migliori per vari utilizzi

• Molto scomodo per l'idea di lavorare con una tecnologia che non crede di essere "giusta"

• Molto intelligente, può avere ottime conversazioni su una varietà di argomenti

• Iniziata la programmazione molto prima dell'università / lavoro

• Ha alcuni "iceberg" nascosti, grandi progetti personali sotto il radar CV

• Conoscenza di una grande varietà di tecnologie non correlate (potrebbe non essere in CV)

Indicatori negativi:

• La programmazione è un lavoro giornaliero

• Non vuoi veramente parlare in "talk shop", anche se incoraggiato a

• Impara nuove tecnologie nei corsi sponsorizzati dall'azienda

• Felice di lavorare con qualsiasi tecnologia tu abbia scelto, "tutte le tecnologie sono buone"

• Non sembra troppo intelligente

• Programmazione iniziale all'università

• Tutta l'esperienza di programmazione è sul CV

• Concentrato principalmente su uno o due stack tecnologici (ad esempio, tutto ciò che riguarda lo sviluppo di un'applicazione java), senza alcuna esperienza al di fuori di esso

Inoltre, suggerirei:

• Il test FizzBuzz (o qualcosa di simile per testare la capacità di base di scrivere un algoritmo.
• Versione più dura del test FizzBuzz (per portarli al punto di errore o quasi-fallimento.)
• Discutere il loro codice e vedere se sono disposti ad essere autocritici e cercare miglioramenti (che probabilmente non hanno avuto il tempo di fare in un breve test in loco) come:
  • buoni nomi di variabili (ho avuto esperti programmatori esperti che usano variabili in produzione come "flag" (WTF ??)
  • modularizzazione.
  • Anticipare i problemi e fare "codifica difensiva"
• La volontà di vedere "difetti" come opportunità di miglioramento. Penso che i migliori programmatori guardino sempre con fermezza ai difetti del codice precedente. Non sono così egocentrici da pensare che trovarne un difetto sia un affronto personale. Lo vedono come un'opportunità per fare meglio. (Quelli che non riescono a guardare i difetti senza intoppi o sono sopraffatti vedendo un difetto (e diventano superfelici o, per evitare proprio questo, ignorano i difetti.
• Possono eseguire il debug?
• Possono testare le unità? (Ho parlato con troppi programmatori che dicono "QC fa quello." Non sto parlando di Test, sto parlando di test: scrivi una funzione, funziona? Fa sforzi ragionevoli per affrontare probabili problemi (input NULL, ecc.)? Se non puoi farlo, come fai a sapere quando hai finito?
• Hanno buone capacità di comunicazione? (come minimo: buona comprensione e conoscenza di sé su quando lo fanno e non capiscono e la volontà di dire "Non capisco, per favore, spiegamelo di nuovo".

Gran parte del riassunto sopra è tratto da Come individuare un buon programmatore , che è un ottimo articolo, focalizzato un po 'di più sugli indicatori a più lungo raggio. Conferma definitivamente le mie intuizioni ed esperienze. Sono anche un sacco di cose (come "passione") che non sono normalmente menzionate in una lista di controllo di "cosa è un buon programmatore".

La valutazione dell'intelligenza di programmazione è una forma di test di Turing. Quindi non ci sono (attualmente) procedure di valutazione della forma chiusa che siano garantite per funzionare. Ci vogliono programmatori intelligenti per riconoscere altri programmatori intelligenti, ma solo con una ragionevole probabilità.

Le tue possibilità saranno migliori se hai degli intervistatori nella tua squadra che possono sentire l'odore della neve, e istintivamente non ti piace lavorare con persone stupide (anche quelli che sono di bell'aspetto, hanno curriculum dall'aspetto impressionante e possono lanciare tutte le solite soluzioni in scatola dalla memoria).

(Una possibile metodologia che aiuterebbe la qualità dello stackoverflow come effetto collaterale è quella di scavare vecchie domande StackOverflow, legate in qualche modo alle tue esigenze lavorative ma che a tuo parere hanno risposte inferiori; chiedi all'intervistato come farebbero rispondi e invitali a postarlo se è una buona risposta. Simile a un riassunto per l'OCR di crowd-sourced.)

Offri loro un problema, preferibilmente uno associato al dominio del problema su cui lavoreranno, e chiedi loro di discutere su come affrontarlo. Puoi farli discutere, pseudo-codice o scrivere parti di codice effettivo a seconda di quanto sei sicuro nel loro livello di competenza

Ad esempio, se la tua organizzazione ha organizzato conferenze, chiedi loro di delineare in che modo codificano un sistema di registrazione online sicuro. Dovrebbero essere in grado di coprire alcune delle nozioni di base e porre delle buone domande su esattamente ciò che deve essere implementato. Mentre interagisci, dovresti essere in grado di determinare se saranno adatti alla tua organizzazione e al ruolo che ti occorrono per riempire.

Non sono un grande fan della programmazione di trivia test e rompicapo. Anche se possono essere divertenti per alcune persone, possono anche infastidire e / o stressare altre persone, incluse persone che potrebbero essere solo la soluzione migliore per la tua squadra. Inoltre, le informazioni su molti di questi test sono prontamente disponibili online e incoraggeranno il cramming per i test e altre tattiche che ne ridurranno la vitalità per valutare l'abilità del programmatore.

Leggendo questa domanda e alcune delle risposte ricevute mi ha spinto a scrivere un articolo che ritengo possa interessare:

Pratiche di reclutamento dispari durante l'assunzione di sviluppatori di software

Ok, quindi il titolo dell'articolo è spazzatura, ma l'articolo arriva al cuore del problema. Non è il problema del candidato che hai scelto di intervistarli, non importa quanto possano essere inappropriati per il ruolo che hai in mente. Se non sei riuscito a definire una procedura di assunzione ben strutturata per permetterti di trovare le gemme allo stato grezzo, allora dovrai solo convivere con le conseguenze, e sì, questo significa ottenere alcuni candidati che potrebbero mai incontrare le tue aspettative. Filtrare i candidati in base alle loro lettere e curriculum richiede prima di tutto, chiedere ai candidati di scrivere una lettera su se stessi e ciò che vogliono dal ruolo, e poi guardare come viene scritto il curriculum. Se hai solo uno o due potenziali candidati da intervistare, probabilmente hai fatto correttamente il pre-screening. Se non puoi decidere tra i tuoi candidati in questa fase e hai ancora un centinaio di domande, probabilmente hai impostato le tue aspettative troppo basse o non sei stato abbastanza aggressivo nel processo di filtro.

Quando alla fine trovi i 1 o 2 candidati che ritieni vali, non chiedere semplicemente una manciata di domande per tester, ma invece investire il tempo per conoscere queste persone e impegnarsi in un open discussioni sull'ingegneria del software in generale. Imparerai di più da un approccio casuale del candidato rispetto a quello che farai nella tradizionale situazione di colloquio (e in qualche modo contraddittorio). Inoltre, non accontentarti semplicemente di una singola intervista, ma invece di trattare i tuoi candidati chiave in diverse riunioni in cui viene utilizzata una discussione aperta e dove il candidato può incontrare i potenziali colleghi. Il tempo non viene mai sprecato, in quanto i candidati inappropriati non prospereranno molto bene in una discussione altamente tecnica, e mostreranno i loro difetti molto rapidamente mentre abbassano la guardia. Se passi il tempo e ancora non hai un noleggio, hai avuto l'opportunità di saperne di più su quali sono le tue esigenze e puoi continuare a migliorare il tuo processo di intervista in base a ciò che hai appreso dalle interviste "fallite".

Ti suggerisco di andare con una domanda di FizzBuzz e assumere il primo che passa. Ulteriori test tendono ad essere imperfetti in quanto non tutti i bravi programmatori si avvicinano a un problema come te, o gestiscono un'intervista senza balbettare, o conoscono le lingue che vuoi o ti interessano come scambiare interi senza una terza variabile (chi ne ha bisogno comunque? significa, dal momento che la RAM ha superato 128 byte?).

Pensaci. Se la domanda di FizzBuzz elimina 199 su 200, ha appena eliminato centinaia di interviste. Avresti davvero intervistato centinaia di potenziali clienti?

Sembra solo un calo dei rendimenti dopo FizzBuzz. Ciò presuppone che 199/200 sia persino approssimativamente vicino. E presumo che anche il TUO tempo sia prezioso ...

Non sono sicuro che si tratti di un commento o di una risposta, ma fondamentalmente di ciò che ha detto Matthieu. Vuoi domande stupide e semplici che richiedono un minuto o due (ma non più di 5) minuti per farlo e dovrebbero riguardare aree diverse.

Esempi di domande stupide e semplici sono una domanda sulla ricorsione come se si avesse una lista e si deve stampare in ordine inverso senza usare un ciclo. Una semplice domanda di espressione regolare se la regex viene normalmente eseguita nel tuo sviluppo. Una domanda su bit e byte se si utilizza C ++ (scrivere un modello che accetta char a long e stampa la rappresentazione binaria. La specializzazione non è richiesta, basta usare sizeof () per calcolare la lunghezza del bit)

Dovrebbe richiedere circa < = 3 minuti per domanda

Chiedete loro quali sono le sfide di programmazione più interessanti che abbiano mai provato a risolvere, ma che non hanno potuto, quale approccio hanno usato per risolverlo, perché non hanno potuto risolverlo e quale altro approccio pensano di poter risolvere.

Questo è abbastanza per me per giudicare le capacità di un programmatore come programmatore.

1. Possono difendere ciò che affermano di sapere? Lo hanno inserito nel CV / curriculum come abilità o qualcosa che hanno fatto su un altro progetto. Guarda come in profondità possono andare sull'argomento.

2. Possono imparare qualcosa di nuovo? Parla di un aspetto di alto livello della tecnologia che stai utilizzando o di qualcosa di specifico per la domian aziendale in cui lavori e vedi se riescono a cogliere l'argomento. Fanno domande intelligenti? Possono fare un'analogia? È simile a qualcosa che hanno fatto in un'altra industria o tecnologia?

3. Preferirebbero programmare? Non deve essere il numero uno nella loro lista, ma devono mostrare una preferenza per scrivere il codice. E intendo in realtà scrivere codice e fare qualcosa, non sedermi intorno e parlarne o disegnare sulla lavagna tutto il giorno. Non minimizzare la pianificazione o promuovere la codifica dei cowboy, ma alla fine devi avere il codice. Evita quelli che evitano la tastiera. Questa non è una posizione di gestione.

Puoi fare un punteggio su una scala da una a dieci cose o semplicemente fare affidamento sul fatto di poter odorare i tuoi simili.

Se ti fa sentire meglio i programmatori cattivi esistono praticamente in ogni paese. Come eliminarli è il problema.

La prima diserbo è il curriculum. Una cosa che cerco è l'esperienza linguistica rivendicata e nulla per descrivere ciò che hanno fatto in quella lingua. Ho visto i curriculum che sostengono praticamente che conoscono ogni lingua mai inventata e tuttavia la loro esperienza mostra che hanno lavorato solo con Access e Visual Basic. Quelli vanno proprio nella spazzatura. I curriculum di 10 pagine vanno nella spazzatura (in particolare dieci pagine riprendono da persone con meno di 2 anni di esperienza che ho ottenuto). Dai recenti laureati con poca esperienza, devi essere davvero pignolo su come si presentano. I migliori candidati sono attenti con i loro curriculum, non hanno errori. Stai davvero cercando qualcuno a cui importa così poco che non si sia preso la briga di correggere il suo curriculum?

Anche i curriculum preparati professionalmente vanno nella spazzatura. Una volta che hai letto centinaia di curriculum, puoi selezionarli mentre usano lo stesso identico fraseggio. Non puoi fidarti del contenuto in un curriculum preparato professionalmente e sai che la persona non ha fatto la propria preparazione. Questo è il tipo di persona che si affida agli altri per risolvere i suoi problemi per lui, lo vuoi davvero in una posizione di programmazione?

Cerca le cose che fanno risaltare la persona per quelle che scegli. È più difficile ovviamente con quelli appena usciti dalla scuola, ma cerca risultati, contributi all'open source, ecc.

Il prossimo estirpare è l'intervista telefonica. Chiedete dei concetti di base che riguardano il lavoro reale che avete. Se le persone non hanno una conoscenza di base dei concetti di cui hanno bisogno, non valgono la pena di prendere in considerazione un colloquio personale. I giovani spesso pensano che questo sia ingiusto perché possono cercare tutto su Internet, ma la verità è che non ho mai incontrato un buon programmatore che ha dovuto cercare tutto su Internet. Dovresti avere una certa conoscenza della tua professione che non devi cercare ogni volta.

Dopo l'intervista telefonica dovresti scegliere i migliori 4-5 candidati e intervistare. Naturalmente se hai solo 1-2 buoni candidati, non preoccuparti di intervistare persone che hai già eliminato. Ora stai per fare le domande difficili e avere un'idea di come affrontano i problemi. Non userei mai il test fizzbuzz perché è troppo conosciuto e le risposte non ti dicono nulla. Risolvete invece alcuni problemi dal vostro codice base. Potrei dare loro un requisito e un pezzo di codice e chiedere loro se il codice soddisfa i requisiti e se no perché no e cosa potrebbero fare per soddisfare il requisito. Vorrei chiedere loro di descrivere il problema di programmazione più difficile che hanno dovuto risolvere e quali misure hanno preso per trovare la risposta. Vorrei porre alcune domande tecniche più approfondite. Ricorda che stai cercando di farti un'idea della loro competenza tecnica, della loro capacità di risolvere problemi e debugging e della loro capacità di adattarsi al tuo team esistente. Faccio anche domande che probabilmente non conoscono la risposta per giudicare quanto bene gestiscono lo stress, è un lavoro stressante, non voglio qualcuno che si piega nell'intervista perché lo stress del lavoro è maggiore dello stress dell'intervista . Cerco punti di forza nelle aree in cui attualmente siamo deboli e la capacità di lavorare in team e di presentarsi ai clienti (i nostri sviluppatori si occupano ampiamente degli utenti), l'elenco potrebbe essere diverso.

Ai candidati deve essere dato un problema del mondo reale da risolvere con la libertà di utilizzare qualsiasi tecnologia.

Se esce a pieni voti, lei è In!