La "codifica su lavagna bianca" è inappropriata durante le interviste? [chiuso]

Questa è una domanda un po 'soggettiva, ma mi piacerebbe sentire feedback / opinioni da entrambi gli intervistatori / intervistati sull'argomento.

Abbiamo diviso il nostro colloquio tecnico in 4 parti. Scrivi codice, leggi e analizza codice, progetta sessione e codice sulla lavagna bianca.

Per l'ultima parte, ciò che chiediamo agli intervistati di fare è scrivere un piccolo frammento di codice (4-5 righe) sulla lavagna e spiegare mentre lo attraversano. Vorrei essere chiaro che lo scopo non è quello di catturare le persone. Non stiamo cercando una sintassi perfetta. Al diavolo può anche essere uno pseudo-codice. ma il punto è dare loro un problema molto semplice e vedere se il loro cervello può comunicarci la soluzione. Per problemi semplici intendo "Invertire una stringa", "FizzBuzz" ecc ...

Nota che prima chiediamo sempre un linguaggio esplicito. Siamo una casa .NET C #. abbiamo detto solo "pseudo-codice" in cui qualcuno ha perso spazio / lottando davvero con il codice.

La mia domanda è "È inappropriato / irragionevole aspettarsi che un programmatore scriva uno snippet di codice su una lavagna durante un'intervista?"

A mio avviso, è molto appropriato. Se desideri che un lavoro svolga una particolare abilità, allora è del tutto appropriato aspettarsi di dimostrare tale abilità al colloquio.

L'effetto di questa tecnica sul processo di reclutamento è molto evidente. Il 90% dei candidati fallisce questo compito. ma gli sviluppatori reclutati sono buoni e gli sviluppatori saranno rispettati all'interno dell'azienda.

Se come candidato di fronte a questa tecnica, prima di tutto rilassati. Si tratta di valutare te come programmatore e i tuoi processi di pensiero. Non si tratta della tua sintassi perfetta. Se commetti un errore di sintassi, potrei svolgere il ruolo di un compilatore e dirti che il codice non riesce a compilare su una determinata riga, darti un messaggio di errore e vedere come rispondi. Allo stesso modo se aggiungi un; su un ciclo o un'istruzione if che si sarebbe compilata, avrei giocato il debugger e ti avrei parlato attraverso un singolo passaggio del codice. Ancora una volta, non si tratta dell'errore, riguarda il modo in cui faresti fronte all'errore e i tuoi processi mentali sono buoni.

La mia domanda è "Non è appropriato / irragionevole aspettarsi che un programmatore scriva uno snippet di codice su una lavagna durante un'intervista?"

È molto ragionevole. Un'alternativa a una lavagna potrebbe essere un laptop e un proiettore, poiché i programmatori sono più abituati a scrivere codice su una tastiera che su una lavagna. Assicurati solo che un ambiente di sviluppo come Eclipse o VS o Idle sia già in esecuzione con un progetto vuoto all'avvio del candidato, in modo che non debba perdere tempo a cercare tra le applicazioni installate.

Non è inappropriato, ma sappi che NON può sempre rivelare le vere intuizioni sulle capacità di programmazione o di risoluzione dei problemi della persona che stai intervistando. E immagino che sia esattamente quello che stai cercando.

In secondo luogo, nota che c'è sempre la paura di fallire, che infastidisce costantemente il cervello della persona. "Che cosa succede se faccio un casino?", "Cosa succede se commetto un errore sciocco". La maggior parte del cervello della persona è impegnata a ispezionare costantemente come stanno venendo fuori - solo pochi possono trattenere i nervi.

Quindi, in questo tipo di situazione, anche il migliore potrebbe finire per vacillare.

Per l'ultima parte che chiediamo agli intervistati di fare è scrivere un piccolo frammento di codice (4-5 righe) sulla lavagna e spiegare mentre lo attraversano

