it-swarm.it

Come riconoscere un buon programmatore?

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 del 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" nei confronti della persona (cioè, principalmente della tua esperienza), e di provarlo?

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

133
gius

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.

157
Jon Skeet

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 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 di essere diventato più bravo a intervistare le persone dopo aver letto Guida di Joel alle interviste con la guerriglia (ora alla versione 3.0, che è in anticipo rispetto alla versione per il web e tutto il resto, deve solo essere buono).

Ci sono anche altre 57 domande (al 20/11/2008) su Software Engineering Stackexchange taggato con intervista e alcune sembrano molto rilevanti, quindi dai un'occhiata a quelle.

84
Hamish Smith

Qualche idea:

  • Poni diverse domande aperte da diverse angolazioni:

    • Rivedi alcuni codici. Cosa è stato identificato? Errori tecnici, incoerenze di stile, commenti, algoritmi, manutenibilità, ecc ...
    • Scrivi un po 'di codice. Cerca processi, prove antiproiettile, 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 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 in 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, presente. Devi sapere che c'è qualcuno dentro. :-)

47
Adam Liss

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 .

39
Eigir

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 a essere migliori programmatori, in genere le persone non possono imparare a essere migliori esseri umani.

24
Doctor Jones

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.

16
Manoj

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 chiunque altro per ottenere aiuto per il problema che stanno risolvendo.

Se riesci a trovare l '"hacker" che documenta molto bene e che ha eccellenti capacità comunicative, credo che tu abbia vinto 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.

16
Wolf5

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 sebbene un candidato avesse tutte le capacità e i talenti necessari, non lo assumevano perché lo era un a non è una brava persona con cui lavorare.

7
Svante

È 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 apprendere 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 di hobby 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 capacità di squadra. In un progetto OS è possibile cercare gli archivi della mailing list per saperne di più.
6
Mnementh

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.

3
Silvercode

per prima cosa comincio con le solite cose del colloquio, considero molto importante vedere se la persona davanti a me vale qualcosa e per determinare le sue abilità e conoscenze.

Dopodiché uso 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 ...

3
baba smith

So che questo non risponde a ciò che stai chiedendo, ma raccomando, leggi permettendo, assumi 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).

2
Vinko Vrsalovic