Quanto sono efficaci le sfide di programmazione nel processo di reclutamento? [chiuso]

Come qualsiasi strumento, possono essere estremamente utili o estremamente pericolosi. Un trapano elettrico renderà la tua vita molto più facile - fino a quando non forerai la parte superiore della tua mano e atterrerai nel pronto soccorso. Lo stesso vale per le sfide di programmazione nel reclutamento.

The Good : questo può essere un modo efficace per rilevare qualcuno che, sulla carta, potrebbe non essere così avvincente come programmatore. Quello con una laurea in qualcosa che ha ben poco a che fare con ciò che le persone normalmente considerano campi di "programmazione" correlati - Biologia, Scienze politiche, Storia dell'arte ...

Se passano attraverso le tue sfide, allora sono grandiose. Hanno imparato la programmazione, in qualche modo, ed è apparentemente bloccato. Se si impantanano, la loro applicazione potrebbe davvero essere qualcosa che sfugga alle risorse umane.

The Bad : una sfida di programmazione scritta male non valuta in realtà capacità di programmazione . Mette alla prova la soluzione dei puzzle tramite l'abilità di programmazione . Il problema è che la seconda è una domanda a due variabili: sei bravo a risolvere i rompicapo e puoi risolvere il puzzle risolvendolo tramite codice. È possibile avere un programmatore di talento che fallisce completamente nella parte di risoluzione dei puzzle.

La maggior parte delle sfide di programmazione che ho visto non riescono a rilevare le persone che sono vicino a quello che vuoi, a seconda di come è scritto.

Ci sono modi per mitigare entrambi. Per questi ultimi, prenderei in considerazione l'idea di accettare un "credito parziale" sotto forma di soluzioni che non sembrano arrivare proprio lì, "Ecco come risolverei questo ..." ecc. Se stai veramente cercando un problema risolutori. Dopotutto, pochissime persone codificano da sole, e se la loro risposta sarebbe stata giusta se potevano chiedere a un collega anziano "Hey Jim, conosci un buon modo per implementare X?", Potrebbe essere davvero qualcuno che vuoi su la tua squadra.

Il primo è un po 'più difficile, perché l'onere per questo è su di te. Scegli i puzzle / problemi / sfide che contano. Se nessuno nel tuo gruppo si è mai scontrato con qualcosa di lontanamente somigliante al problema del Commesso viaggiatore nel suo lavoro, non fare qualche giro geniale su Traveller Salesman la sfida che ti viene in mente. In questo modo, se falliscono nell'aspetto risolutivo di "risolvere il problema e codificarlo", stanno almeno fallendo in qualcosa che in realtà emergerà, piuttosto che in un po 'arbitrario di intelligenza che la tua squadra ha sparato a pranzo.

Molto efficace.

... purché il processo di assunzione non contenga solo sfide di programmazione. Mentre mi preoccupo e odio fare la valutazione tecnica di ogni intervista, fa fa da indicatore semplice per filtrare gli idioti. E filtrare gli idioti è il punto cruciale del processo di reclutamento, quindi puoi dedicare più tempo a coloro che sono adatti per il ruolo.

Durante le interviste, ritengo molto importante vedere cosa dice la gente sotto pressione. Se sono inclini a sputare un mucchio di merda sfacciata, è facilmente identificabile e saprò che questa persona non vale il mio tempo.

More likely to be afraid to come up to us at a career fair.

Questa non è una brutta cosa. Se il tuo potenziale candidato non è disposto a scommettere sul fatto che valga la pena di essere assunto lì, vuoi davvero reclutarlo comunque?

Suppongo che tu voglia che qualcuno lavori come membro di un team - in quanto tale, il programmatore migliore è la persona che lavora meglio con i membri del team esistenti. Vuoi riunire un gruppo di persone in grado di comunicare efficacemente l'un l'altro, che in realtà vanno d'accordo (non devono essere amici, ma hanno bisogno di un buon rapporto e rispetto), che sono disposti ad essere d'accordo e utilizzare standard di sviluppo comuni (codice e processo), che sono disposti ad aiutare i loro college quando affrontano un nuovo problema o hanno un blocco mentale (teoria dei quattro occhi). Devi anche trovare un mix di tipi di personalità, quindi se hai una squadra di introversi che di rado parli, allora un membro del team più socievole può migliorare le dinamiche di squadra che renderanno il team più produttivo. D'altra parte, vuoi evitare una persona con una personalità eccessivamente strong perché dominerà il team e questo ridurrà la qualità e la produttività, in particolare con gli introversi del team.

Dopo aver inserito una persona in quel mix, considera abilità / abilità tecniche. Anche questi devono essere complementari. Ognuno ha diverse aree in cui sono forti, altri sono a posto e alcuni non ne hanno idea. Quindi è necessario ottenere un mix di punti di forza rilevanti per il progetto in questione. Ricorda che un programmatore intermedio che lavora bene con un buon programmatore avrà il livello del proprio lavoro elevato dalla persona più strong. L'anello debole della catena sono le relazioni, non le abilità (a condizione che l'abilità sia nella squadra)

Buona fortuna nel metterlo insieme.