Va bene. Ma ancora una volta, solo perché qualcuno non è stato in grado di spiegare correttamente qualcosa non significa che non lo sappiano bene. (La spiegazione è un'arte della parola).

Se fossi in te, lo farei per l'ultima parte ...

Assumili per un progetto molto piccolo (ma realistico). Guarda come codificano, prendono decisioni, assimilano le condizioni di lavoro, i membri del team, ecc., E quindi in base a quello, prendono la decisione finale.

Non inappropriato, ma ricorda che alcune persone (e forse una quota maggiore della folla dei programmatori) possono essere molto stressate in un'intervista. Penso che molti di noi conoscano il ragazzo dell'ufficio che è un programmatore brillante e una persona molto affidabile, ma si scioglierebbe in una situazione del genere. Le sue prestazioni non sono state misurate in un test del genere, quindi non fare di questo un test go / no go.

Personalmente penso che questa sia una delle cose migliori che puoi fare. Come hai detto che non cerchi la sintassi corretta o qualcosa di simile, la parte più importante qui è vedere se qualcuno può comunicare ... Ho visto tanti bravi sviluppatori che possono lavorare da soli solo nel loro spazio ... Sfortunatamente questo non è possibile in una grande quantità di casi, quindi avere un ragazzo esperto che è anche in grado di dire ciò che pensa in modo chiaro e conciso è un membro più valido della squadra di qualcuno che pensa: "Non lo capiranno comunque lo farò da solo e lo dimostrerò più tardi ".

Comunicazione, comunicazione, comunicazione che è la base di ogni progetto di dimensioni medio-grandi (anche una volta più piccoli ne hanno bisogno)

Penso che non sia una cosa ragionevole. Cerchiamo di trovare candidati, che siano bravi nel compito che vogliamo che facciano. Scrivere codice su una lavagna non è uno di questi e non credo sia un filtro valido per trovare buoni candidati.

• Il buon codice non viene scritto, viene riscritto. Una lavagna è praticamente immutabile, poiché è difficile cambiarla dopo averla scritta. Dovrebbe essere il più semplice possibile cambiare idea non appena si capisce meglio il problema.
• Partecipare a un colloquio è una situazione stressante così com'è, non è necessario esercitare ulteriore pressione sul candidato. Molte persone di computer non hanno una buona calligrafia. Gli IDE moderni offrono molti strumenti a cui sei abituato. E essere in grado di google qualcosa nel momento in cui ti serve è anche parte dello stile di lavoro della maggior parte dei programmatori. Perché togliere tutte queste cose e creare un ambiente artificiale, in cui non dovranno mai lavorare se le fai un'offerta?
• Siamo anche molto interessati alla capacità di scrivere buoni test, forse anche fare TDD. Questo non è possibile vedere durante la codifica della lavagna.

La maggior parte degli indizi che potresti trarre da una sessione di programmazione della lavagna potresti anche uscire da una sessione di accoppiamento - E credo che l'abbinamento sia uno strumento molto migliore per avere un'idea, di come un candidato risolve un problema e di come lavora. Può portare il proprio computer e lavorare in un ambiente con cui si trova a proprio agio. Ed è molto più facile fare domanda per l'attività che vuoi che facciano dopo essersi uniti. Ad esempio, abbiamo una base di codice legacy di grandi dimensioni, quindi chiediamo loro di refactoring del codice estratto per il progetto reale. E in realtà ci accoppiamo il più possibile nel nostro lavoro quotidiano, quindi è perfetto.

Mentre una sessione di lavagna probabilmente aiuta a filtrare i cattivi candidati, probabilmente filtra anche molti buoni programmatori.

Personalmente, vorrei uscire da qualsiasi intervistatore che mi chiedesse di fare FizzBuzz. Non so quando questo è diventato il nuovo standard del settore, ma è davvero una perdita di tempo. FizzBuzz è un filtro che può essere utilizzato prima di un'intervista, anche se personalmente penso che se dovessi scegliere tra N candidati di cui abbastanza ho un codice open source o un blog che posso guardare, lo preferirei sicuramente come filtro .

In poche parole, penso in un'intervista per una posizione di programmazione (tranne forse per junior o stage), dovrebbe già essere stato stabilito / determinato che l'intervistato può programmare.

Sì, la lavagna è perfetta, anche se penso che dovresti affrontare una serie diversa di problemi. Lancia loro un problema del mondo reale e invitali a disegnare un mucchio di squibble UML per spiegare la loro strategia generale per risolvere quel problema. Offri loro un computer con Internet, in modo che possano cercare librerie di terze parti che potrebbero usare come scatole nere nel loro scenario.
In pochi minuti, vedrai davvero come affrontano i problemi. Puoi effettivamente renderlo una cosa molto interessante, selezionando i problemi per i quali non hai necessariamente una soluzione in mente e tentando di "risolverli" insieme, per vedere quanto bene comunicano e quanto bene possono incorporare input (comunque don non spingerli troppo forte - alcune persone potrebbero bloccarsi se lo fai). E quindi aggiungere alcuni requisiti al volo. Questo è un po 'come lo sviluppo di software senza implementazione e, soprattutto, senza debug, quindi 15 minuti sono un sacco di tempo.

Lasciami rispondere con un'altra domanda:

Scrivere codice su una lavagna bianca offre qualche reale vantaggio nella valutazione della capacità di programmazione, rispetto alla digitazione e all'esecuzione del codice su un computer?

Penso che sia assolutamente appropriato chiedere a un candidato di scrivere il codice in un'intervista. Tuttavia, per me, essere in grado di eseguire il codice è una parte fondamentale del circuito di feedback che costituisce la programmazione. Su una lavagna bianca, mi stai legando una mano dietro la schiena e non hai il quadro completo di come lavoro un problema.

No, ma IMO un approccio migliore sarebbe usare la lavagna per lo scopo previsto e usare UML / schizzi / note per qualche progetto fittizio, piuttosto che il vecchio "scrivimi una query sql per ottenere tutti i record" o "scrivi un metodo che inverte una stringa ".

Una delle migliori interviste che ho avuto è stata passare circa 20 minuti a discutere con lo sviluppatore principale l'architettura (non software) per la dimora di uno scienziato pazzo (completo di nascondiglio segreto, raggio della morte e canile). Ha avuto modo di vedere il mio approccio nel risolvere i problemi, e il problema era qualcosa di divertente, non tipico della programmazione programmata di 101 cose che è stata risolta dai linguaggi moderni mille volte. Per inciso ho anche fatto un pezzo di codice come questo prima, ma mi sentivo molto più "sotto pressione" che con la parte dell'architettura.

In questi giorni, molta programmazione è fatta in team. Per far funzionare le squadre, le persone devono essere in grado di comunicare. Gran parte di questo è la capacità di comunicare di fronte a una lavagna (brainstorming, mentoring, correzione di codici proposti, ecc.)

Vorrei sapere se il candidato ha spiegato come procedere alla soluzione di un problema di programmazione utilizzando il codice della lavagna per assistere. Se la spiegazione è abbastanza buona, gli altri bravi programmatori nella stanza correggeranno mentalmente qualsiasi errore di battitura / errore sulla scheda.

Per la maggior parte dei tipi di posizioni di squadra, sarebbe irragionevole NON aspettarsi che un candidato sia in grado di spiegare e scarabocchiare il loro tentativo di soluzione.

No, è una buona cosa codificare per un colloquio, ma dovresti consentire il codice in qualsiasi lingua ragionevole poiché di solito è più facile addestrare un programmatore concorrente in un'altra lingua che ottenere un programmatore così così nella lingua che desideri, su a un livello competitivo.

Direi che è appropriato, ma nella maggior parte dei casi non è un modo efficace per scoprire chi è bravo in programmazione e chi no. Se vuoi fare un lavoro (= assumere qualcuno che sia capace), allora l'intervista dovrebbe concentrarsi sulla misurazione delle abilità della vita reale. Finora la migliore intervista con cui avevo lavorato in questo modo:

• Saluti, benvenuti dalle risorse umane.
• Poche parole su di me, sull'azienda, ecc ... e ha spiegato il resto dell'intervista.
• Mi ha dato un laptop con un programma che mancava poche parti, a causa di ciò aveva fallito i test unitari. Le parti mancanti sono state commentate lì come testi, si trattava di implementare un'attività di base, come creare una connessione tra poche classi e introdurre una semplice logica aziendale.
• Se tutto è andato bene, i test unitari sono diventati verdi.
• Salutando, e accordo di tornare tra pochi giorni.
• Quel giorno il leader si è incontrato con me e mi ha chiesto del programma finito, cosa ho fatto e perché.
• Anche questo leader mi ha fatto domande sulle mie esperienze passate e su alcune altre domande.

Riassumendo: se stai cercando forza lavoro in un codice di produzione, testa le loro abilità in un ambiente reale. Se sei curioso delle loro conoscenze teoriche, è meglio chiedere loro di queste cose. Se sei spogliato dall'IDE, o sei nervoso perché devi programmare sulla lavagna bianca davanti a qualcuno, posso capire, specialmente nell'IT le persone a volte sono introverse e molti di noi non riescono a gestire bene queste situazioni, quindi su bianco a bordo la nostra efficienza avrà un aspetto peggiore di quello che realmente è.

Non lo trovo irragionevole a meno che l'intervistato non abbia una brutta calligrafia (o dovrei dire boardwriting) :-). Inoltre l'unica differenza nel tuo approccio è l'uso di una tavola e di un marker. In alcuni casi gli intervistatori fanno questa cosa, ma invece danno un foglio e una penna. Nel caso ci siano 3-4 persone che conducono il colloquio, direi che il tuo approccio sarà molto migliore e adatto.