“Test” della lavagna durante un'intervista: modo legittimo per eseguire il backup del codice (lavagna)? [chiuso]


15

Come ho capito, avere un errore (anche un errore di battitura o ";" mancante) nel codice della lavagna ti costerà spesso alcuni punti di intervista. Evitare ciò renderà inevitabilmente più volte un codice di correzione (perdendo tempo e possibilmente energia / concentrazione neurale) o persino usando un algoritmo più semplice (e quindi meno efficace) - ed entrambi questi modi sono di nuovo "costosi"!

Quindi, perché non solo scrivere velocemente un codice così elegante ed efficace come avresti un framework di test (unit) a tua disposizione e poi semplicemente testarlo (solo sulla lavagna)?

Qualcuno ha provato / visto questo approccio? L'intera idea è degna?

[questo vale ovviamente anche per il caso carta e penna]


23
Se avessi voluto che qualcuno scrivesse codice su una lavagna o su un foglio durante un'intervista, non mi aspetterei che sia sintatticamente corretto al 100% - questo li mette troppo sotto pressione. Sì, dovrebbe essere ampiamente corretto, ma mancare i punti e virgola o anche ottenere un nome di metodo / profilo di parametro leggermente sbagliato è (o dovrebbe essere) OK.
ChrisF

17
Sono un grande fan del codice della lavagna nelle interviste, ma chiunque si aspetti che il codice della lavagna sia sintatticamente perfetto lo sta facendo male. Il punto è vedere come si attacca un problema, non vedere che è possibile produrre un codice sintatticamente perfetto in un ambiente totalmente non realistico.
Tim Goodman,

3
dovresti essere in grado di dire quale sia chiedendo loro di fare un commento in corso su ciò che stanno facendo ad esempio o discutendo la soluzione con loro dopo che hanno finito.
ChrisF

6
Essere eccessivamente preoccupati per la sintassi e l'ortografia esatte costerà i punti dell'intervistatore nel mio libro.
JeffO,

2
questo è il codice psuedo per
jk.

Risposte:


49

Voglio assolutamente che testiate il codice della lavagna che vi chiedo di scrivere. Voglio che tu parli ad alta voce mentre lo scrivi, guardalo oltre, individua la maggior parte degli errori di sintassi che hai fatto e fai notare come potrebbe essere più efficiente. In effetti, questo è un po 'il punto di farlo alla lavagna. E ' non è un one-shot, write-it-all-out, uh-huh-you-get-70/100 genere di cose. È una conversazione, mediata dal codice e tenuta alla lavagna invece che sulla mia scrivania.

Ecco alcuni ottimi modi per fallire il test "Codifica lavagna":

  • rifiutalo
  • non fare una sola domanda di chiarimento (lingua, piattaforma, qualcosa sui requisiti) E non dirmi i tuoi presupposti su di esso E fare ipotesi che sono molto lontane da ciò a cui avrei risposto

(ad esempio: scriverlo in Fortran, interpretare "display" o "print" come "scrivere nel registro eventi", quel genere di cose. Potrei permetterlo se mi dicessi in anticipo quali erano i tuoi presupposti)

  • chiedimi in quale lingua lo desidero, ricevi una risposta nella descrizione del lavoro, quindi scrivila in un'altra lingua perché non ti senti a tuo agio nella lingua richiesta.

(Siamo consulenti qui. Sto testando il comportamento del consulente tanto quanto la codifica. Chiedere al cliente è corretto solo se il cliente ha effettivamente una scelta. Controllare le conversazioni con le persone che ti pagheranno è difficile. Questa è la lezione 1. È un segno contro di te su qualsiasi argomento, ma per lo specifico "stai assumendo un programmatore X ma non voglio scrivere in X per te" ora hai due grandi segni neri.)

  • mostrami che sei un astronauta dell'architettura riempiendo due lavagne con interfacce, schemi di fabbrica, astrazioni, iniezioni e test quando volevo che "stampassi i numeri da uno a 5".

