Come gestire un'intervista per "codice errato"? [chiuso]

Le interviste con codice errato (se eseguite correttamente) dovrebbero mostrarti il codice con il seguente:

• Una tecnica di parolacce (non usando l'istruzione using in C # quando necessario, o usando un ArrayList invece di un List<T> )
• Una decisione di progettazione sbagliata (perché diamine stiamo passando stringhe ovunque, o utilizzando ref e out parametri così tanto?)
• Errori di sintassi (Questo non dovrebbe nemmeno essere compilato!)
• Errori di run-time (come un overflow dello stack causato da una proprietà che si riferisce a se stesso in C #)

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

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

Ayende lo utilizza in modo più approfondito 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 a vedere come pensi.

L'IMO chiave è semplicemente pensare a voce alta. Quindi, anche se si blocca, allora dì semplicemente "sto sottolineando qui, ma lascia che passi attraverso questo piano ad alta voce".

Supponendo che tu abbia l'abilità di pensare a voce alta ti rallenterai abbastanza da ragionare correttamente. Se le interviste sono abbastanza sagge, vedranno la tua situazione e ti aiuteranno fino a che non penserai chiaramente. Non sono fuori per cercare di ingannarti e farti sembrare stupido - solo una tecnica potente per vedere come pensi.

Le probabilità sono, la "pressione del tempo" che senti è completamente autoimposta. Ha più a che fare con i propri sentimenti di insicurezza e preoccuparsi di quanto bene si misura.

Il miglior consiglio che chiunque può dare è: Relax. 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 quelle cattive; aiuterà a ridurre il nervosismo e le preoccupazioni interne che passano troppo tempo.

Inoltre, passare attraverso diversi "passaggi" potrebbe rendere un po 'più facile individuare dettagli specifici. Fai un passaggio cercando parentesi graffe o errori di ortografia. Fai un altro passaggio cercando le linee confuse. 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 domanda interiore chiedendo se lo stai facendo in modo veloce / abbastanza buono.

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

Non sono mai stato in questo tipo di intervista, ma quando sto cercando di lavorare su un pezzo di codice difficile che posso sospettare di essere cattivo, a volte parlo tranquillamente a me stesso. Trovo che la vocalizzazione a volte aiuti a risolvere i problemi. Anche in un'intervista, puoi provare a tracciare i passi dell'esecuzione come un diagramma o qualcosa con una matita e un foglio. Questo lavoro per me a scuola, lo faccio ancora a lavoro. YMMV, ovviamente ...

Penserei che un buon punto di partenza (se non si vede nulla di ovvio) sarebbe "debuggarlo". A meno che tu non veda subito possibili problemi, un buon punto di partenza è fare una piccola lista di valori di test. I valori buoni sono un valore "normale percorso", un valore "zero" o "vuoto", valori nulli, un valore molto piccolo (una stringa di 1 carattere, l'int 1, ecc.), Molto grande o molto lungo valore e valori "strani" specifici per il tipo (ad esempio, caratteri Unicode per stringhe, numeri negativi per interi, ecc.). Qui non farebbe male menzionare il fatto che normalmente si dovrebbero scrivere dei test unitari usando questi valori per testare il codice, e si dovrebbe semplicemente eseguire quelli per verificare la funzione.

Inizia camminando con i valori del tuo percorso felice. Per una funzione di addizione, si potrebbe iniziare con 3 o 4. Esaminare ogni riga per errori di battitura e di logica, rintracciare i valori delle variabili locali mentre si va. Spero che trovi alcuni bug. Una volta terminato il percorso, avrai una sensazione migliore per il codice e speriamo si senta un po 'meno sopraffatto, quindi di' qualcosa del tipo, "Ora che ho una sensazione migliore di ciò che questo codice sta facendo, sono andando a fare un passo indietro e dare un'occhiata a questo, "poi fare proprio questo - cercando cose che spiccano per te come cose che avresti fatto in modo diverso (cattive decisioni di progettazione, variabili con nomi scarsi, investigare possibili errori, ecc.).

Se questo non ti porta da nessuna parte, o se ti senti come se avessi finito le cose da dire, torna al tuo elenco di valori di prova, e cammina di nuovo con una nuova che pensi sia probabile causa problemi.

Questo almeno ti farà andare.

Come ha detto Stephen Bailey, pensare a voce alta è una tecnica eccellente in questa situazione in quanto consente agli intervistatori di vedere il tuo processo di pensiero. Una sorta di spiegare cosa stai cercando di capire. L'altra cosa che potresti fare è lasciare che gli intervistatori sappiano che stai andando a leggere correttamente il codice prima di fornire una diagnosi sulla cattiveria nel codice. Sono stato su entrambi i lati del tavolo e so che può essere frustrante per entrambe le parti in queste situazioni.

Se ti senti meno stressato come test scritto, estrai il notebook e inizia a prendere appunti. Ho tirato fuori un taccuino e ho iniziato a delineare 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, mancate corrispondenze di tipo di dati, valori di variabili locali (l'elenco può variare a seconda del tipo di codice che hai, la mia lista per una parte complessa di SQL sarebbe essere diverso da qualcuno che ha ottenuto un pezzo di codice che non era incentrato sui dati) durante il processo, ecc. Una volta che ne hai scritto alcuni, inizia a cercarli. In questo modo, anche se non trovi tutti i problemi prima che l'intervistatore voglia andare avanti, lui / lei sarà in grado di vedere una lista delle cose che hai intenzione di controllare. Se crei in anticipo una lista di cose che potresti voler cercare, allora ti sentirai più sicuro iniziando il processo sapendo quali cose hai pianificato di guardare. Di solito queste qiestions sono più su come si potrebbero trovare gli errori che in realtà trovandoli tutti.

Sono un po 'in ritardo per questa festa, ma una tecnica che potresti usare sarebbe scrivere dei test unitari per il codice in questione. Quindi puoi concentrarti meno su ciò che è ingiustamente sbagliato con il codice e più su quali sono i risultati attesi che stai cercando. Preferirei assumere qualcuno in grado di scrivere buoni test rispetto a qualcuno in grado di individuare immediatamente ciò che è sbagliato con un pezzo di codice.

Potrebbero esserci due problemi:

Potrebbe trattarsi di un "intervista sotto stress" link . L'intervistatore sta cercando di capire come affrontare lo stress dal momento che il loro ambiente di lavoro è tale.

o

Potresti sentirti stressato. In tal caso dovrai gestire questo stress, es. introspe e vedi come puoi rimanere calmo.