Come progettare domande di coding interview resistenti all'IA

Non puoi vietare l'IA. Puoi progettare intorno ad essa.

Nel 2026, chiedere ai candidati di rinunciare agli assistenti IA per un'intervista è solo spettacolo. Il livello che i candidati raggiungono con ChatGPT in un'altra scheda è il livello contro cui i competitor assumono. La domanda non è come rilevare l'uso dell'IA — è metà del lavoro, e lo affrontiamo in come rilevare ChatGPT nelle interviste di coding. L'altra metà è progettare problemi che non crollano quando il candidato ha un LLM a disposizione.

Questa è una guida alla seconda metà: come scrivere problemi di intervista di coding che producono vero segnale anche quando l'IA è attiva, e dove l'aiuto dell'IA si mappa chiaramente su competenze che effettivamente vuoi assumere.

Perché i problemi standard non funzionano più

Un tipico problema LeetCode ha tre proprietà che lo rendono banale per un LLM:

1. Si trova nel training set. Ogni classico problema two-pointer, sliding window e dynamic programming è stato risolto, spiegato e re-spiegato su internet.
2. L'input è ben specificato. Due array di interi, un target, restituisci gli indici. Il modello sa esattamente cosa produrre.
3. L'output è binario. I test passano o falliscono. Non c'è giudizio nella risposta che il candidato possa difendere.

Un problema con tutte e tre queste proprietà è, nel 2026, un controllo di competenza ChatGPT, non di competenza di programmazione. Ogni proprietà che rimuovi rende il problema più difficile da esternalizzare.

Principio 1: ancora il problema al codice che l'LLM non ha mai visto

Il modo più pulito per eliminare il vantaggio del training set è far lavorare il candidato all'interno di una codebase specifica. Un LLM può scrivere un graph traversal a freddo. Non può affidabilmente estendere un repo di 400 righe dove due dei moduli usano una convenzione interna che non ha mai incontrato.

Ecco come appare nella pratica:

• Fix-the-bug. Un repo di 200–400 righe con un bug non ovvio. Il sintomo è dato, la causa non è. Il candidato deve leggere, ipotizzare, testare e patchare. Delineiamo il formato nella nostra guida all'intervista senza Leetcode.
• Extend-the-feature. Un'app funzionante con una piccola richiesta di feature ben definita. La qualità del diff è la valutazione. Un LLM può generare un diff plausibile; non può garantire che il diff si adatti alle convenzioni esistenti e passi i test esistenti al primo tentativo.
• Refactor under a constraint. "Questo file ha 600 righe ed è difficile da leggere. Dividilo in tre file senza cambiare il comportamento. I test devono ancora passare." La risposta giusta è una questione di giudizio. Non c'è una soluzione canonica da memorizzare.

Questi formati neutralizzano il vantaggio del training set perché l'LLM non può aver visto il repo. La capacità del candidato di navigare il codice sconosciuto diventa il segnale.

Principio 2: rendi l'input ambiguo di proposito

Gli LLM sono al loro meglio quando le specifiche sono precise. Sono al loro peggio quando le specifiche mancano di informazioni che un umano noterebbe e chiederebbe.

Un problema standard: "Dato un CSV di ordini, calcola i ricavi mensili."

Una versione più difficile da esternalizzare: "Ecco un CSV di ordini. Calcola i ricavi mensili. Alcune righe sono rimborsi e rappresentate come importi negativi. Alcune righe sono rimborsi parziali e usano un valore status diverso. Alcune righe sono da una linea di prodotto dismessa che non è stata effettivamente spedita. Decidi quali includere e spiega il tuo ragionamento prima di scrivere qualsiasi codice."

Il passaggio del ragionamento è la valutazione. Un LLM produrrà felicemente codice che gestisce il caso canonico e silenziosaamente scarta il resto. Un vero ingegnere farà una pausa, elencherà le ambiguità e farà una domanda di chiarimento — o documenterà i presupposti che ha fatto.

Valuta i chiarimenti e i presupposti del candidato separatamente dal codice che segue. L'elenco dei chiarimenti è più difficile da falsificare rispetto all'implementazione.

Principio 3: sposta il peso sulla conversazione intorno al codice

Una sottomissione è un campione, non una risposta. Un LLM può produrre una sottomissione. Solo il candidato può difenderla sotto interrogazione dal vivo.