(pensi che sto esagerando ma ho avuto un ragazzo che ha generalizzato il mio problema in modo drammatico - attenendosi all'esempio sopra diciamo che invece di 1 a 5 la sua soluzione farebbe qualsiasi sequenza arbitraria di numeri interi (ottenuto da dove? Mi chiedevo) ed era 5 volte più a lungo di chiunque altro - e si è dimenticato di chiamare effettivamente la funzione che ha svolto il lavoro. Ripetuti suggerimenti e suggerimenti che lo percorrevano come se fosse il debugger non ha portato a notare che la funzione non è mai stata chiamata.)

Dico sempre "ti piace?" "puoi migliorarlo?" "guidami attraverso quello" e simili. In genere il punto e virgola mancante viene individuato, o off-by-one, in quella conversazione. In caso contrario, di solito lo contrassegno fino ai nervi.

Altre cose che potresti non pensare siano importanti alla lavagna che contano per me:

  • quando hai finito, posso ancora leggerlo? Hai sbavato, scarabocchiato, cambiato colore, frecce disegnate, barrato e generalmente lasciato un casino che non può essere usato ora? O sei consapevole del fatto che le lavagne sono cancellabili, hanno indicato linee di codice nell'aria invece di cerchiarle / farle scorrere e mi hanno lasciato qualcosa di cui avrei potuto scattare una foto e conservarla nel file di progettazione?
  • quanto mi hai chiesto come hai fatto? Ti piace essere lasciato solo e non discutere il tuo codice o lo vedi come una cosa collaborativa? Come hai risposto quando ti ho chiesto le cose mentre le stavi ancora scrivendo?
  • hai ghignato per il compito "facile" o svenuto per quello "duro"? Sei stato scortese riguardo alla richiesta di mostrare che puoi programmare? Sei facilmente intimidito da un problema tecnico o arrogante riguardo alla tua capacità di elaborare un buon algoritmo?
  • lo stai risolvendo nella tua testa o ricordi una soluzione che hai letto da qualche parte? Di solito posso dire per i problemi difficili.
  • hai pianificato in anticipo dove hai iniziato a scrivere? Le persone che finiscono la lavagna di solito iniziano troppo in basso o scrivono troppo in grande - posso dire che non sapevano che sarebbero state 20 righe di codice e quindi hanno lasciato spazio solo a 5 - che ci crediate o no, questo piccolo dettaglio è rispecchiato in anche compiti di stima più grandi.
  • l'hai guardato prima di dire che avevi finito? Ti ho visto indicarti o toccarti e testarlo tu stesso prima che te lo chiedessi? Quando ti ho chiesto o ti ho fatto domande specifiche a riguardo, l'hai guardato di nuovo o sei semplicemente passato dalla memoria? Sei disposto a considerare che la tua prima bozza potrebbe non essere completa?

Consiglio vivamente di praticare la programmazione alla lavagna. Avvertisco sempre gli intervistati che verrà loro chiesto di farlo. Se hai accesso a una lavagna reale, poniti alcuni semplici problemi e fai pratica facendoli lì. Aiuterà le tue prestazioni e la tua sicurezza.

Mi dispiace, lo so che mi trovo in TL; territorio DR, ma ecco la cosa: la codifica alla lavagna non riguarda solo la codifica . È un test che va oltre la semplice comprensione della sintassi. Ci sono molti comportamenti di buoni programmatori che sono dimostrati nella tua risposta a questo compito. Se pensi che si tratti solo di codificare, ti manca il punto.

In altre conversazioni sui test della lavagna, le persone mi dicono che potrei rifiutare un buon candidato con esso. Onestamente, è un rischio che sono disposto a correre. Ogni giro di assunzioni contiene diverse persone che potrei assumere. Alcune persone con ottimi curriculum, che stanno bene nella parte dell'intervista, rispondono alla lavagna e chiaramente non possono (con qualsiasi suggerimento) scrivere un semplice codice nella lingua che dichiarano di conoscere. Potrei aver assunto alcuni di questi. Qualsiasi strumento che lo impedisce è uno strumento che continuerò a utilizzare. Non sono mai finito in nessuno a noleggiare una barca perché tutti i miei candidati hanno incasinato la lavagna e non mi aspetto che lo farò mai.


2
Sembra essere un'ottima risposta (e ad essere sincero molto più interessante che inizialmente speravo di ricevere). Molte molte grazie.
mlvljr,

9
@KingOfHypocrites hai effettivamente letto la risposta? Non mi interessa perdere un punto e virgola. Guarda cosa dice che mi interessa. 20 minuti alla lavagna mi dicono molto su di te.
Kate Gregory,

7
Sono curioso di sapere se qualche ricerca ha convalidato l'intervista alla lavagna. Divulgazione completa: sono diventato curioso dopo aver fallito un'intervista con la lavagna, difficile. Non intervisto da alcuni anni, non sono mai stato un buon interprete / presentatore e mi sono praticamente congelato. Le tue intuizioni sono eccellenti e se avessi letto questo prima avrei pensato a quella parte del processo dell'intervista in modo molto diverso (e avrei parlato di più). Detto questo, molte persone hanno opinioni forti su questo argomento, ma sembra essere tutto. Presumo che vi sia una giustificazione obiettiva per questa pratica, supportata da dati di supporto. È lì?
Suboptimus,

3
+1 Ad essere sincero, mi avvicinerei alla lavagna come proxy per un esercizio di programmazione in coppia, sperando di tenere un flusso di conversazione sull'attività come suggerisce Kate - anche se preferirei avere una macchina e in realtà abbinare il programma con il candidato (o essere la coppia candidato alla programmazione con l'intervistatore). Il modo in cui codifichi insieme è importante quanto il codice da solo, in un'organizzazione di qualsiasi dimensione.
Julia Hayward,

