Intervista di Revisione del Codice: Domande, Rubrica e Perché Supera gli Algoritmi

Cosa è veramente un'intervista di revisione del codice

Un'intervista di revisione del codice è esattamente quello che sembra: al candidato viene dato un pull request funzionante — 100-400 righe, una singola feature o correzione di bug — e gli viene chiesto di revisionarlo come se un compagno di team l'avesse aperto. Segnalano i problemi, suggeriscono cambiamenti e spiegano all'intervistatore il loro ragionamento. A volte ci sono bug deliberati. Sempre ci sono scelte di giudizio.

È il formato più sottoutilizzato nell'hiring tecnico. La maggior parte dei colloqui utilizza ancora per default un round di algoritmi su lavagna o un esercizio take-home. Entrambi sono segnali validi per cose specifiche. Nessuno dei due misura l'abilità su cui gli ingegneri trascorrono il tempo maggiore dopo l'assunzione.

Perché supera il round di algoritmi

Tre ragioni, in ordine di impatto.

1. Misura il lavoro reale. Gli ingegneri trascorrono più ore a revisionare codice che a scriverlo da zero. Un colloquio che non misura l'abilità di revisione sta misurando la dimensione sbagliata e la sta chiamando ingegneria.
2. È difficile da fingere con l'IA. Gli LLM possono scrivere il diff. Faticano a discutere sul perché una funzione dovrebbe essere estratta quando un revisore senior ha un caso difendibile per l'altro lato. Il segnale è nel dibattito, che è dove i candidati assistiti da LLM crollano.
3. Scala su tutti i livelli di seniority. I junior notano la sintassi e i bug. I mid-level notano la struttura. I senior notano le scelte di design che il diff sta nascondendo (cosa è stato cancellato, cosa è stato deliberatamente non cambiato). Stesso artefatto, letture molto diverse — il che significa che un PR può guidare interviste da L3 a L6 con pesi di rubrica regolati invece di banchedati domande separate.

Questo è il formato a cui ricorrono i team quando hanno capito che LeetCode non è predittivo e un puro work-sample take-home è troppo costoso da eseguire al volume della parte superiore del funnel.

Come scegliere la codebase

Il PR che usi determina se l'intervista misura il giudizio o la conoscenza. Tre cose contano:

• Usa codice reale e anonimizzato. Uno snippet giocattolo con tre bug ovvi allena i candidati a cercare trucchi. Un diff reale con cambiamenti di qualità mista li costringe a leggere veramente.
• Scegli un dominio che il candidato non avrà memorizzato. Evita un'app TODO o un algoritmo stile leetcode. Usa qualcosa con logica di business — una regola di prezzo, un controllo di permessi, una politica di retry. La familiarità con il dominio non è il segnale.
• Assicurati che ci sia almeno una scelta di giudizio difendibile. La migliore intervista di revisione del codice ha zero risposte "sbagliate" e tre posti dove un revisore riflessivo potrebbe controbattere comunque. È lì che misuri la seniority.

Fornisci il round con il diff caricato in un editor reale — non un PDF statico. Le chat room di codifica collaborativa di ClarityHire aprono il file con annotazioni e un thread di commenti che l'intervistatore può guardare in tempo reale, quindi la revisione sembra un normale PR di GitHub piuttosto che un interrogatorio.

La rubrica di valutazione a quattro dimensioni

Prendi in prestito la struttura da una rubrica di system design ma ricostruisci le dimensioni per il lavoro di revisione.

1. Identificazione dei problemi

Hanno colto le cose che una revisione reale catturerebbe? Valuta la densità e la gravità:

• 4 — ha colto il problema centrale (sicurezza, correttezza o architettura) più le piccole cose
• 3 — ha colto il problema centrale o la maggior parte delle piccole cose
• 2 — ha colto problemi di superficie ma ha perso il problema strutturale
• 1 — ha perso il problema centrale e ha criticato la formattazione

2. Prioritizzazione

