Come Valutare le Competenze di Collaborazione con l'IA negli Intervisti di Programmazione

Quando l'uso dell'IA diventa una competenza, non un comportamento da rilevare

Per gran parte degli ultimi due anni, l'IA negli intervisti era qualcosa da cui difendersi. La rubrica era "il candidato l'ha usata, e l'abbiamo colto?" Questo inquadramento si applica ancora nei round senza IA, e lo strato di integrità che rileva l'abuso lì è un vero lavoro.

Ma nello stesso processo, sempre più aziende stanno ora eseguendo un round dove l'IA è richiesta. Meta, Canva, Shopify e Coinbase valutano esplicitamente i candidati sulla collaborazione con l'IA. Se il tuo processo si sta muovendo in quella direzione, hai bisogno di una rubrica — perché se dici a un candidato "usa gli strumenti che vuoi" e lo valuti sul fatto che il codice finale funzioni, stai misurando quasi nulla. Il codice che funziona è il contributo dell'IA. La competenza è quella che il candidato porta con sé.

Questo articolo è per i responsabili delle assunzioni che progettano il round collaborativo con l'IA. Quattro dimensioni da valutare, un formato di esercizio e gli errori comuni che gli intervistatori fanno e che riducono il segnale.

Le quattro dimensioni che vale la pena valutare

Una rubrica utile per la collaborazione con l'IA testa competenze che sono osservabili in 45 minuti e che distinguono l'ingegnere che usa bene l'IA da quello che copia il suo output. Quattro dimensioni, con ancore a ogni livello.

1. Qualità del prompt e scomposizione del problema

I candidati forti non chiedono al modello di "costruire la funzione". Scompongono prima il problema, poi chiedono aiuto per il pezzo di cui hanno bisogno. Il primo prompt dell'ingegnere bravo assomiglia a un ticket ben delimitato; quello dell'ingegnere debole assomiglia alla dichiarazione del problema originale.

Cosa devi ascoltare:

• Il candidato ha riformulato il problema con parole proprie prima di fare il prompt?
• Ha vincolato il modello — percorsi dei file, firme delle funzioni, la forma dei dati, esempi dell'output previsto?
• Ha chiesto una cosa alla volta, o ha incollato tutto il brief e speranza?

Un proxy utile: quanti token ha scritto il candidato nel prompt per ogni riga di codice prodotta dall'IA? Al di sotto di un certo rapporto, il candidato sta usando il modello come una scatola magica e non sta esercitando giudizio sull'input.

2. Verifica e scetticismo

Questa è la dimensione che più spesso separa il forte dal debole. Il modello produce output. Che cosa fa il candidato?

Il segnale più forte è se il candidato verifica prima di integrare. Comportamenti specifici:

• Leggere il codice generato riga per riga prima di incollarlo
• Eseguirlo rispetto a un caso di test che il candidato ha costruito (non uno suggerito dal modello)
• Riconoscere una funzione o una libreria allucinata e ripromptare o sostituirla di persona
• Notare che l'output è plausibile ma sbagliato in un caso limite

Il comportamento più debole è incolla-e-prega: il candidato copia il codice del modello nell'editor, esegue il percorso felice, vede verde e passa oltre. Questo è l'equivalente della collaborazione con l'IA di un ingegnere junior che effettua il merge senza leggere il diff.

Usa la stessa analisi della coerenza del codice che contrassegna il codice generato da LLM nelle valutazioni asincrone. In un round richiesto dall'IA, il punteggio non è "il candidato ha usato l'IA" — è previsto. Il punteggio è se le modifiche del candidato all'output dell'IA mostrano prove di lettura e riflessione, o se il diff è puro incolla.

3. Controllo del loop

I candidati junior seguono l'IA ovunque la porti. I candidati forti guidano l'IA.

Comportamenti concreti da valutare:

• Quando il modello restituisce una risposta sbagliata, il candidato diagnostica e riprompta con un vincolo corretto — o continua a rigenerare, sperando in una risposta diversa?
• Quando il modello propone un'architettura con cui il candidato non è d'accordo, il candidato spinge indietro ("Preferirei usare una macchina a stati qui, puoi rifarlo con quel modello?") o accetta il suggerimento?
• Quando il modello va fuori tema (refactoring di qualcosa che il candidato non ha chiesto), il candidato se ne accorge e lo riporta indietro?

Questa dimensione è invisibile senza la registrazione dello schermo. Assicurati che il round catturi la cronologia dei prompt e il diff dell'editor insieme, non solo il codice finale.

4. Comunicazione mentre si fa pair programming con l'IA

L'ultima dimensione è se il candidato tiene l'intervistatore al corrente. Sembra soft ma è il predittore di segnale più alto di come il candidato lavorerà giorno dopo giorno in un team che fa pair programming con l'IA.

Come appare il bene:

• Narrare prima di fare il prompt: "Chiederò a Claude di scrivere il parser. Mi aspetto che faccia bene il tokenizer ma probabilmente abbia problemi con i caratteri di escape — dovrò correggerlo."
• Mostrare il prompt prima di inviarlo
• Portare il disaccordo con il modello in superficie, non in silenzio
• Distinguere quello che hanno scritto da quello che ha scritto il modello quando spiegano il codice

La versione debole: prompting silenzioso, lunghe pause mentre il candidato legge l'output del modello senza condividere cosa ne pensa, il codice appare nell'editor senza spiegare da dove viene. Un candidato che codifica in silenzio con l'IA farà pair programming in silenzio con gli umani, ed è un segnale di dinamica di team che vuoi rilevare nel processo.

L'esercizio che fa emergere queste competenze

La tentazione è dare al candidato un problema di algoritmi e lasciarlo usare l'IA. Non farlo. L'IA lo risolverà in pochi secondi e il candidato passerà 40 minuti a modificare commenti. Non imparerai nulla.

Un esercizio migliore ha tre proprietà:

1. Multi-step, con una sorpresa incorporata. Inizia con un piccolo compito che il candidato può chiaramente risolvere. A metà, introduci una richiesta di modifica che rompe un'ipotesi — un nuovo formato di dati, un vincolo di prestazione, una libreria deprecata. L'adattamento è dove emerge la competenza di collaborazione con l'IA.
2. Un punto di partenza sottilmente rotto. Dai al candidato il codice che compila e funziona ma ha un bug sottile — un off-by-one, un'eccezione inghiottita, una race condition sotto carico. Osserva se lo colgono da soli o si fidano dell'IA a trovarla. La maggior parte dei modelli non troverà un bug sottile senza un prompt esplicito.
3. Una componente di documentazione o ricerca. L'attività richiede al candidato di integrarsi con una libreria o API sconosciuta. Il modello la conosce. Il candidato deve verificare quello che dice il modello rispetto ai documenti effettivi. Il divario tra "il modello sostiene" e "i documenti dicono" è ricco di segnali.

Quarantacinque minuti per l'intero round. L'editor di codice collaborativo di ClarityHire esegue Monaco con esecuzione integrata e lo accoppia con cattura della cronologia dei prompt, in modo che l'intervistatore possa vedere il diff dell'editor e la conversazione del modello fianco a fianco durante il debrief — non solo il codice finale.

Ancore di valutazione, da 1 a 4

Valuta ogni dimensione indipendentemente su una scala da 1 a 4. Ancora i livelli ai comportamenti, non agli aggettivi.

Qualità del prompt (1–4):

• 1: Incolla l'intera dichiarazione del problema nel modello; nessuna scomposizione.
• 2: Chiede la funzione nel complesso, ma aggiunge almeno un vincolo.
• 3: Scompone l'attività in due o tre pezzi; fa il prompt a ognuno separatamente con contesto rilevante.
• 4: Scrive prompt ben delimitati che includono la firma della funzione, la forma dei dati e un esempio elaborato.

Verifica (1–4):