4
So che questo è vecchio ma mi sono appena collegato ad esso e volevo sottolineare: uno dei tratti distintivi di un disturbo dell'elaborazione visiva è la mancanza di capacità di stimare lo spazio in cui stai scrivendo e quindi finendo per esaurire lo spazio . Se la persona che stai valutando non solo esaurisce lo spazio per più righe, ma ha anche caratteri più piccoli verso la fine di una riga quando si rendono conto di aver iniziato troppo grande, potrebbero avere solo una disabilità di apprendimento piuttosto che non capire quanto tempo sarà il codice. Chiedi loro di stimare qualcosa di non spaziale e potresti ottenere un risultato migliore.
Yamikuronue,

17

Penso che tu abbia fatto un'ipotesi errata qui. Non mi aspetto che un candidato che scriva codice su una lavagna sia in grado di ottenere ogni ";" perfettamente a posto. Se stai intervistando in un posto che ti penalizza per questo, ti suggerisco di non essere un'organizzazione per cui vuoi lavorare :-).


2
Ho fallito un'intervista perché, come si diceva, non avevo scritto un codice perfettamente ottimizzato al primo passaggio di un test su carta e penna (essendo della scuola get-it-working-with-unit-test-then-optimise ). Inoltre, non disponevano di un framework di test, ma presumevano solo di avere programmatori che lo facessero per la prima volta!
Julia Hayward,

3
@JuliaHayward - Una fuga fortunata per te dai suoni! Non riesco a credere che la gente lo faccia ancora.
Martijn Verburg,

7

I test su carta o lavagna sono estremamente inefficaci. Ricordo che una volta ho avuto un'intervista in cui ho dovuto cercare errori in alcuni codici su carta. Uno di questi era che la classe ereditava da un'interfaccia ma mancava l'implementazione di un membro. Sapevo che questo sarebbe stato probabilmente uno degli errori, lo stavo cercando e per qualsiasi motivo sul posto non riuscivo a vederlo (anche se ho menzionato che lo stavo cercando come uno dei problemi).

