La "White-Board-Coding" è inappropriata durante le interviste? [chiuso]

A mio avviso, è molto appropriato. Se vuoi che un lavoro faccia una particolare abilità, è del tutto appropriato che ci si possa aspettare che dimostri quella competenza al colloquio.

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

Se come candidato si affronta questa tecnica, prima di tutto rilassati. Si tratta di valutare te come programmatore e i tuoi processi mentali. Non si tratta della tua sintassi perfetta. Se crei un errore di sintassi, potrei interpretare il ruolo di un compilatore e dirti che il codice non riesce a compilare su una determinata riga e ti dà un messaggio di errore e vedere come rispondi. Allo stesso modo se aggiungi un; su un ciclo o un'istruzione if che si compilerebbe, riprodurrei il debugger e parlerò attraverso un singolo passaggio attraverso il codice. Di nuovo, non si tratta dell'errore, ma di come faresti fronte all'errore, e i tuoi processi mentali sono buoni.

My question is "Is it innappropriate / unreasonable to expect a programmer to write a code snippet on a whiteboard during an interview ?"

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

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

In secondo luogo, si noti che c'è sempre la paura di fallire, costantemente a scuotere il cervello della persona. "Cosa succede se rovino?", "Cosa succede se commetto un errore stupido". La maggior parte del cervello della persona è impegnata a controllare costantemente come stanno venendo fuori - solo pochi riescono a trattenere i nervi.

Quindi, in questo tipo di situazione, anche il meglio potrebbe finire vacillando.

For the last part we ask interviewees to do is write a small code snippet (4-5 lines) on the whiteboard and explain as they go through it

Va bene. Ma ancora, solo perché qualcuno non è in grado di spiegare qualcosa correttamente non significa che non lo conoscono bene. (La spiegazione è un modo di dire).

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

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

Non appropriato, ma ricorda che alcune persone (e forse una fetta maggiore della folla di programmatori) possono essere molto stressate in un'intervista. Penso che molti di noi conoscano il tipo dall'ufficio che è un programmatore geniale e una persona molto affidabile, ma si sarebbe sciolto in una situazione del genere. Le sue prestazioni non possono essere misurate in un test del genere, quindi non fare questo test go / no go.

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

