Come riconoscere un buon programmatore? [chiuso]

La nostra azienda è alla ricerca di nuovi programmatori. E qui arriva il problema: ci sono molti sviluppatori che sembrano davvero fantastici durante l'intervista, sembrano conoscere la tecnologia di cui hai bisogno e avere un buon background lavorativo, ma dopo due mesi di lavoro, scopri che non sono in grado di lavorare una squadra, scrivere un po 'di codice impiega molto tempo e, inoltre, il risultato non è buono come dovrebbe essere.

Quindi usi qualche test formalizzato (ce ne sono?)? Come riconosci un buon programmatore e una brava persona? Ci sono delle semplici domande "buone" che potrebbero rivelare i problemi futuri? ... o si tratta solo del tuo "sentimento" per la persona (cioè, principalmente della tua esperienza), e di provarlo?

Modifica: secondo la risposta di Manoj, ecco la domanda relativa all'attività di codifica durante il colloquio di lavoro.

Invitali a parlare di ciò a cui sono interessati. Devo ancora incontrare uno sviluppatore che è veramente appassionato quando parla di programmazione ma non riesce a programmare. Potrebbero anche esistere, ovviamente - e anche il tuo colloquio dovrebbe verificare la competenza - ma la passione è un buon indicatore della mia esperienza. (Nota che non è lo stesso di essere in grado di "parlare" in termini di parole d'ordine.)

Chiedi loro cosa non gli piace della loro lingua o piattaforma preferita. Come avrebbero sistemato le cose? Cosa vorrebbero vedere nella prossima versione? Hanno progetti di hobby? Se hanno un blog, leggilo. Controlla la loro presenza online generale.

Assumere brave persone è difficile .

Mi ci sono voluti alcuni errori reali per migliorare. Inizi a fidarti del tuo tratto intestinale molto di più dopo le prime due volte in cui non ti fidi di te e te ne pentirai.

Ho un grande rispetto per le domande sullo schermo del telefono di Steve Yegge e l'ho usato come base per intervistare le persone con un certo successo.
Penso anche che sono diventato più bravo a intervistare le persone dopo aver letto la guida di Joel alle interviste con la guerriglia (ora alla versione 3.0, che è in anticipo rispetto alla versione per il web e tutto, deve solo essere buono).

Ci sono anche altre 57 domande (al 20/11/2008) sull'ingegneria del software Stackexchange taggate con l'intervista e alcune sembrano molto rilevanti, quindi dai un'occhiata a quelle.

Qualche idea:

• Poni diverse domande aperte da diverse angolazioni:

  • Rivedi un po 'di codice. Cosa è stato identificato? Errori tecnici, incoerenze di stile, commenti, algoritmi, manutenibilità, ecc ...
  • Scrivi del codice. Cerca processi, prove antiproiettile, leggibilità, ecc.
  • Crea un design di alto livello per un piccolo sistema. Cerca la comprensione del problema, l'approccio, le comunicazioni, la completezza, i dettagli.
  • Descrivere il processo di sviluppo del software. Cerca design, collaborazione, revisione, test, buone / cattive abitudini ed esperienza complessiva.

• Scegli qualcosa, qualsiasi cosa, il candidato afferma di conoscere bene. Poni una domanda semplice e poi, in base alla risposta, fai un'altra, leggermente più dettagliata, e continua a "scavare" fino a raggiungere il limite delle conoscenze del candidato. Questo ti dà un'idea di:

  • Onestà: sa quanto sostiene?
  • Profondità della conoscenza: quanto impara le cose?
  • Comunicazione: quanto ti spiega qualcosa che non ti è familiare? Il processo di pensiero è logico?
  • Reazione a situazioni stressanti: quanto è difficile lavorare per rispondere? Lo finge? L'inevitabile "Non lo so" è facile o difficile?

• Chiedi in che modo il candidato ha affrontato varie situazioni e precedenti lavori: lavoro di squadra, progetti scaduti, debug, ecc . Le risposte sono positive o negative? Appassionato? Intelligente? Arrogante?

Trovo che i migliori candidati siano entusiasti, esperti, sicuri ma educati e, soprattutto, presenti . Devi sapere che c'è qualcuno dentro. :-)

Per riconoscere un buon programmatore, devi essere un buon programmatore. Ciò significa che devi conoscere molto bene la programmazione per vedere tutto ciò che viene detto e fatto nell'intervista e devi sapere quali domande porre.

Ho visto i candidati dare la risposta sbagliata durante il colloquio, ma la loro spiegazione ha dimostrato che conoscevano l'argomento (e quindi potevano facilmente ottenere la risposta giusta cercando in rete). Per vederlo, devi conoscere molto bene l'argomento di cui stai ponendo la domanda.

Un'altra cosa è evitare domande sui dettagli che potrebbero essere facilmente cercate su Google. Quella domanda mostra solo quanto è bravo il candidato a ricordare le cose, non se lui o lei hanno davvero le conoscenze e la comprensione che stai cercando.

La mia raccomandazione è quella di ottenere aiuto da qualcuno che conosce molto la programmazione e ha buone capacità di persone, per dare una mano con le interviste.

Modifica: ho anche scritto un commento sulle interviste qui .

Ricorda che l'abilità di programmazione non è tutto. Potresti avere il miglior programmatore al mondo che lavora per te, ma se odiano lavorare con altre persone non le troverai molto utili.

La personalità di un programmatore dovrebbe essere in cima alla lista di quanto la maggior parte dei datori di lavoro sembra classificarla. Nel mio attuale posto di lavoro sono molto attenti ad assumere il tipo corretto di persona.

Le persone in genere possono imparare ad essere migliori programmatori, in genere le persone non possono imparare ad essere migliori esseri umani.

Renderli in codice. Dare un problema che può essere risolto in 4 o 5 ore e ispezionare il codice per la documentazione, lo stile di codifica, come ha pianificato la soluzione prima di iniziare effettivamente a codificare ecc. Non è necessario che sia effettivamente necessario risolvere il problema. E come menzionato da Jon Skeet, fagli parlare della programmazione, del loro linguaggio di scelta e cose del genere. Puoi riconoscere la passione in un buon programmatore. Chiedi quanti siti di programmazione seguono come stackoverflow. I blog che seguono possono anche essere un buon indicatore.

Mi piace la risposta della passione. Credo che devi essere appassionato di ciò con cui lavori per essere davvero bravo in questo.

Un buon programmatore programma sul lato oltre al lavoro (almeno una volta ogni tanto). Gli piace risolvere i problemi di programmazione. E quando non riesce a trovare un programma che risolva un particolare bisogno a casa, in genere cerca di risolverlo da solo.

Ma ci sono diversi tipi di programmatori.

• Hai quelli che amano documentare. Personalmente odio documentare. Ma documentare ciò che viene fatto può essere importante.
• Hai gli "hacker". Quelli che sono decisi a risolvere un puzzle complesso in cui se dovessi cercare Google, probabilmente non troverebbero una soluzione. Possono risolvere "qualsiasi" problema purché abbiano gli strumenti di cui hanno bisogno.
• Hai quelli che si educano a diventare programmatori solo perché il mercato era buono per essere assunto per la programmazione. Di solito sono mediocri perché mancano della passione.
• Hai quelli che sono bravissimi a comunicare e "possono risolvere qualsiasi cosa", ma una volta che ottengono il lavoro si aggrappano a tutti gli altri per ottenere aiuto per il problema che stanno risolvendo.

Se riesci a trovare l '"hacker" che documenta molto bene e che possiede eccellenti capacità comunicative, credo che tu abbia raggiunto il jackpot.

Oh, e un'ultima cosa. Probabilmente non vuoi un programmatore che abbia ambizioni da leader, poiché utilizzerà la programmazione solo per lanciarsi. Ciò significa che prima o poi perderai quella risorsa.

Una domanda che farei quando assumi un programmatore sarebbe: "Perché ti sei educato come programmatore?". Sarebbe un regalo morto se esitassero lì.

È la mia opinione.

Un mio amico lavora in un'azienda in cui ha un ulteriore passo nel processo di assunzione: dopo lo screening iniziale e il colloquio, un candidato deve "testare il lavoro" per alcuni giorni. Mi disse che anche se un candidato aveva tutte le capacità e i talenti necessari, non lo assumevano perché non era una persona simpatica con cui lavorare.

È molto difficile riconoscere un programmatore basato solo su un colloquio di lavoro.

Alcune cose che decidono che qualcuno è un buon programmatore sono:

• in grado di lavorare in gruppo
• scrive un buon codice che sia comprensibile e mantenibile
• è in grado di conoscere nuove tecnologie

Quindi hai alcuni piccoli suggerimenti che puoi scoprire in un'intervista:

• Il candidato conosce un linguaggio tecnologico / di programmazione o ne conosce molti? Se conosce lingue diverse, sembra essere in grado di imparare cose nuove e probabilmente conosce gli aspetti negativi della sua attuale tecnologia / lingua preferita. Quindi chiedi conoscenza oltre alla tecnologia che usi nella tua azienda.
• Chiedi i progetti in cui ha già lavorato, in particolare i progetti per hobby e open-source. I progetti Hobby ti mostrano che gli piace programmare e farlo anche nel tempo libero (e in questo modo migliora le sue abilità). In un progetto open source puoi cercare il codice che ha scritto. Se il progetto coinvolge più di una persona, potresti ricevere suggerimenti sulle sue capacità di squadra. In un progetto OS è possibile cercare gli archivi della mailing list per saperne di più.

Potresti eseguire alcuni test nell'intervista.

Ma molte volte c'è anche un problema con l'ambiente di lavoro stesso. Sicuramente questo potrebbe non essere il caso nella tua organizzazione, ma è abbastanza comune nel settore dell'industria del software che il debito tecnologico diventa troppo grande. Quindi, quando assumi nuove persone, non aiuta molto se sono buone o no, a causa del debito. Massimizzare la leggibilità e la comprensibilità del codice del programma aiuta i nuovi arrivati ​​a mettersi al lavoro.

Inoltre molte persone sono in grado di cooperare, ma a volte non c'è modo di cooperare. Ad esempio, se tutte le persone sono sviluppatori, dovrebbero fare il loro lavoro. Bene, lo fanno. Ma hai un architetto che guida il progetto di sviluppo e tiene riunioni e cose del genere? Gli sviluppatori normali potrebbero ritenere di non avere il mandato necessario per iniziare le riunioni e potrebbero pensare che interrompere di tanto in tanto gli altri non sia la strada giusta.

Comunicare tra loro non dovrebbe essere l'obiettivo finale. Meno comunicazione è necessaria, meglio è, ma solo se meno è possibile. Meno diventa possibile se hai un architetto. La quantità totale di comunicazione potrebbe rimanere a un buon livello, ma si ottengono più risultati per la stessa quantità di comunicazione.

per prima cosa comincio con le solite cose dell'intervista, ritengo molto importante vedere se la persona davanti a me vale qualcosa e per determinare le sue abilità e conoscenze.

Dopodiché utilizzo un paio di tecniche nel campo di Java, come discutere alcuni principi, presi principalmente da Effective Java.

A questo punto, quando penso che potrei avere un buon programmatore davanti a me, gli do un pezzo di codice per revisionarlo. Quello che voglio vedere è che è in grado di individuare le parti pericolose del codice, dare alcuni suggerimenti sui miglioramenti, trovare insidie ​​sulle prestazioni un multi threading E che può distinguere tra osservazioni importanti e "osservazioni sul gusto". Tutto ciò mi aiuta a trovare un dipendente più competente.

ma alla fine ricordo sempre che l'assunzione è una specie di gioco d'azzardo ... molto molto difficile da prevedere ...

So che questo non risponde a ciò che stai chiedendo, ma raccomando, le leggi lo consentono, assumono sempre su base temporanea all'inizio (due settimane o un mese, a seconda del lavoro). Se la persona vale il suo sale, non obietterà, inoltre è una salvaguardia per entrambi (puoi lasciarlo andare e potrebbe finire per non gradire il lavoro e andarsene).