Come scrivere domande di colloquio di programmazione resistenti all'IA

Le premesse sono cambiate

A metà 2026, la domanda interessante non è se il candidato ha ChatGPT aperto. È se il vostro colloquio misura ancora qualcosa quando lo ha. La maggior parte dei team ha reagito aggiungendo rilevamento — biometria dei tasti, segnali di incolla, punteggio di coerenza del codice. Il rilevamento aiuta. La progettazione dei problemi aiuta di più. Un problema che un LLM risolve in otto secondi non vi dice nulla sulla persona dietro la tastiera, indipendentemente da quanto chiaramente segnalate l'incolla.

Questa è una guida pratica su come scrivere domande di colloquio di programmazione che producono ancora segnale attendibile quando si suppone l'assistenza dell'IA.

Cosa rende facile una domanda per un LLM

Tre proprietà giocano contro di voi:

1. Appare nel corpus di addestramento. LeetCode, HackerRank, Codeforces, repository di tendenza su GitHub — tutto è nei pesi del modello. Se la vostra domanda ha un nome di stampo Wikipedia (Two Sum, Word Ladder, Longest Increasing Subsequence), assumete che la risposta sia memorizzata.
2. Il testo completo è consegnato da subito. Un prompt completo e non ambiguo è esattamente la forma su cui un LLM è stato addestrato a rispondere. Il modello non ha bisogno di nulla dal candidato.
3. L'output è in forma chiusa. Una funzione con un input, un output e una sola risposta corretta è banalmente valutabile — e banalmente generabile.

LeetCode #1 colpisce tutti e tre. Così fa la maggior parte della libreria di domande ereditata.

Principio di progettazione 1: Nascondere il testo del problema, far emergere il sintomo

Anziché "implementare una funzione che restituisce la sottostringa più lunga senza caratteri ripetuti," date al candidato un test case non superato e una vaga segnalazione di bug: "I clienti vedono articoli duplicati nel carrello dopo che questo endpoint viene eseguito. Ecco un input che fallisce. Risolvi il problema."

Il candidato ora deve:

• Leggere il codice esistente
• Formare un'ipotesi su cosa sia sbagliato
• Decidere cosa significhi effettivamente "corretto"

Il modello può ancora aiutare — ma solo dopo che il candidato ha incorniciato il problema. L'inquadramento del problema è la competenza che volevate misurare comunque.

Principio di progettazione 2: Consegnare la base di codice, non il prompt

Sostituite puzzle autonomi con un piccolo repository. 100–300 righe, più file, uno o due bug intenzionali, un README scarno. Chiedete: "Trova il bug che causa il 500 sul POST /orders, e risolvilo."

Un modello che non ha visto il vostro repository non è migliore di un candidato in questo. Indovinerà plausibilmente e con sicurezza — e sbaglierà — perché la risposta è nel codice circostante, non nel prompt.

Questo formato funziona anche come colloquio senza LeetCode per team che vogliono misurare l'ingegneria reale piuttosto che la velocità nel risolvere puzzle.

Principio di progettazione 3: Integrare una modifica a metà domanda

A metà strada, cambiate il requisito. "Ora il cliente vuole supportare rimborsi parziali — estendi la tua soluzione." Oppure: "Questo endpoint ora deve essere idempotente. Cosa cambia?"

La modifica fa tre cose:

• Costringe il candidato a dimostrare che comprende il proprio codice (un incolla fresco da una finestra di chat non può farlo).
• Fa emergere gli istinti architetturali che una soluzione one-shot nasconde.
• Rende ovvio il prompt di un modello durante il colloquio — il candidato si ferma, chiede qualche minuto, oppure produce un secondo incolla pulito che non assomiglia al primo. Tutto ciò diventa segnale nel rapporto di integrità.

Principio di progettazione 4: Chiedere giudizio, non output

Alcune delle domande con il segnale più alto non hanno neppure codice da scrivere:

• Esercizi di code review. Consegnate un diff di 60 righe. Chiedete al candidato di lasciare commenti come se fosse il revisore su una PR. Gli LLM producono code review serie e generiche ("considera l'aggiunta di un commento qui"). Gli ingegneri senior producono critiche specifiche e prioritizzate ("questo lock è mantenuto durante la chiamata di rete — andrà in deadlock sotto carico").
• Conversazioni sui compromessi. "Hai due opzioni per questo cache invalidation. Quale sceglieresti e perché?" Il candidato deve difendere una scelta. Il modello non ha interessi in gioco e mediterà.
• Leggere una PR non familiare. "Spiegami cosa fa questo cambiamento e cosa potrebbe andare male."