Due problemi non sono mai dello stesso peso. Valuta se il candidato distingue "questo è un bug" da "potrebbe essere più pulito" da "non blocchere su questo." Gli ingegneri senior ancorano i revisori attorno ai bug; i junior trattano ogni commento come priorità uguale.

3. Qualità della giustificazione

Per ogni commento che lascia, riesce ad articolare il compromesso? "Estrarrei questo helper" è un commento di livello B. "Estrarrei questo helper perché la stessa logica appare nel flusso di cancellazione dell'ordine e vogliamo che evolvono insieme" è la versione senior. Valuta la specificità, non il vocabolario.

4. Tono e collaborazione

La revisione del codice è un'abilità relazionale. Un revisore che è tecnicamente giusto ma scrive commenti che il tuo team risentirà è un negativo netto. Valuta: il commento arriva come un suggerimento su cui l'autore può agire, o come un attacco?

Questa è la dimensione che la maggior parte dei formati di intervista non può misurare affatto. Le interviste di revisione del codice la mettono in luce chiaramente.

Domande di esempio per ancorare la conversazione

Questi sono i prompt che gli intervistatori dovrebbero tenere fino a dopo che il candidato ha fatto il loro passaggio personale:

• "Presentami i commenti che posterei davvero, nell'ordine in cui li posterei."
• "Quale singolo commento renderei bloccante?"
• "Se l'autore controbatte sul tuo commento più importante, qual è il tuo secondo argomento migliore?"
• "Cosa non è in questo diff che dovrebbe essere? Cosa chiederei nella descrizione del PR?"
• "Cosa non solleverei, anche se l'ho notato?"

L'ultima domanda è quella più discriminante per il livello senior nell'insieme. Sapere cosa ignorare è metà della revisione del codice efficace.

Come valutare una revisione aperta

L'intervista produce artefatti disordinati — commenti inline, una trascrizione della procedura dettagliata verbale, a volte un riassunto scritto. Tre regole per valutarli coerentemente:

• Usa un modello di valutazione condiviso per ruolo. Costruiscilo una volta dalla tua libreria di rubriche e riutilizzalo tra i candidati.
• Valuta l'artefatto e la conversazione separatamente. Un candidato che ha scritto grandi commenti ma ha argomentato male nella discussione dal vivo è un'assunzione diversa da uno che l'ha capovolto.
• Esegui un round solo scritto su scala, dal vivo di persona per i finalisti. La valutazione assistita da IA dei commenti scritti dà un passaggio utile sulla densità e specificità al top del funnel, dove non puoi permetterti il tempo dal vivo. Il round dal vivo cattura il segnale di conversazione che la valutazione non può.

Resistere all'assistenza dell'IA durante il round

Se il candidato esegue il diff attraverso Claude o GPT in un'altra scheda, i commenti che incollano saranno tecnicamente densi ma stilisticamente incoerenti con la loro argomentazione nella discussione. Due modi per portare alla luce questo:

• Osserva il modello di modifica — incollate pulite e grandi di prosa strutturata seguite da silenzio sono il segnale, nello stesso modo in cui lo sono in un round di codifica
• Rendi la discussione dal vivo obbligatoria e avversariale: scegli il commento più forte del candidato e discuti contro. I commenti scritti dall'IA crollano quando il candidato non riesce a difendere la frase specifica che ha scelto

Non hai bisogno di vietare l'IA per far funzionare il round. Hai bisogno di progettarlo in modo che un candidato solo IA non possa superare la metà della conversazione.

Cosa fare dopo

Scegli un PR dalla tua codebase, anonimizzalo, e pilota il round con due ingegneri attuali la prossima settimana. Chiedogli di revisionare il diff a freddo e valutarsi contro la rubrica. Qualunque discrepanza appaia tra la loro valutazione e il tuo istinto su come revisionano effettivamente il lavoro è la discrepanza che la tua rubrica sta correggendo. Poi eseguilo sul tuo prossimo loop e confronta i punteggi dei candidati contro i tuoi risultati di valutazione della codifica esistenti. Nella nostra base clienti, l'ordine di ranking cambia — e il nuovo ordine si mappa meglio a chi effettivamente funziona dopo l'assunzione.