Come gestire un colloquio "codice errato"? [chiuso]

Un'intervista con "codice errato" è quella in cui all'intervistato viene mostrato uno snippet di "codice errato" e viene chiesto di correggerlo o di segnalare cose che non vanno. Ho problemi con queste interviste perché mi ci vuole del tempo per leggere il codice, capire cosa sta facendo e sottolineare i difetti. In una situazione in cui c'è la pressione del tempo, tendo a congelarmi e vedo che il codice "dovrebbe" funzionare, anche quando non lo fa.

Qual è un buon modo per gestire questo tipo di intervista e, più in generale, quali sono alcune buone tecniche per leggere e comprendere rapidamente il codice ?

Le interviste con codice errato (se eseguite correttamente) dovrebbero mostrare il codice con quanto segue:

• Una tecnica del linguaggio scorretto (non usare l' usingistruzione in C # quando necessario, o usando un ArrayListinvece di a List<T>)
• Una cattiva decisione di progettazione (perché diamine stiamo passando stringhe ovunque, o usando refe outparametri così tanto?)
• Errori di sintassi (questo non dovrebbe nemmeno compilare!)
• Errori di runtime (come un overflow dello stack causato da una proprietà che fa riferimento a se stesso in C #)

C'è una lista di controllo mentale che dovresti esaminare, colpendo ciascuno dei punti sopra. Se non riesci a guardare il codice e farlo, questo è un punto di miglioramento. Qualunque sia la lingua in cui affermi di essere "competente", dovresti essere in grado di esaminare un blocco di codice e sottolineare questi quattro tipi di errori.

Di recente ho scritto un blog su un pezzo di codice che mostrava tutti questi problemi , dovrebbe aiutarti a seguire lo stesso processo mentale.

Ayende lo approfondisce con la sua serie Wages of Sin .

Non cercare di capirlo rapidamente. L'obiettivo qui non è vedere se riesci a capire il codice come un guru, ma piuttosto vedere come pensi.

La chiave IMO è semplicemente pensare ad alta voce. Quindi, anche se ti congeli, dì semplicemente "Sto sottolineando qui, ma lasciami passare lentamente ad alta voce".

Supponendo che tu abbia l'abilità di pensare ad alta voce, ti rallenterà abbastanza da avere la mente giusta. Se le interviste sono abbastanza intelligenti, vedranno la tua situazione e ti aiuteranno fino a quando non stai pensando chiaramente. Non sono fatti per cercare di indurti a sembrare stupido - solo una potente tecnica per vedere come pensi.

Le probabilità sono che la "pressione del tempo" che senti sia totalmente autoimposta. Ha più a che fare con i tuoi sentimenti di insicurezza e preoccupazione per quanto bene ti alzi.

Il miglior consiglio che chiunque può dare è: Rilassati. Prenditi il ​​tuo tempo, guarda il codice e parla solo di ciò che vedi mentre lo vedi. Sentiti libero di parlare delle parti buone e di quelle cattive; ti aiuterà a ridurre il tuo nervosismo e le preoccupazioni interiori che passa troppo tempo.

Inoltre, passare attraverso diversi "passaggi" potrebbe rendere un po 'più semplice individuare dettagli specifici. Fai un passaggio alla ricerca di parentesi graffe o errori di battitura non corrispondenti. Prendi un altro passaggio alla ricerca di linee offuscate. Prendine un altro alla ricerca di pretzel semantici. Concentrarsi su un tipo di "cosa sbagliata" potrebbe rendere più facile individuare quei dettagli e (di nuovo) ridurre la tua voce interiore chiedendoti se lo stai facendo velocemente / abbastanza bene.

Soprattutto, parla attraverso quello che stai facendo e pensando - aiuterà entrambi e l'intervistatore.

Non sono mai stato in questo tipo di intervista, ma quando sto cercando di lavorare su un codice complicato che potrei sospettare di essere cattivo, a volte parlo piano con me stesso. Trovo che a volte vocalizzare aiuti a risolvere i problemi. Anche in un'intervista, potresti provare a tracciare le fasi dell'esecuzione come un diagramma o qualcosa con una matita e un foglio di carta. Questo funzionava per me a scuola, lo faccio ancora a volte al lavoro. YMMV, ovviamente ...

Penserei che un buon punto di partenza (se non vedi nulla di ovvio) sarebbe "debug". A meno che non si vedano possibili problemi fin dall'inizio, un buon punto di partenza è fare un piccolo elenco di valori di prova. I buoni valori sono un valore "normale" (normale), un valore "zero" o "vuoto", valori null, un valore molto piccolo (una stringa di 1 carattere, int 1, ecc.), Un valore molto grande o molto lungo valore e "strani" valori specifici del tipo (ad es. caratteri Unicode per stringhe, numeri negativi per ints, ecc.). Qui non sarebbe male menzionare che normalmente si scriveranno unit test usando questi valori per testare il codice e si eseguiranno semplicemente quelli per verificare la funzione.

Inizia camminando con i tuoi valori del percorso felice. Per una funzione di aggiunta, potresti iniziare con 3 o 4. Esamina ogni riga per errori di battitura ed errori logici, monitorando i valori delle variabili locali mentre procedi. Speriamo di trovare alcuni bug. Quando avrai finito con il percorso felice, avrai una sensazione migliore per il codice e speriamo che ti sentirai un po 'meno sopraffatto - quindi dì qualcosa del tipo: "Ora che ho una sensazione migliore per quello che sta facendo questo codice, sono fare un passo indietro e dargli un'occhiata, "quindi fare proprio questo - cercando cose che ti distinguono come cose che avresti fatto diversamente (cattive decisioni di progettazione, variabili mal nominate, indagare su possibili bug, ecc.).

Se ciò non ti porta da nessuna parte o se ritieni di aver esaurito le cose da dire, torna al tuo elenco di valori di prova e ripercorri con quello nuovo che ritieni possa causare problemi.

Questo almeno ti farà andare avanti.

Come ha detto Stephen Bailey, pensare ad alta voce è una tecnica eccellente in questa situazione in quanto consente ai tuoi intervistatori di vedere il tuo processo di pensiero. In un certo senso spiega cosa stai cercando di capire. L'altra cosa che potresti fare è far sapere agli intervistatori che leggerai correttamente il codice prima di fornire una diagnosi sulla cattiveria del codice. Sono stato su entrambi i lati del tavolo e so che può essere frustrante per entrambe le parti in queste situazioni.

Se senti meno pressione mentre lo fai come una prova scritta, quindi estrarre il notebook e iniziare a prendere appunti. Ho tirato fuori un quaderno e ho iniziato a disegnare appunti come parte del mio processo di pensiero in un'intervista. Avere un taccuino e una penna ti fa sembrare organizzato. Potresti scrivere alcuni punti elenco di cose da cercare, sintassi, errori logici, discrepanze tra i tipi di dati, valori delle variabili locali (l'elenco potrebbe variare in base al tipo di codice che hai, il mio elenco per un pezzo complesso di SQL sarebbe essere diversi da qualcuno che ha ottenuto un pezzo di codice che non era incentrato sui dati) mentre si procede attraverso il processo, ecc. Dopo averne scritto alcuni, iniziare a cercarli. In questo modo anche se non trovi tutti i problemi prima che l'intervistatore voglia andare avanti, sarà in grado di vedere un elenco delle cose che avresti controllato. Se crei in anticipo una lista di controllo di cose che potresti voler cercare, ti sentirai più sicuro di iniziare il processo sapendo quali cose hai pianificato di guardare. Di solito queste domande sono più su come trovare gli errori piuttosto che trovarli tutti.

Sono un po 'in ritardo per questa festa, ma una tecnica che potresti usare sarebbe quella di scrivere unit test per il codice in questione. Quindi puoi concentrarti di meno su ciò che è leggermente sbagliato nel codice e di più sui risultati attesi che stai cercando. Preferirei assumere qualcuno in grado di scrivere buoni test piuttosto che qualcuno in grado di individuare immediatamente ciò che non va in un pezzo di codice.

Potrebbero esserci due problemi:

Potrebbe essere una "intervista sullo stress" http://it.wikipedia.org/wiki/Job_interview#Stress . L'intervistatore sta cercando di capire come affrontare lo stress poiché il loro ambiente di lavoro è tale.

O

Potresti essere stressato te stesso. In tal caso dovrai gestire questo stress, ad esempio introspetto e vedere come puoi rimanere calmo.