Programmazione di coppie per un colloquio di lavoro

Question

La nostra azienda ha pensato di rottamare le nostre procedure di intervista e riunire ogni candidato per 4-5 ore con alcuni programmatori e fare solo un paio di programmi.

Mi piace l'idea in teoria, ma non sono sicuro di come sia possibile renderlo giusto per ogni candidato. Come valuteresti loro? Il loro contributo non dipenderebbe realmente da ciò che ciascun programmatore stava lavorando in quel giorno?

Qualsiasi idea sul fatto che questa sia una buona idea/cattiva idea o su come farlo funzionare è ciò che sto cercando in questo caso.

Cheers!

EDIT:

RISULTATO - come richiesto

Ci accingiamo a condurre i primi passi del colloquio la stessa di prima. Telefono seguito da faccia a faccia. Invece di riportarli per una terza e ultima griglia, porteremo 3 sviluppatori a sedere con tutti e 7 i membri del team. Abbiamo deciso di lasciare decidere al team chi è stato assunto.

Siamo giunti a questa conclusione per un paio di motivi. Riteniamo che ciò consentirà agli sviluppatori di dare loro una scelta su chi stanno lavorando. La seconda ragione è dinamica di gruppo. Pensiamo che sia davvero importante avere un buon gruppo dinamico ed è difficile dirlo fino a quando non assumerai una persona se si adatterà o meno.

Quindi il risultato finale è che andremo avanti con le sessioni di programmazione della coppia, ma in un modo completamente diverso e per un modo completamente diverso da quello previsto originariamente.

