Ho avuto una dozzina di interviste nella mia vita (sto per laurearmi) e mi chiedo perché mi è stato chiesto solo una volta di leggere e spiegare un po 'di codice. Approssimativamente, il 90% dei lavori riguarda principalmente il mantenimento dei sistemi esistenti. L'abilità IMO di leggere il codice di qualcun altro è un'abilità importante.
Perché gli intervistatori non lo controllano? *
* Tra i miei amici, io sono l'unico a cui è stato chiesto di rivedere il codice.
Quando stavo facendo domande per l'intervista, all'inizio lo feci, ma gradualmente lo feci. I candidati che potevano scrivere bene il codice nell'intervista potevano leggere bene il codice nell'intervista. I candidati che non potevano leggere il codice non potevano scriverlo neanche. Le domande coinvolte nella lettura del codice non differenziavano realmente i candidati.
Se il lavoro consiste nel mantenere un'applicazione, le abilità che devi testare durante le interviste sono:
Capacità di comprendere la grande base di codice con la sua documentazione, test di unità , ecc.
La capacità di refactare il codice e di apportare modifiche senza rompere tutto.
Chiedere alle persone di leggere il codice non ti aiuterà a valutare quelle capacità.
Eri stato chiesto di scrivere il codice? Se sì, come indicato in la sua risposta , questo è sufficiente. Se generalizziamo un po ', una persona che scrive codice sorgente chiaro e facile da capire sarebbe in grado di leggere il codice sorgente scritto da altre persone.
Se non ti è stato chiesto di scrivere il codice, allora, probabilmente, sei stato probabilmente intervistato da una persona del dipartimento risorse umane. Tali interviste non possono essere troppo tecniche e sono per lo più inutili, dal momento che non mettono a frutto le tue capacità e la tua capacità di lavorare bene, ma piuttosto il numero di anni trascorsi al college e altre cose che non hanno nulla a che fare con il lavoro. / p>
Ci sono alcuni altri motivi per non chiedere di leggere il codice per un lavoro di manutenzione:
1. È difficile da fare in modo affidabile
Concretamente, cosa faresti se fossi un intervistatore? Fai leggere ai tuoi candidati un codice. Quale codice? In che lingua? Quanto bene o male scritto? Con o senza commenti? Con o senza documentazione?
Ancora più importante, cosa racconta del candidato? Quanto bene è correlato con lo stesso codebase?
Supponiamo che tu abbia un'app legacy VB.NET da mantenere. Sai che il codice sorgente è per lo più brutto e non testato, e alcuni commenti sono obsoleti o fuorvianti. Negli ultimi tre mesi, hai avuto uno sviluppatore molto abile che lavora sulla soluzione; ha rifattorizzato e ha testato le parti più critiche dell'applicazione, ha aggiunto commenti dove c'era bisogno di commenti e, soprattutto, ha scritto una documentazione dettagliata sull'architettura generale, le parti critiche e le insidie.
Ora stai assumendo uno sviluppatore per mantenere questo codebase. Durante un'intervista, forniresti un pezzo di codice (non ancora testato) o il codice che è stato refactored dallo sviluppatore precedente?
Daresti la documentazione? Per leggere la documentazione, il candidato dovrà passare almeno un paio d'ore. Ciò rende impossibile farlo durante un'intervista.
2. Leggere un breve pezzo di codice non equivale a leggere il codice di un progetto familiare
Ricorda, il lavoro è di mantenere un progetto. È difficile mantenere una base di codice estesa i primi giorni o settimane in cui non hai familiarità con il progetto. È molto più facile farlo dopo alcuni mesi quando hai scritto tutta la documentazione e hai una visione chiara della base di codice globale.
La cosa più importante da testare è se la persona sarà efficiente quei mesi . Non ti importa se la persona non sarà in grado di capire nulla nei primi due giorni.
Chiedendo a una persona di leggere una breve parte di codice da zero, non stai testando come questa persona sarebbe in grado di gestire una codea di codice familiare e documentata di migliaia di LOC .
3. Il mantenimento del codice sorgente non si limita a leggerlo
Quando mantieni una base di codice, stai modificando . Uno sviluppatore che legge solo il codice non porta nulla di utile alla sua azienda.
Le abilità utili sono la capacità di codice refactore , di aggiungere test unitari , di prevedere l'impatto di un cambiamento , ecc. non testare tali capacità chiedendo a una persona di leggere il codice durante l'intervista.
La lettura è un'ipotesi basata sul fatto che l'abilità è presente per la scrittura. Considera il concetto in qualsiasi lingua. La programmazione è solo un linguaggio per comunicare tra uomo e macchina. Considera una comunicazione da uomo a uomo. Se stavi assumendo qualcuno come interprete per il giapponese, non sarebbe ragionevole pensare che se potessero scrivere un saggio di 1.000 parole su un particolare argomento che sarebbero in grado di leggerlo?
Come programmatori, la nostra attività principale è la creazione di codice e la traduzione di idee astratte in implementazioni concrete. Questo generalmente significa scrivere. Concordo sul fatto che leggere sia altrettanto critico, ma nella grande maggioranza dei casi, dove è presente la capacità di lettura, è presente anche la capacità di lettura. L'unico vero caso in cui potrei vedere una differenza distinguibile sarebbe in un ambiente in cui ci sono un sacco di casi altamente complessi che si sono evoluti nel tempo. Anche a questi dati, però, non ti aspetteresti che qualcuno sia in grado di leggerli e comprenderli senza almeno qualche studio.
Inoltre, leggere il codice e spiegare quello che pensi che faccia non esprime veramente a un intervistatore come usi le tue capacità di pensiero critico. Mostra un po 'di analisi, ma la maggior parte dei datori di lavoro vuole vedere se riesci a pensare senza essere messo in una scatola. Vogliono sapere se riesci a cogliere i concetti senza il beneficio (o anche la stampella) del codice esistente per dirti cosa o come fare qualcosa.
In passato, penso che il codice di lettura debba essere qualcosa di dimostrato nelle interviste, ma nel tempo ho capito che questa è una perdita di tempo sia per l'intervistatore che per l'intervistato. Perché? Perché anche i cattivi programmatori possono leggere un codice di codice.
Essere in grado di giudicare la capacità di qualcuno di leggere il codice diventa rilevante solo quando si guarda qualcosa di complesso o di codice che abbraccia molte classi e file. Essere in grado di rintracciare il codice per capire cosa sta facendo è un tratto desiderabile, ma non c'è abbastanza tempo per qualcuno di trovare un buon esempio (non il codice di produzione), né c'è tempo in un'intervista per fare una domanda del genere .
Quindi, i cattivi programmatori possono leggere il codice, ma non possono scrivere bene il codice. Chiedere di vedere esempi di lavoro di un candidato o di chiedere a un candidato di scrivere il codice nel colloquio è un modo migliore per indicare le proprie capacità. Se riescono a scrivere codice pulito e conciso, è probabile che possano leggere il codice.
Chiedo a tutti i candidati che intervisto una variazione del FizzBuzz problema. È veloce, semplice e in genere è in grado di individuare i codificatori errati molto più velocemente di qualsiasi altra cosa abbia trovato. Un buon programmatore lo otterrà molto rapidamente e facilmente e ti darà una rapida occhiata al loro stile di codifica e al loro processo di pensiero.
Leggi altre domande sui tag code-reviews interview