Due modi per sfruttare questo:

• Async-then-sync. Esegui prima il round take-home o async coding, poi programma un round dal vivo di 30 minuti dove il candidato ti guida attraverso la sua sottomissione. Chiedigli di estenderla, cambia un vincolo, o chiedigli di argomentare perché ha scelto una struttura dati rispetto a un'altra. Abbiamo approfondito questo formato in domande di follow-up per sottomissioni take-home.
• Live pairing sul codice del candidato. A metà intervista, cambia un requisito e chiedigli di refactorizzare di fronte a te. Il candidato che ha incollato la soluzione originale da un LLM avrà difficoltà a farla evolvere senza ripromptare.

In ClarityHire instruiamo il round dal vivo con code coherence checks sulla sottomissione originale, quindi l'intervistatore entra sapendo quali sezioni del codice del candidato sembrano generate da LLM e quali sembrano scritte a mano. La conversazione può quindi mirare alle sezioni sospette specificamente.

Principio 4: scegli problemi dove l'aiuto dell'IA è una feature, non un bug

Se il tuo job posting dice "userai strumenti IA ogni giorno in questo ruolo," allora progetta problemi che ti permettono di osservare come i candidati effettivamente le usano. Non è la stessa cosa che permettere loro di incollare la risposta.

• Open-book con attribuzione. Dichiara esplicitamente: "Puoi usare ChatGPT o qualsiasi documentazione. Documenta ogni prompt che hai usato e la parte della soluzione che ha prodotto." Un candidato forte usa il modello chirurgicamente; uno debole fa prompt cinque volte per la stessa funzione rotta. La traccia è il segnale.
• IA come avversario. Dai al candidato una funzione generata da IA difettosa come punto di partenza. Il suo lavoro è identificare cosa è sbagliato, perché, e ripararlo. Questo testa la competenza che il ruolo effettivamente richiede: revisionare criticamente l'output dell'IA prima di spedirlo.
• Debugging assistito da IA. Daigli un repo sconosciuto con un bug reale, consenti l'uso di strumenti, e osserva come individuano la causa. Gli ingegneri che si appoggiano al modello per domande ristrette ("cosa significa questo stack trace?") sembrano molto diversi da quelli che incollano il file intero e sperano.

Esploriamo il quadro più ampio di questo formato in open-book coding assessments.

Principio 5: combina prevenzione con rilevamento — non affidarti a uno solo

Anche il problema meglio progettato perde segnale in una sola direzione. Abbina le scelte progettuali sopra con segnali di integrità passivi:

• Keystroke biometrics segnalano eventi burst-paste che non corrispondono alla paternità umana.
• Code coherence analysis cattura cambiamenti di stile a metà sottomissione.
• Un live follow-up cattura autori che non possono difendere il loro stesso codice.

Ognuno è debole da solo. Insieme rendono il costo dell'imbroglio più alto del costo di fare il lavoro.

Un breve checklist prima di spedire la domanda

Prima di mettere un problema di coding di fronte a un candidato nel 2026, chiediti:

1. ChatGPT potrebbe risolvere questo solo dalla dichiarazione del problema? Se sì, riprogetta o riduci il suo peso nel loop.
2. Le specifiche sono ambigue in modo da premiare domande di chiarimento? Se no, aggiungi ambiguità.
3. Il candidato deve difendere o far evolvere la sua soluzione dal vivo? Se no, programma un follow-up.
4. Stai misurando come usano l'IA, o fingendo che non lo faranno? Sii onesto con il candidato comunque.
5. Hai un segnale di integrità che conferma che la stessa persona ha scritto la sottomissione e ha eseguito il follow-up? Se no, aggiungine uno.

Cosa fare dopo

Se il tuo round di coding attuale è un singolo problema in stile LeetCode con una dropbox take-home, stai testando prompt engineering a questo punto, non ingegneria. Scegli uno dei formati sopra, scrivi un problema in esso, e eseguilo su tre ingegneri interni prima di metterlo di fronte a un candidato. La prima versione sarà troppo facile o troppo poco chiara; la terza sarà quella che produce vero segnale.

Per un contesto più ampio su dove l'async si inserisce nel loop, vedi async vs live technical interviews. Per la metà del rilevamento di questo stesso problema, inizia con come rilevare ChatGPT nelle interviste di coding.