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

Penso che la nostra azienda possa creare sfide progettate per trovare candidati ingegneri del software che sono:

• Bravo a risolvere i problemi, non a stupire i recruiter.
• Più probabilità di avere paura di venire da noi in una fiera della carriera.
• Più probabilità di essere sottoutilizzati nel loro attuale lavoro di programmazione, ma sono troppo introversi per fare qualcosa al riguardo.

Per un esempio, vedi questo articolo che tratta Facebook che nasconde un indirizzo e-mail in un'immagine usando Piet .

Non riesco proprio a trovare studi o dati concreti sul fatto che funzioni davvero o meno.

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

Il buono : questo potrebbe essere un modo efficace per rilevare qualcuno che, sulla carta, potrebbe non essere così convincente come programmatore. Quello con una laurea in qualcosa che ha ben poco a che fare con ciò che le persone normalmente considerano i campi relativi alla "programmazione": biologia, scienze politiche, storia dell'arte ...

Se superano le tue sfide, va benissimo. Hanno imparato la programmazione, in qualche modo, ed è apparentemente bloccato. Se si impantanano, la loro applicazione potrebbe davvero essere qualcosa che è sfuggita alle risorse umane.

Il cattivo : una sfida di programmazione scritta male non valuta effettivamente l' abilità di programmazione . E le prove di puzzle solving tramite abilità di programmazione . Il problema è che in seguito è una domanda a due variabili: sei bravo a risolvere i puzzle e puoi fare la risoluzione dei puzzle tramite codice. È possibile avere un programmatore di talento perfetto 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 vicine a quello che vuoi, a seconda di come è scritto.

Ci sono modi per mitigare entrambi. Per quest'ultimo, prenderei in considerazione l'accettazione del "credito parziale" sotto forma di soluzioni che non sembrano essere abbastanza raggiungibili, "Ecco come lo risolverei ..." ecc. Se stai davvero cercando un problema risolutori. Dopotutto, pochissime persone codificano da sole, e se la loro risposta sarebbe stata giusta se potessero chiedere a un collega senior "Ehi Jim, conosci un buon modo per implementare X?", Potrebbe benissimo essere qualcuno su cui vuoi la tua squadra.

Il primo è un po 'più difficile, perché l'onere di ciò è su di te. Scegli puzzle / problemi / sfide che contano. Se nessuno nel tuo gruppo si è mai imbattuto in qualcosa che assomiglia in remoto al problema del commesso viaggiatore nel loro lavoro, non fare qualche giro intelligente sul commesso viaggiatore la sfida che ti viene in mente. In questo modo, se non riescono a risolvere il problema di "risolvere il problema e codificarlo", almeno non riescono in qualcosa che effettivamente verrà fuori, piuttosto che un po 'di intelligenza arbitraria che la tua squadra ha sputato a pranzo.

Molto efficace.

... purché il processo di reclutamento non contenga solo sfide di programmazione. Mentre mi struggo e voglia di fare la valutazione tecnica di un colloquio, si fa agire come un semplice indicatore per filtrare 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.

Quando intervista, ritengo molto importante vedere cosa dicono le persone sotto pressione. Se sono inclini a sputare un mucchio di schifose cazzate, è facilmente identificabile e saprò che questa persona non vale il mio tempo.

Più probabilità di avere paura di venire da noi in una fiera della carriera.

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

Suppongo che desideri che qualcuno lavori come parte di un team - in quanto tale, il programmatore migliore è la persona che lavora meglio con i membri del team esistenti. Volete riunire un gruppo di persone in grado di comunicare efficacemente tra loro, che in realtà vanno d'accordo tra loro (non devono essere amici, ma hanno bisogno di un buon rapporto e rispetto), che sono disposti a concordare 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 un team di introversi che parlano raramente, quindi portare un membro del team più loquace può migliorare le dinamiche del team che renderanno il team più produttivo. D'altro canto,

Dopo aver indotto una persona a inserirsi in quel mix, quindi considera l'abilità / abilità tecnica. Anche questi devono integrare. Ognuno ha aree diverse in cui sono forti, altri in cui sono OK 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 sollevato dalla persona più forte. L'anello debole della catena sono le relazioni, non le abilità (a condizione che l'abilità sia nella squadra)

Buona fortuna nel metterlo insieme.