Come riconoscere un buon programmatore? [chiuso]

Invitali a parlare di ciò a cui sono interessati. Devo ancora incontrare uno sviluppatore che sia davvero appassionato quando parla di programmazione ma non può realmente codificarlo. Possono certamente esistere, ovviamente - e anche il tuo colloquio dovrebbe verificare la competenza - ma la passione è un buon indicatore nella mia esperienza. (Si noti che non è lo stesso di essere in grado di "parlare del discorso" in termini di parole d'ordine.)

Chiedi loro cosa non piace sulla loro lingua o piattaforma preferita. Come avrebbero risolto 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 .

Ho avuto alcuni errori reali per farmi migliorare. Comincia a fidarti del tuo tratto intestinale molto di più dopo il primo paio di volte che non ti fidi di esso e te ne penti.

Ho un grande rispetto per domande sullo schermo del telefono di Steve Yegge e ho usato questo 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 alla guerriglia (ora alla versione 3.0, che è prima della versione per il web e tutto, deve essere buono)

Ci sono anche altre 57 domande (a partire dal 20/11/2008) su Ingegneria del software Stackexchange taggato con intervista e alcuni di loro sembrano molto pertinenti, quindi dai un'occhiata.

Alcune idee:

• Poni diverse domande aperte da diversi punti di vista:

  • Esamina il codice. Che cosa è stato identificato? Errori tecnici, incoerenze di stile, commenti, algoritmi, manutenibilità, ecc ...
  • Scrivi un po 'di codice. Cerca process, bullet-proofing, leggibilità, ecc.
  • Crea un progetto di alto livello per un piccolo sistema. Cerca la comprensione del problema, l'approccio, le comunicazioni, la completezza, i dettagli.
  • Descrivi 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 semplice domanda e poi, in base alla risposta, chiedi a un'altra, leggermente più dettagliata, e continua a "scavare" fino a raggiungere il limite della conoscenza del candidato. Questo ti dà un'idea di:

  • Onestà: lo sa quanto ha preteso?
  • Profondità della conoscenza: quanto bene apprende le cose?
  • Comunicazione: quanto ti spiega qualcosa di non familiare? Il processo di pensiero è logico?
  • Reazione a situazioni stressanti: quanto duro lavora per rispondere? Lo falsifica? L'inevitabile "non lo so" è facile o difficile?

• Chiedi come il candidato ha affrontato varie situazioni in precedenti lavori: lavoro di gruppo, progetti scaduti, debug, etc . Le risposte sono positive o negative? Appassionato? Intelligente? Arrogante?

Trovo che i migliori candidati siano entusiasti, esperti, fiduciosi 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 la programmazione molto bene per vedere attraverso il materiale che viene detto e fatto nell'intervista, e devi sapere quali domande porre.

Ho visto candidati che hanno ricevuto la risposta sbagliata al colloquio, ma la loro spiegazione ha dimostrato che conoscevano l'argomento (e quindi potevano facilmente ottenere la risposta giusta cercando nella rete). Per vederlo, devi conoscere l'argomento che stai facendo domande molto bene.

Un'altra cosa è evitare domande sui dettagli che potrebbero essere facilmente consultati. Queste domande mostrano solo quanto è buono il candidato a ricordare le cose, non se lui o lei hanno davvero le conoscenze e le conoscenze che stai cercando.

La mia raccomandazione è di ottenere aiuto da qualcuno che conosce una grande quantità di programmazione e di avere buone capacità di persone, per aiutare 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 li troverai molto utili.

La personalità dei programmatori dovrebbe essere più in alto nella lista di quella che la maggior parte dei datori di lavoro sembra classificare. Nel mio attuale posto di lavoro sono molto cauti nell'assumere il tipo corretto di persona.

In generale, le persone possono imparare a diventare dei programmatori migliori, in genere le persone non possono imparare a essere esseri umani migliori.

Fagli fare il codice. Dare un problema che può essere risolto in 4 o 5 ore e controllare il codice per la documentazione, lo stile di codifica, come ha pianificato la soluzione prima di iniziare effettivamente a codificare ecc. Non ha bisogno di risolvere il problema. E come ha detto Jon Skeet, fagli parlare della programmazione, del loro linguaggio di scelta e cose del genere. Puoi recogonizzare la passione in un buon programmatore. Chiedi quanti siti di programmazione hanno seguito, come lo stackoverflow. I blog che seguono possono essere un buon indicatore.

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

Un buon programma di programmazione sul lato oltre al lavoro (almeno una volta ogni tanto). A lui piace risolvere problemi di programmazione. E quando lui / lei non riesce a trovare un programma che risolve un particolare bisogno a casa, cercherà tipicamente di risolverlo da solo.

Ma ci sono diversi tipi di programmatori.

• Hai quelli che amano documentare. Personalmente odio documentare. Ma documentare cosa è fatto può essere importante.
• Hai gli "hacker". Quelli che sono d'accordo nel risolvere un puzzle complesso in cui, se tu dovessi cercarlo su 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 bravi a comunicare e loro "possono risolvere qualsiasi cosa" ma una volta ottenuto il lavoro si impiccano su tutti gli altri per ottenere aiuto per il problema che stanno risolvendo.

Se riesci a trovare l '"hacker" che documenta anche molto bene e ha ottime capacità comunicative, credo che hai raggiunto il jackpot.

Oh, e un'ultima cosa. Probabilmente non vuoi un programmatore che abbia ambizioni da leader, visto che userà solo la programmazione per partire. Ciò significa che perderà la risorsa prima o poi.

Una domanda che vorrei porre quando assumere un programmatore sarebbe: "Perché ti sei educato come programmatore?". Sarebbe un regalo fatale se esitassero lì.

Questa è la mia opinione.

Un mio amico lavora in un'azienda in cui ha un ulteriore passaggio nel processo di assunzione: dopo il primo screening e il colloquio, il richiedente deve "testare il lavoro" per alcuni giorni. Mi ha detto che anche se un candidato aveva tutte le capacità e il talento necessari, non lo hanno assunto perché era un non una persona simpatica con cui lavorare.

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

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

• in grado di lavorare in un team
• scrive un buon codice che è comprensibile e maintable
• è in grado di conoscere le nuove tecnologie

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

• Il candidato conosce una tecnologia / linguaggio di programmazione o conosce più persone? Se conosce diverse lingue, sembra essere in grado di imparare cose nuove e forse conosce gli aspetti negativi della sua attuale tecnologia / lingua preferita. Quindi chiedi informazioni oltre alla tecnologia che utilizzi nella tua azienda.
• Richiedi progetti a cui ha già lavorato, in particolare progetti per hobby e open-source. I progetti di Hobby ti mostrano che gli piace programmare e farlo anche nel tempo libero (e in questo modo migliora le sue capacità). 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 abilità di squadra. In un progetto OS puoi cercare negli 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 vostra organizzazione, ma è abbastanza comune nel campo dell'industria del software che il debito tecnologico diventa troppo grande. Quindi quando assumi nuove persone, non è di grande aiuto se sono buone o meno, a causa del debito. Massimizzare la leggibilità e la comprensibilità del codice del tuo programma aiuta i nuovi arrivati a mettersi al lavoro.

Anche molte persone sono tali da poter cooperare, ma a volte non c'è modo di cooperare. Ad esempio se tutte le persone sono sviluppatori, si suppone che facciano il loro lavoro. Bene, lo fanno. Ma hai un architetto, che dirige il progetto di sviluppo e tiene riunioni e simili? Gli sviluppatori normali potrebbero ritenere di non avere il mandato necessario per iniziare le riunioni e potrebbero pensare che l'interruzione degli altri di tanto in tanto non è il modo.

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

Per prima cosa parto dalla solita roba di intervista, ritengo molto importante vedere se la persona di fronte a me vale qualcosa e determinare le sue capacità e conoscenze.

Dopo di che uso un paio di tecniche nel campo di Java, come la discussione di alcuni principi, presi principalmente da Java efficace.

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

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

So che questo non risponde a quello che stai chiedendo, ma raccomando, le leggi permettendo, assumere 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).