Perché gli intervistatori non chiedono al richiedente di leggere del codice? [chiuso]

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. Circa il 90% dei lavori riguarda principalmente la manutenzione dei sistemi esistenti. La capacità dell'IMO di leggere il codice di qualcun altro è un'abilità importante.

Perché gli intervistatori non lo controllano? *

* _{Tra i miei amici sono l'unico a cui è stato chiesto di rivedere un po 'di codice.}

Quando stavo facendo domande per l'intervista, all'inizio l'ho fatto, ma lentamente l'ho eliminato. I candidati che potevano scrivere bene il codice nell'intervista potevano leggere bene il codice nell'intervista. I richiedenti che non erano in grado di leggere il codice non potevano neanche scriverlo. Le domande relative alla lettura del codice non hanno realmente differenziato i candidati.

Versione breve

Se il lavoro consiste nel mantenere un'applicazione, le competenze che devi testare durante le interviste sono:

• La capacità di comprendere la base di codice di grandi dimensioni con la sua documentazione, unit test , ecc.

• La capacità di refactoring del codice e di apportare modifiche senza rompere tutto.

Chiedere alle persone di leggere il codice non ti aiuterà a valutare tali abilità.

Versione lunga

Ti è stato chiesto di scrivere il codice? Se sì, come ha notato Sign nella sua risposta , questo è sufficiente. Se generalizziamo un po ', una persona che scrive un 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 codice, allora, probabilmente, sei stato intervistato da una persona del dipartimento delle risorse umane. Tali interviste non possono essere troppo tecniche e sono per lo più prive di valore, dal momento che non mettono a repentaglio 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.

Esistono alcuni altri motivi per non chiedere di leggere il codice per un lavoro di manutenzione:

1. È difficile fare in modo affidabile

Concretamente, cosa faresti se fossi un intervistatore? Fai leggere ai tuoi candidati qualche codice. Quale codice? In che lingua? Quanto bene o male scritto? Con o senza commenti? Con o senza documentazione?

Ancora più importante, cosa dice del candidato? Quanto bene si collega con codebase stesso?

Supponiamo che tu abbia un'app VB.NET legacy 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 a lavorare sulla soluzione; ha effettuato il refactoring e ha testato l'unità delle parti più critiche dell'applicazione, ha aggiunto commenti laddove fossero necessari commenti e, soprattutto, ha scritto una documentazione dettagliata sull'architettura generale, le parti critiche e le insidie.

Ora stai assumendo uno sviluppatore per mantenere questa base di codice. Durante un'intervista, daresti un pezzo di codice legacy (brutto non testato) o il pezzo di codice che è stato refactored dallo sviluppatore precedente?

Daresti la documentazione? Per leggere la documentazione, il candidato dovrà trascorrere almeno alcune ore. Questo rende impossibile farlo durante un'intervista.

2. Leggere un breve codice non è lo stesso di leggere un codice di un progetto familiare

Ricorda, il compito è mantenere un progetto. È difficile mantenere una base di codice di grandi dimensioni i primi giorni o settimane quando non si ha 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 generale.

La cosa più importante da verificare è se la persona sarà efficiente in 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 un breve pezzo di codice da zero, non si sta testando come questa persona sarebbe in grado di gestire un codice familiare e documentato di migliaia di LOC .

3. Mantenere il codice sorgente non è solo leggerlo

Quando si mantiene una base di codice, la si sta modificando . Uno sviluppatore che legge solo il codice non porta nulla di utile alla sua azienda.

Le abilità utili sono la capacità di refactoring del codice , l' aggiunta di unit test , la previsione dell'impatto di una modifica , ecc. Non si verificano tali abilità chiedendo a una persona di leggere il codice durante l'intervista.

La lettura è un presupposto basato 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 assumessi qualcuno come interprete per il giapponese, non sarebbe logico che se potessero scrivere un saggio di 1.000 parole su un argomento particolare 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 la lettura è altrettanto critica, ma nella maggior parte dei casi, in cui è presente l'abilità di scrittura è presente anche l'abilità di lettura. L'unico caso reale in cui ho potuto vedere una differenza distinguibile sarebbe in un ambiente in cui ci sono molti casi altamente complessi che si sono evoluti nel tempo. Anche dato questi, però, non ti aspetteresti che qualcuno sia in grado di leggerli e capirli senza almeno qualche studio.

Inoltre, leggere il codice e spiegare ciò che pensi non esprima realmente 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 la lettura del codice dovrebbe essere qualcosa di dimostrato nelle interviste, ma nel tempo mi sono reso conto che si tratta di una perdita di tempo sia per l'intervistatore che per l'intervistato. Perché? Perché anche i programmatori cattivi possono leggere un frammento 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 codice che abbraccia molte classi e file. Essere in grado di rintracciare il codice per capire cosa sta facendo è una caratteristica desiderabile, ma non c'è abbastanza tempo per qualcuno per trovare un buon esempio (non un codice di produzione) né c'è tempo in un'intervista per porre una domanda del genere .

Quindi, i programmatori errati 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 codice nel colloquio sono gli indicatori migliori della sua abilità. Se riescono a scrivere codice pulito e conciso, è probabile che riescano a leggere il codice andava bene.

Chiedo a tutti i candidati che sto intervistando una variazione del problema FizzBuzz . È veloce, semplice e normalmente può individuare i codificatori difettosi 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 processo di pensiero.