A quanto pare, ho ancora ottenuto quel lavoro, ma mi ha fatto pensare a quello che era successo. In uno scenario realistico per quel genere di cose, ho intenzione di ottenere linee ondulate nel momento in cui qualcosa non va (questo è C # in Visual Studio) e la cosa non si compila. Non lo controllo mai nella vita reale perché non succede mai (è impossibile) e quindi sono fuori sintonia dal vedere questo genere di cose. I punti e virgola mancanti sono un esempio ancora più estremo di questo: totalmente irrealistico nel mondo reale a meno che tu non stia scrivendo nel blocco note e inviando il tuo codice a qualcun altro per compilarlo!

Se qualcuno chiede di usare una lavagna durante un'intervista per supportare qualcosa che vogliono dire, allora sarebbe fantastico, ma non lo farei mai al contrario.


2
La tua storia sembra dimostrare che il tuo test è stato efficace. Invece di chiedere "Come riesaminare il codice?" ti hanno dato un po 'di revisione. Hai parlato a voce alta e hai detto qualcosa del tipo "devi assicurarti che implementi tutto" e anche se non ti è capitato di individuare quello mancante, hai mostrato loro che in realtà sai come rivedere il codice per gli errori, non solo rispondere a domande al riguardo . Probabilmente, inoltre, non hai indicato un mucchio di non errori che alcune persone potrebbero avere e forse hai visto anche altri errori. E poi hai ottenuto il lavoro. Mi sembra efficace, per tutti!
Kate Gregory,

2
Inoltre, i punti e virgola mancanti continuano a essere respinti come non un vero negativo. Digitare in modo coerente la sintassi della tua lingua preferita significa che sei uno sviluppatore più lento di qualcuno che ha interiorizzato tutta quella sintassi. Stai costantemente tornando indietro e aggiustando cose che hai dimenticato. Ci sono buone probabilità che ti venga sbalzato dal ritmo con il costante fastidio dell'IDE. Inoltre, le persone che lasciano tutti i loro punti e virgola sulla lavagna e non si accorgono quando li chiedi non sono allo stesso livello dei bravi sviluppatori che una volta alla settimana dimenticano di digitare un punto e virgola nell'IDE e poi risolvono esso.
Kate Gregory,

2
+1 è inefficace. Non dimostra assolutamente nulla. Sono abbastanza sicuro che molte persone che falliscono il test sono meglio del ragazzo medio che lo supera.

3
@Kate: capisco da dove vieni, ma non sono d'accordo, specialmente perché ora mi siedo dall'altra parte del tavolo. Se a qualcuno mancano dei punti e virgola regolarmente, voglio vederlo nell'IDE non in un ambiente artificiale. È come il codice di accesso al mio ufficio: posso digitare il numero senza pensarci, chiedermi di scriverlo con la sicurezza del 100% e farei fatica. Un'intervista non sarà mai realistica al 100%, quindi non voglio fare di tutto per renderla ancora meno.
Finlandia,

1
È molto meno probabile che ometta una sintassi importante sulla tastiera rispetto a una lavagna, perché la digitazione è rafforzata dalla memoria muscolare. Tuttavia, il mistyping (e un fastidio del mio editor, o del partner di coppia), specialmente in una situazione di programmazione di coppia, è probabile che mi metta in un ciclo di feedback in cui gli errori rinforzano i nervi che causano errori. Penso che i poliglotti siano probabilmente svantaggiati rispetto ai candidati monolingue.
apertura del

5

L'ho fatto. Durante un'intervista mi è stato chiesto di implementare la codifica di lunghezza normale sulla lavagna, e mentre abbreviavo un po 'del codice (spiegando che cosa stavo abbreviando) per adattarmi alla lavagna, ho comunque trovato una raccolta di test per questa unità, e ne ho seguito uno per convalidare la mia soluzione e mostrare come il test avrebbe aiutato. Mi è stata offerta quella posizione, quindi presumo che il test sia stato utile o, nel peggiore dei casi, non fastidioso.


4

Uso questo approccio quando faccio i test per la scuola. Prima scrivo la funzione, poi a lato scrivo una piccola tabella di ingressi, uscite e var. Ho colto alcuni errori stupidi in questo modo. Testare, anche su carta / lavagna, è sempre meglio che non testare.

Non sono d'accordo con il fatto di impazzire per i punti e virgola in un ambiente professionale, però.


4

Chiedere a un candidato di scrivere un codice su una lavagna è stupido. Esistono strumenti moderni come snippits, jsfiddle e intellisense. Inoltre, nessun ingegnere dovrebbe essere tenuto a memorizzare la sintassi. La sintassi viene cercata e referenziata. Se stai memorizzando il codice, probabilmente non hai dedicato del tempo alla tua carriera per imparare a programmare in un ambiente multi-tenant, ottimizzando la sintassi o persino un ambiente ospitato.


3
Chiunque sia a metà decente in una determinata lingua dovrebbe avere la sintassi memorizzata dal semplice utilizzo di essa. Se un ragazzo scrive il codice C # tutto il giorno e non conosce la maggior parte della sintassi dalla parte superiore della sua testa, sarà lento e terribile. Puoi anche cercare cos'è 2 ^ 8, ma ogni sviluppatore degno del suo sale dovrebbe sapere cosa è fuori di testa solo dopo averlo incontrato così spesso. Lo stesso vale per la sintassi.
whatsisname

1
Questo semplicemente non è vero. Memorizzare la sintassi in questo giorno ed età non è necessario. Dire che gli sviluppatori che sanno codificare in numerosi linguaggi come sql, vb, c #, javascript e usano json, angularjs, telerik e altri non valgono la pena perché non sono in grado di memorizzare la sintassi è sciocco. C'è di più nell'essere un buon ingegnere del software che gli operatori matematici come la tua lista. Che ne dici di comprendere requisiti, strutture di progettazione, modelli, esperienza nel settore? C'è letteralmente abbastanza sintassi in lingue e librerie per riempire il retro di un camion.
James Bailey,

Non si tratta di essere "necessario". È che se usi qualcosa abbastanza spesso, lo ricorderai. Se un ragazzo afferma di essere uno sviluppatore di SQL ma non riesce a scrivere un'istruzione join dalla cima della sua testa, è perché è a) incompetente b) mentiva sulle sue qualifiche, oppure c) ha un cervello molto strano, tutto tre situazioni che non voglio affrontare.
whatsisname

1
Un "join" non è ciò che viene generalmente richiesto su una lavagna. Spesso sono enigmi e cose non rilevanti per il lavoro. Che cosa succede se il candidato è certificato, ha una laurea e ha un curriculum solido. Pensi ancora che sia "incompetente" perché non codifica su una lavagna bianca per vivere? Ai professionisti del marketing non è richiesto di elaborare una strategia di marketing trimestrale sui punti di colloquio. È sciocco. Dovresti essere in grado di parlare con il candidato e di dedurre facilmente se è in grado di programmare.
James Bailey,

3

Quando un ristorante vuole assumere uno chef, il proprietario non gli chiede di cucinare una "pot au feu" con uno stecchino e un berretto.

Non chiedere a uno sviluppatore di scrivere il codice su una lavagna durante un'intervista.


3
E quando è stato chiesto?
mlvljr,

Durante l'intervista

3

La codifica della lavagna è dura. Non mi è mai stato presentato fino a quando non sono stato intervistato dalla Disney. Non sapendo cosa aspettarmi e non potendo eseguire il debug, mi sono imbattuto in esso parlandolo e risolvendo il problema, ma in un modo pseudo-codice. Quando hanno chiesto potrebbe funzionare.

Voglio dire, potresti semplicemente dover correggere gli errori di sintassi, giusto. Credo che abbiano perso un ottimo candidato se non fossi assunto a causa della lavagna. Guardo le qualifiche e sembra che io sia qualificato per la posizione e posso fare il lavoro. Eccello nell'attuale lavoro in cui mi trovo e vorrei poterlo fare con loro.

Grazie per il tuo contributo Kate, ho letto ogni parola. È solo per me come programmatore, la lavagna non mostra davvero le tue abilità. Sono un grande programmatore che lavora in più lingue. Conoscevo la lingua in cui mi era stato chiesto di programmare, ma all'improvviso mi sono dimenticato sulla lavagna.

Costruisco un'integrazione complessa e l'elaborazione delle carte di credito, ma sulla lavagna bianca non riuscivo a ricordare come nemmeno fare la sintassi corretta non mi suggerisse nulla.

Come datore di lavoro mi piacciono i test sulla lavagna bianca; tuttavia, sto assumendo un programmatore che voglio vedere le loro reali capacità se fanno il lavoro. È fantastico se possono comunicare, ma devo vederli in grado di risolvere i problemi.


1
Grazie per l'input, a quanto pare, è giusto quello che stavo pensando quando ho posto la domanda: si può davvero rimanere bloccati in un codice di lavagna senza sapere se è (già) corretto e non avere mezzi per "effettivamente" controllarlo. Una soluzione complicata: scrivi un test sulla lavagna! ;)
mlvljr
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.