• 1: Incolla l'output del modello senza leggere.
• 2: Legge l'output ma testa solo il percorso felice.
• 3: Costruisce almeno un caso di test indipendente dai suggerimenti del modello; coglie almeno un problema.
• 4: Tratta ogni output come sospetto; verifica rispetto a documenti reali, dati di test reali e casi limite prima di integrare.

Controllo (1–4):

• 1: Segue tutto quello che produce il modello; rigenerates piuttosto che riprompta al fallimento.
• 2: Riprompta con lo stesso contesto dopo il fallimento; a volte coglie il modello che va fuori tema.
• 3: Diagnostica perché il modello è sbagliato e riprompta con un vincolo corretto.
• 4: Imposta l'architettura di persona e usa il modello per pezzi tattici; spinge indietro quando il modello suggerisce un design diverso.

Comunicazione (1–4):

• 1: Prompting silenzioso; l'output appare nell'editor senza spiegazione.
• 2: Narra il risultato finale ma non il processo.
• 3: Narra prima di fare il prompt e mostra il prompt all'intervistatore.
• 4: Distingue chiaramente il proprio contributo da quello del modello; porta il disaccordo con il modello in superficie ad alta voce.

Usa una scorecard strutturata dove ogni intervistatore blocca il suo punteggio prima del debrief. Le dimensioni sono indipendenti abbastanza da permettere che il disaccordo sia informativo — un intervistatore potrebbe valutare il candidato 4 sulla verifica e 2 sulla comunicazione, e quel modello è la cosa che vale la pena discutere.

Errori comuni degli intervistatori

Cinque errori che riducono il segnale in questo round:

1. Valutare il codice finale. Il codice è dell'IA. Il giudizio, i prompt e le modifiche sono del candidato. Valuta quelli.
2. Chiedere al candidato di "spiegare cosa ha fatto l'IA". Questo testa la comprensione della lettura, non la collaborazione. Invece, chiedi "cosa cambieresti dell'approccio dell'IA?"
3. Lasciare il round in silenzio. Se il candidato sta zitto per due minuti mentre legge l'output del modello, spingilo: "raccontami cosa stai guardando". Il silenzio non è il test; stai valutando come fanno pair programming.
4. Scegliere un problema che il modello può risolvere in un colpo. Un problema banale significa che il candidato non deve mai dimostrare il controllo, la verifica o il recupero. Scegli un problema che richiede almeno un round di disaccordo con il modello.
5. Dimenticare la linea di base di integrità. Questo è il round richiesto dall'IA, ma sei ancora nello stesso processo del round senza IA. Se il modello di sequenze di tasti di un candidato in questo round sembra identico al round senza IA, è interessante — sia per buone ragioni (il candidato digita davvero in questo modo) sia per cattive ragioni (lo stesso helper fuori schermo sta eseguendo entrambi i round).

Cosa fare dopo

Se stai per aggiungere un round di collaborazione con l'IA al tuo processo:

1. Decidi quali delle quattro dimensioni contano di più per il ruolo specifico. Un ingegnere di ML applicato probabilmente pesa la verifica più in alto; un ingegnere software generalista potrebbe pesare la comunicazione.
2. Progetta un esercizio che include una sorpresa a metà round e un bug sottile all'inizio. Scrivi le ancore prima che il primo candidato lo veda.
3. Cattura la cronologia dei prompt insieme al diff dell'editor. Senza i prompt, stai valutando il codice; con loro, stai valutando l'ingegnere.
4. Calibra con due intervistatori su una sessione registrata prima di eseguirla in diretta. Il disaccordo tra loro è la rubrica.
5. Valuta questo round indipendentemente dal round senza IA. Misurano cose diverse e confonderli premierà il candidato sbagliato.

L'obiettivo di questo round non è trovare candidati che possono usare l'IA — quasi tutti i candidati possono. È trovare quelli il cui giudizio, verifica e direzione sono sufficientemente buoni da rendere il leverage dell'IA reale, invece di un incolla-e-prega costoso.