Qualsiasi pensiero o critica di questo approccio è più che benvenuto !! (questa modifica è postata come risposta qui sotto, quindi non esitare a downvotare se ritieni che questo non sia l'approccio migliore)

Answer 1

Spero che tu abbia un mucchio di passi avanti a questo. Per far funzionare tutto ciò è necessario un curriculum e uno schermo del telefono eccellenti. Non vuoi spendere una gran quantità di tempo su candidati ai quali non dovresti parlare in primo luogo.

Così si segnala un colloquio iniziale e forse avere la seconda intervista come la sessione di programmazione coppia? - Ted Smith (1 minuto fa)

Sì. Potresti anche pensare di fare una semplice intervista di codifica sul web usando qualcosa come CoPilot.

Answer 2

Il modo più semplice è dare a ciascuna persona lo stesso programmatore con cui lavorare e lo stesso identico codice.

Il problema in cui ti imbatterai è che l'assunzione non è come la programmazione. Non esiste un processo graduale per condurre alla risposta giusta su chi assumere. (puoi avere più passaggi per rendere la decisione più semplice). Devi valutare ognuno dei loro punti di forza ecc. Ed essenzialmente fare un'ipotesi plausibile su quale sia il migliore da assumere. A volte indovina male.

L'altra cosa sulla programmazione delle coppie a cui dovrete stare attenti è la quantità di tempo necessario affinché ogni candidato in quella fase passi attraverso quel tipo di test.Se cercassi un lavoro, sarei riluttante a fare un'intervista a un'azienda che mi chiedesse di farlo. Perché? Perché è un sacco di tempo, e se intervengo in più posti, potrei passare letteralmente giorni solo andando a interviste per lavori che forse non ho nemmeno ricevuto o voluto. Qualche spazio come Google o MS sarebbe un'eccezione, ma la maggior parte dei posti non sono come quei due. (Per non parlare del fatto che se stanno lavorando su un codice reale, si sta essenzialmente chiedendo loro di fare il lavoro di qualcuno gratuitamente).

Answer 3

A meno che non si utilizzi ampiamente la programmazione pair nel proprio sviluppo reale, sarei molto restio a utilizzarlo. Ho incontrato un numero qualsiasi di sviluppatori professionali di alta qualità che hanno menzionato una forte avversione per accoppiare la programmazione e le cui abilità non sarebbero state giudicate bene in tale processo.

Answer 4

Perché no? Inoltre, non è come se le interviste fossero sempre (o mai) giuste. Dovresti valutare i risultati finali del nuovo approccio rispetto all'approccio tradizionale basato sull'intervista.

Inoltre, una mini intervista prima della sessione di programmazione della coppia potrebbe essere buona per evitare di sprecare tempo con i programmatori con persone che si comporterebbero male.

Answer 5

Mi piace questa idea. Comunque penso che potrebbe essere difficile da fare in quanto richiederebbe al candidato di avere una certa conoscenza del progetto con cui lo accetterei. Inoltre, da 4 a 5 ore sembra un po 'lungo. Che cosa succede se vedi immediatamente che non funzionerà, hai intenzione di sederti per tutta la sessione con il candidato?

Buona domanda però. Cose a cui pensare.

Answer 6

Per mantenerlo corretto, è necessario che ogni membro del personale partecipante abbia un problema preparato per valutare il candidato. Preferibilmente qualcosa preso dal mondo reale nella loro esperienza aziendale, ma qualcosa che è già stato risolto. Questa è una buona occasione per valutare le conoscenze su un problema e valutare non solo le abilità di programmazione.

Odio quando si risponde a domande troppo specifiche. Una volta ho avuto un'intervista in cui un programmatore stava testando la mia conoscenza dell'STL che ho usato ampiamente e stava cercando di convincermi che era necessario un allocatore personalizzato. Ne avevo sentito parlare ma non li ho mai usati (specialmente in Windows) e mi sono sentito stupido. IOW, evita di essere critico.

Quindi il mio punto è, fare domande pratiche che non riguardano tanto la verifica della conoscenza di programmazione quanto è possibile valutare una maggiore qualità qualitativa e approcci di risoluzione dei problemi se si utilizza l'idea della "coppia di programmazione".

Buona domanda!

Answer 7

Onestamente, sembra un'idea grandiosa, anche se Jason Punyon ha certamente ragione a dover fare un sacco di diserbo prima di sprecare una notevole quantità di tempo per gli abbattitori. Puoi dare un'occhiata a una metrica importante che altrimenti sarebbe quasi introvabile nell'intervista: con chi ti piace lavorare.

Non credo che sia davvero necessario preoccuparsi che sia "equo" basato sull'argomento o che cerchi di presentare situazioni coerenti a candidati diversi, se si mantiene il giusto atteggiamento valutativo - che non è Si trattava di "avere la risposta giusta" o di passare attraverso il set giusto di cerchi, ma che tipo di sforzo, capacità di risoluzione dei problemi, attitudine alla comunicazione e flessibilità mostrarono. Perderai la maggior parte del beneficio dell'esercizio trasformandolo in un test artificiale, per non parlare del fatto di cambiarlo da qualcosa che i tuoi sviluppatori possono trarre qualche beneficio (o almeno ancora ottenere un po 'di lavoro durante) con un enorme spreco di il loro tempo.

Answer 8

Joel Spolsky ha un eccellente Guerrilla Guide to Interviewing che parla, tra le altre cose, delle attività di programmazione.

Curiosità: Joel Spolsky è una co-fondatore di stackoverflow.com

Answer 9

Come un aneddoto personale, mi sono schiaffeggiò in giro in un'intervista a causa di una tecnica come questa. Ero andato lontano nel loro processo di intervista; passato i controlli del curriculum, la presentazione del codice e questa era la parte faccia a faccia dell'intervista.

Ero appena uscito dall'università e non avevo mai programmato prima né TDD. Mi hanno fatto sedere per fare un mazzo di carte e si è fatto floppare. Male! Non capivo perché l'intervistatore stesse scrivendo test che sembravano così stupidi * (IE "return null;") e non spiegavano perché e, naturalmente, essendo estraneo al TDD, non sapevo quali domande porre. Il risultato finale è stato che sembrava che non potessi programmare la mia uscita da un sacchetto di carta.

Se hai intenzione di fare questo tipo di esercizio, devi rivolgerti all'intervistato perché si troveranno in posti diversi con la loro attitudine. Ciò significa che otterrete valutazioni diverse che potrebbero non essere basate sul talento reale e che quindi saranno fortemente influenzate.

** Ora che ho capito TDD, capisco test come questo e come dovrebbe funzionare, ma l'uomo ha fatto mai sembrare stupido, al momento! *

Answer 10

Un particolare azienda utilizza una tecnica chiamata estrema intervista. Per l'intervista estrema porteranno 30 sviluppatori e li raggrupperanno in 15 coppie. Spiegheranno che stanno cercando persone che lavorano bene con gli altri. Che prenderanno una decisione di assunzione basata unicamente sulla loro capacità di lavorare con gli altri.

Essi forniranno un problema per le coppie da risolvere. Sottolineeranno che non sono interessati alla soluzione, solo la capacità di ogni programmatore di lavorare con gli altri. Per ogni coppia forniranno un osservatore della coppia. Durante l'esercizio (da 2 a 4 ore di durata), l'osservatore prende appunti sull'abilità di una persona di accoppiare ... non la soluzione.

Sono stupiti di quanti programmatori si concentrano sulla risoluzione del problema anziché sulla collaborazione. Delle 15 coppie, identificheranno circa da 4 a 6 sviluppatori per una seconda intervista. A questi sviluppatori verrà chiesto di tornare e trascorrere una settimana con il team (vengono pagati). Dopo una settimana, decidono chi tenere. Generalmente circa la metà di loro (da 2 a 3 sviluppatori).

Quando hanno finito, hanno sviluppatori in grado di collaborare e dopo una settimana di lavoro con varie coppie, il team ha una forte indicazione che può effettivamente sviluppare software. Il processo è innovativo ed efficace. Hanno avuto un alto tasso di successo con quelli che hanno assunto.

Answer 11

Ho appena avuto un'intervista con una società con sede a San Francisco che si vanta di metodi Agile/ecc. Dovevo intervistare il CEO stesso. Ho circa 20 anni di esperienza nel settore, ma non ho mai abbinato programmato o sviluppato utilizzando l'approccio TDD. Mi è stato detto che sarebbe stato un "colloquio di programmazione" ma non avevo idea di cosa aspettarmi, e prima che iniziasse il ragazzo disse che pensava che potessi essere d'accordo sul fatto che tutte le interviste dovessero essere fatte in questo modo. (che in retrospettiva non era altro che una dichiarazione arrogante).

In ogni caso, durante l'intervista l'esercizio era di sviluppare una lezione usando TDD. Mi ci è voluto un secondo per regolare il mio modo di pensare sull'intero processo, anche perché non avevo mai programmato o fatto il TDD. Mentre sono inciampato qui e là ho fatto bene alla fine. ma la sua risposta è stata che non mostravo la natura aggressiva del back-and-end di cui hanno bisogno per il loro ambiente di programmazione di coppia. Ora, quello poteva anche essere un modo subdolo per dire che "non pensavo avessi fatto un bel" tipo di messaggio.

Fortunatamente non avevo bisogno del lavoro e, ad essere sincero, l'esperienza mi ha fatto capire che preferirei trovare una carriera diversa da quella di dover essere un ingegnere del software che deve lavorare in coppia, giorno dopo giorno, quando è venuto a sviluppare il codice. La cosa strana è che a volte ho lavorato con un'altra persona sul codice contemporaneamente, quindi tutto è possibile.

In conclusione, credo che sia stato un buon risultato dato che non pensavano che fossi una buona idea e che non mi importava dei loro metodi di lavoro. Ma saremmo giunti alla stessa conclusione se avessi parlato per qualche minuto di più su me stesso e mi avesse dato qualche informazione in più su come vanno sul loro lavoro. Il che significa che esistono altri modi per trovare un candidato idoneo piuttosto che sottoporli allo stress della programmazione di coppia con un estraneo completo; modo falso per valutare la competenza imo.

Answer 12

Dalla mia esperienza limitata, i miei sentimenti sono misti. Mi piace l'idea di abbinare come parte di un'intervista, esp. se l'azienda utilizza spesso l'abbinamento, perché offre sia una migliore sensibilità per l'adattamento. Come candidato, sono passato spesso attraverso interviste in cui mi sono seduto in una stanza a rispondere alle domande per qualche ora, ma in seguito non avevo la sensazione che sarebbe stato lavorare nel loro ambiente. L'accoppiamento può essere più vantaggioso di un esercizio di codifica casuale, a meno che l'intervistatore non sia in grado di lavorare con qualcuno. E mi piace essere in grado di discutere di materiale tecnico da entrambe le parti. E come candidato preferirei interagire con qualcuno piuttosto che rispondere alle domande o risolvere i problemi del codice da solo.

Ma ... come altri hanno notato, il tempo necessario può essere un problema. Ho passato un paio di giorni di interviste di abbinamento e ho trovato alcuni periodi buoni, mentre altri sentivano che poche ore erano sprecate: una perché lo sviluppatore non stava lavorando su qualcosa che si prestava all'abbinamento (specialmente dato il mio background), l'altro perché un problema env ha impedito un lavoro molto utile per un po '. Se il lavoro non funziona, può essere frustrante aver impiegato un giorno o due a lavorare per questo.

Un luogo che ha provato questo approccio non era sicuro se avrebbero dovuto avere qualcuno al di fuori dell'azienda che lavorava al progetto di un cliente. Hanno anche temuto che spiegando il dominio e il lavoro svolto ci sarebbe voluto troppo tempo, anche se senza di esso il candidato potrebbe non essere in grado di contribuire molto. Così hanno scelto un progetto open source su cui il dipendente stava lavorando.

Questo sembra essere un punto chiave: ci deve essere un compito ben scelto che il candidato può capire rapidamente e essere in grado di contribuire a. L'ultima parte dipenderà in parte dalle capacità del candidato. Un'altra chiave potrebbe essere la capacità del dipendente di valutare qualcuno con questo approccio. Non tutti sono bravi alle normali interviste, e questo è probabilmente più vero di un colloquio di abbinamento.

Inoltre, se un'azienda non fa molto abbinamento, questo tipo di interviste potrebbe non essere altrettanto utile. Sembra che ci sia un beneficio nel vedere il codice di qualcuno (come fa notare Joel Spolsky), e questo potrebbe essere un buon modo per farlo. Ma se l'abbinamento non è una parte tipica del lavoro, forse una sessione di abbinamento completa non è appropriata. Forse una versione modificata.

Sarei curioso di sapere quali aziende che hanno adottato questo approccio pensano ai risultati. Leggendo alcune delle altre risposte a questa domanda dimostra che non sempre sembra ideale dal punto di vista del candidato.

Answer 13

Ho appena avuto un paio di interviste di programmazione pochi giorni fa e, ad essere onesti, non mi piace molto. Mi è stato comunicato un giorno prima dell'intervista e poi l'intervistatore mi ha detto che la programmazione di coppia è ciò che alla fine farò comunque nel lavoro. Sono andato in ufficio ed ero in coppia con qualcuno che è un ingegnere del software molto anziano. La compagnia è a San Francisco e sono una compagnia rinomata per la programmazione delle coppie, tutti abbinano i programmi in ufficio.All'inizio sembrava che andasse bene, spiegava di tutti gli strumenti che usavano, del proprio framework di test unitario che costruivano e di un po 'del progetto. Ha quindi scritto fondamentalmente un gruppo di test unitari e voleva che lavorassi all'implementazione per farlo passare. Proprio come una FYI, la base di codice che esiste già è enorme, direi 10k linee, non è come un progetto super-complesso, ma è complesso per qualcuno semplicemente intervenire e quindi scrivere codice senza una precedente comprensione della gerarchia di classi ecc. Trovo davvero difficile credere che si aspetti che qualcuno salti subito con una linea di codice 10k che esiste già. Semplicemente non corrisponde ad un'intervista di programmazione di coppia, una base di codice più piccola sarebbe d'aiuto. Ho faticato un po 'a navigare tra le classi e andare avanti e indietro perché non ricordo i nomi delle classi perché ero sopraffatto dalla quantità di classi/codice che già esiste. Ad essere onesti, questo mi ha fatto davvero fare orribile nel processo dell'intervista. Alla fine non mi sono sentito veramente bene. Non ho mai fatto programmi di coppia prima, principalmente durante i compiti del mio anno universitario.

Per me la potenza della programmazione della coppia può essere sfruttata se si è già abili/a proprio agio con la coppia, ma non è proprio adatto per il colloquio. A volte vorrei fare domande alla mia coppia, ma poi ho pensato che se facessi troppe domande, allora avrebbero pensato che fossi stupido e non potessi esibirmi. Se questo fosse già un vero lavoro, non esiterei a chiederlo, ma in un'intervista è difficile .. vuoi chiedere perché la tua coppia dovrebbe aiutarti quando sei bloccato, ma allo stesso tempo è un'intervista , quindi non puoi davvero chiedere molto.

Quella è solo la mia esperienza che ho da un'intervista coppia di programmazione, il mio suggerimento, se si vuole veramente fare questo:

1. essere sicuri che non si danno il candidato di lavorare con una grande base di codice , lavora con uno più piccolo e quindi lui/lei può mostrare le sue abilità al massimo
2. essere in anticipo con il candidato prima dell'intervista di programmazione di coppia, puoi fare domande quando sei bloccato, dovresti essere in grado per fare questo e quello, cosa non puoi fare
3. essere il più dettagliato possibile e

Alla fine, non lo suggerirei. È difficile misurare le prestazioni di un candidato nella programmazione di coppie, e potrebbe essere anche di parte.