Comunicazione, comunicazione, comunicazione sono le fondamenta di ogni progetto di dimensioni medio-grandi (anche più piccole una volta che ce n'è bisogno)

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

• Il buon codice non viene scritto, viene riscritto. Una lavagna è praticamente immutabile, dato che è difficile cambiare una volta che l'hai scritta. Dovrebbe essere il più semplice possibile per cambiare idea non appena capisci meglio il problema.
• Essere in un'intervista è una situazione stressante così com'è, non c'è bisogno di esercitare ulteriore pressione sul candidato. Molti computer non hanno una buona calligrafia. Gli IDE moderni forniscono molti strumenti a cui sei abituato. E essere in grado di google qualcosa nel momento in cui ne hai bisogno è anche parte dello stile di lavoro della maggior parte dei programmatori. Perché togliere tutte queste cose e creare un ambiente artificiale, che non dovranno mai lavorare se gli fai un'offerta?
• Siamo anche molto interessati alla capacità di scrivere buoni test, forse anche di fare TDD. Questo non è possibile vedere durante la codifica della lavagna.

La maggior parte degli indizi che potresti ottenere da una sessione di codifica della lavagna potresti anche uscire da una sessione di accoppiamento - E credo che l'accoppiamento sia uno strumento molto migliore per farsi un'idea, come un candidato risolva un problema e come lui lavora. Può portare il proprio computer e lavorare in un ambiente con cui è a suo agio. Ed è molto più facile da applicare all'attività che vuoi che facciano quando si uniscono. Per esempio, abbiamo una grande base di codice legacy, quindi chiediamo loro di rifattorizzare un codice estratto per il progetto reale. E in realtà accoppiamo il più possibile nel nostro lavoro quotidiano, quindi è perfetto.

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

Personalmente, andrei su 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 usato prima di un'intervista, anche se personalmente penso che se dovessi scegliere tra N candidati di cui avere abbastanza codice open source o blog che posso guardare, preferirei che fosse un filtro .

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

Ma sì, la lavagna è perfetta, anche se penso che dovresti prendere una serie diversa di problemi. Getta loro un problema del mondo reale e fagli trarre un sacco di squilibri UML-ish per spiegare la loro strategia complessiva per risolvere quel problema. Dare loro un computer con internet, in modo che possano cercare librerie di terze parti che potrebbero usare come black box nel loro squibblescape.
Entro pochi minuti, vedrai davvero come affrontano i problemi. In realtà puoi renderlo una cosa molto interessante, scegliendo problemi che non hai necessariamente una soluzione in mente e provi a "risolverli" insieme, per vedere come comunicano bene e quanto bene possono incorporare input (comunque don li spingere troppo strong - alcune persone potrebbero semplicemente bloccarsi se lo fai). E poi aggiungi alcuni requisiti al volo. Questo è un po 'come lo sviluppo di software senza implementazione e, soprattutto, senza debugging, quindi 15 minuti sono un sacco di tempo.

Lasciami rispondere con un'altra domanda:

La scrittura di codice su una lavagna bianca offre un 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 ciclo di feedback che costituisce la programmazione. Su una lavagna bianca, stai legando una mano dietro la mia schiena, e non ottieni il quadro completo di come lavoro attraverso 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 quella di spendere 20 minuti discutendo con lo sviluppatore principale dell'architettura (non software) per la villa di uno scienziato pazzo (completa di nascondiglio segreto, raggio della morte e cuccia per cani). Ha avuto modo di vedere il mio approccio alla risoluzione dei problemi, e il problema era qualcosa di divertente, non tipico di programmazione 101, che è stato risolto dalle lingue moderne migliaia di volte. Tra l'altro ho anche fatto un pezzo di codice come questo prima, ma mi sentivo molto più "sotto pressione" che con la parte di architettura.

In questi giorni, molta programmazione è fatta in team. Perché i team lavorino, le persone devono essere in grado di comunicare. Una grande parte di questo è essere in grado di comunicare di fronte a una lavagna (brainstorming, mentoring, code review proposte di correzione, ecc.)

Vorrei sapere se il candidato ha spiegato come risolvere la soluzione a un problema di programmazione usando il codice della lavagna per aiutare. Se la spiegazione è abbastanza buona, gli altri bravi programmatori nella stanza correggeranno mentalmente tutti i refusi / errori sulla lavagna.

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

No, è una buona cosa codificare per un colloquio, ma dovresti consentire il codice in qualsiasi linguaggio ragionevole in quanto è solitamente più facile addestrare un programmatore in un'altra lingua piuttosto che ottenere un coder così-così nella tua lingua vuole, fino ad un livello concorrente.

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

• Saluti, benvenuto da HR.
• Poche parole su di me, sulla compagnia, ecc ... e lei ha spiegato il resto dell'intervista.
• Mi ha dato un portatile con un programma che ha mancato alcune parti, a causa di questo ha fallito i test unitari. Le parti mancanti sono state commentate come testi, si trattava di implementare un'attività di base, come creare una connessione tra poche classi e introdurre una semplice logica di business.
• Se tutto è andato bene, i test unitari sono diventati verdi.
• Saluti e accordo sul ritorno in pochi giorni.
• In quel giorno il leader si è incontrato con me e ha chiesto del programma finito, cosa ho fatto e perché.
• Anche questo leader ha chiesto delle mie esperienze passate e poche altre domande.

Quindi, per riassumere: se stai cercando forza lavoro in un codice di produzione, prova le loro abilità in un ambiente reale. Se sei curioso delle loro conoscenze teoriche, è meglio chiedere loro queste cose. Se sei spogliato di IDE, o sei nervoso perché devi programmare su lavagna bianca davanti a qualcuno, posso capire, specialmente in IT le persone sono a volte introverse e molti di noi non sono in grado di gestire bene queste situazioni, quindi su bianco a bordo la nostra efficienza sembrerà peggiore di quanto sia in realtà.

Non lo trovo irragionevole a meno che l'intervistato non abbia una cattiva calligrafia (o dovrei dire la scrittura su commissione) :-). Inoltre l'unica differenza nel tuo approccio è l'uso di una tavola e un marcatore. In alcuni casi gli intervistatori fanno questa cosa, ma invece danno una carta e una penna. Se ci sono 3-4 persone che conducono l'intervista, direi che il tuo approccio sarà molto migliore e adatto.