Questi si raggruppano meglio con rubriche di system design che con scorecard di algoritmi. Valutate il ragionamento, non il verdetto.

Principio di progettazione 5: Vincoli insoliti piuttosto che problemi nuovi

Non avete bisogno di inventare una nuova classe di problemi. Avete solo bisogno di un vincolo insolito su uno familiare.

• "Implementa un rate limiter — ma l'orologio può andare indietro fino a 30 secondi a causa della deriva NTP."
• "Costruisci una coda — ma enqueue deve essere O(1) nel caso peggiore, non ammortizzato, perché lo eseguiamo in un control loop in tempo reale duro."
• "Analizza questo file di configurazione — ma la specifica evolve. Mostrami come gestiresti la compatibilità all'indietro tre versioni da ora."

Gli LLM possono risolvere questi. Spesso perderanno il vincolo. Il candidato che lo nota, chiede informazioni e progetta intorno ad esso è il candidato che volete.

Cosa non fare

Poche reazioni comuni che si ritorcono contro:

• Vietare l'IA senza cambiare la domanda. Perderete i migliori candidati che già usano bene l'IA, manterrete i cheater che non si preoccupano delle vostre regole, e non imparerete nulla di nuovo.
• Rendere i problemi gratuitamente difficili per "superare" il modello. La difficoltà avversaria seleziona persone disposte a macinare sotto pressione, non persone che possono fare il lavoro. Il tasso di superamento crolla e l'imbuto si blocca.
• Passare tutto a colloqui alla lavagna / senza laptop. Questa è un'opzione reale, ma ha i suoi compromessi — accessibilità, stress del candidato, e il fatto che nessun ingegnere programma in quel modo nel suo vero lavoro.
• Fidarsi di etichette "resistenti all'IA" dai fornitori di domande. Alcuni fornitori verificano che una domanda ottenga un punteggio sotto una soglia quando sottoposta a GPT-4 oggi. Il modello di domani la rivaluta diversamente. Considerate l'etichetta come punto di partenza, non come garanzia.

Associare la progettazione delle domande al livello di misurazione

Anche una domanda ben progettata beneficia di un livello di integrità che vi dà un secondo asse di segnale. L'IA di coerenza del codice di ClarityHire legge la traiettoria di un invio, non solo il codice finale — il candidato ha iterato, testato e refactorizzato, o la soluzione è arrivata in un grande incolla coerente? Combinato con timing dei tasti e eventi di incolla/cambio scheda, ottenete un punteggio di confidenza che si abbina alle scelte progettuali di cui sopra invece di sostituirle.

Il modello più forte che vediamo: una domanda resistente all'IA per la fase asincrona, seguita da una revisione dal vivo di 30 minuti in cui il candidato deve spiegare decisioni prese ore prima. La combinazione è significativamente più difficile da falsificare di quanto lo sia uno dei due step da solo.

Cosa fare dopo

Scegliete le tre domande che assegnate più spesso e valutatele rispetto ai principi di cui sopra:

1. Ciascuna domanda nasconde parte del testo che il candidato deve estrarre?
2. La domanda richiede di leggere codice che il candidato non ha visto prima?
3. C'è una modifica o una decisione di giudizio che un modello standard non può facilmente possedere?

Per ciascuna domanda che ottiene un punteggio basso, riscrivetela una volta e testate la nuova versione su cinque candidati reali prima di implementarla. Misurate due cose: la qualità media dell'invio dal vostro primo quartile e il tasso di superamento al turno successivo. Se la qualità sale e il superamento rimane stabile, avete una domanda migliore. Se il superamento crolla, la nuova versione è avversaria, non selettiva — rivedete e riprovate.

L'IA nei colloqui di programmazione non è il problema. Le domande "IA-shaped" sono il problema. Aggiustate le domande e il resto dello stack di integrità inizia a fare quello che avrebbe sempre dovuto fare: confermare il segnale, non generarlo.