Come intervistare ingegneri per le competenze di programmazione assistita da IA
La competenza che nessuno sta valutando
A metà 2026, la maggior parte degli ingegneri usa un assistente IA per una parte del lavoro quotidiano. La domanda a cui il tuo colloquio dovrebbe rispondere non è "riesce questo candidato a programmare senza?" — è un'ipotesi. È "riesce questo candidato a consegnare più velocemente e in modo più sicuro con uno rispetto all'ingegnere al suo fianco?"
Questa è una competenza diversa, e richiede un colloquio diverso. Un esercizio da svolgere a casa con una regola nascosta di "vietato l'IA" non la misura. Una prova LeetCode non la misura. Nemmeno la maggior parte dei formati open-book riescono a misurare veramente come il candidato usa l'IA — spesso è solo un motore di ricerca potenziato. Di seguito una guida pratica per strutturare un round che misura direttamente la competenza nell'uso dell'IA, e per valutarla senza premiare la performance.
Cosa significa veramente saper usare l'IA
Guarda un bravo ingegnere usare un assistente per un'ora. Lo vedrai fare cinque cose:
- Inquadrare il prompt intorno ai vincoli, non alle soluzioni. Dice al modello cosa il codice deve fare e non fare, poi itera.
- Rifiutare con sicurezza. Quando il modello propone qualcosa di sottilmente sbagliato — una versione API errata, una libreria allucinata, un pattern fragile — lo accorge in secondi e riorientan.
- Usare l'assistente soprattutto sulle parti noiose. Boilerplate, scaffolding dei test, conversioni di formato — usi ad alto leverage. Scrive la logica load-bearing da solo o tiene il modello a una specifica ristretta.
- Verificare prima di fidarsi. Esegue il codice, legge il diff, verifica i casi limite. Non fa commit a intuito.
- Sapere quando smettere di usarlo. Quando il modello gira in tondo, torna a pensare e leggere.
Un utente debole di IA fa l'opposto: pone domande ampie, accetta generazioni lunghe senza critica, lascia che il modello architetturi la soluzione, e mette in produzione qualunque cosa funzioni. Il compito del colloquio è distinguere questi due profili.
Il formato di domanda che lo evidenzia
La struttura della domanda conta più del problema specifico. Scegline una con queste proprietà:
- La risposta IA ingenua è sbagliata in modo sottile. Non un trucco — un vincolo reale che il candidato deve notare. Una versione comune: chiedi loro di implementare qualcosa su un'API recente o inusuale, dove i dati di training del modello sono obsoleti.
- Il problema è troppo grande per un candidato senza IA finirlo, e troppo sottile per un candidato solo-IA risolverlo in un tentativo. Questo forza sia gli strumenti che il giudizio.
- I criteri di accettazione sono chiari. Non "costruisci qualcosa di bello" — must-have espliciti che il candidato può verificare.
- C'è un'ambiguità deliberata nella specifica. Un ingegnere ragionevole la risolverebbe chiedendo o dichiarando un'assunzione. Un utente debole di IA incolla la specifica nel modello e mette in produzione quello che torna.
Un esempio funzionante: "Costruisci un piccolo comando che legge un CSV di ordini, calcola i totali mensili per cliente, e restituisce JSON. Due ambiguità che devi risolvere: timezone degli ordini e come gestire le righe di rimborso. 60 minuti. Qualunque tool vuoi."
Fallo live, non asincrono
Un esercizio da svolgere a casa puramente asincrono non riesce a distinguere i due profili. L'artefatto sembra lo stesso in entrambi i casi. Fallo come una sessione di programmazione live di 60–75 minuti con condivisione dello schermo o un editor collaborativo, con permesso esplicito di usare l'IA.
Regole dichiarate sin dall'inizio:
- Qualunque tool IA è consentito. Dimmi quali usi.
- Non detrarremo punti per aver usato l'IA. Approfondiremo come la usi.
- Approfondiremo quello che l'IA ti ha dato. Sii pronto a spiegare tutto quello che mantieni.
Questo inquadramento sposta il candidato da difensivo a dimostrativo. I bravi candidati si lanciano. I deboli si nervosano, perché il loro flusso di lavoro non regge lo scrutinio.
Cosa osservare in tempo reale
Cinque segnali concreti durante la sessione:
- Qualità del prompt. Spiega i vincoli, esempi e la forma dell'output desiderato? O incolla la specifica e spera?
- Tasso di rifiuto. Quanto spesso scartano una generazione? I bravi ingegneri rifiutano almeno qualcosa — a volte silenziosamente, a volte a voce alta. Gli ingegneri che mantengono tutto non stanno leggendo quello che mettono in produzione.
- Dove lasciano l'IA fuori. Scrivono la logica critica da soli? O lasciano che l'assistente possieda la parte che determina la correttezza?
- Abitudini di verifica. Eseguono il codice su input reali? Leggono il diff prima di accettare? Guardano i casi limite?
- Recupero. Quando il modello gira in tondo, fanno un passo indietro e pensano, o continuano a fare prompt?
Questi sono osservabili in una finestra di 60 minuti se guardi i keystroke, non solo l'artefatto. L'editor collaborativo di ClarityHire registra la sessione completa con gli eventi di paste etichettati separatamente dall'input digitato — utile quando vuoi riesaminare una scelta specifica con il candidato durante la walk-through.
Una rubrica di valutazione
Cinque dimensioni, 1–4 ognuna, valutate prima del debrief:
| Dimensione | Debole (1) | Forte (4) |
|---|---|---|
| Prompting | Incolla la specifica, pone domande ampie | Inquadra i vincoli, dà esempi, itera |
| Lettura critica | Accetta generazioni lunghe senza controllo | Rifiuta, modifica, riscrive in pochi secondi |
| Giudizio del leverage | Usa l'IA sulla logica load-bearing | Usa l'IA sul boilerplate, controlla il percorso critico |
| Verifica | Mette in produzione codice non testato o poco testato | Esegue su input reali, legge i diff, verifica i limiti |
| Recupero | Itera con il modello quando bloccato | Torna a leggere il codice o chiede un chiarimento |
Valuta ognuna indipendentemente. Gli scorecard di colloquio strutturato di ClarityHire bloccano questi elementi in modo che i revisori non derivino dopo aver visto l'artefatto.
La walk-through post-sessione
Dedica gli ultimi 15 minuti a tre domande:
- "Mostrami una generazione che hai rifiutato. Perché?"
- "Camminami attraverso la parte di questo che hai scritto da solo, e perché non hai lasciato fare all'IA."
- "Qual è la parte più fragile di quello che abbiamo messo in produzione? Cosa aggiusteresti dopo?"
I candidati che hanno effettivamente ragionato durante la sessione possono rispondere senza indugi. I candidati che hanno accettato qualunque cosa il modello ha prodotto non possono — e il gap emerge nei primi dieci secondi di ogni risposta. Questo è lo stesso test di autorialità che faresti su un esercizio da svolgere a casa, applicato all'uso live dell'IA.
Dove si inserisce nel processo
Tratta questo round come una sostituzione dello standard live coding screen, non come un'aggiunta. Il tuo processo dovrebbe includere comunque un round di system design e un round comportamentale; la domanda a cui questo round risponde è quella precedentemente gestita dallo closed-book coding screen, che ha perso la maggior parte del suo segnale nell'era degli LLM.
Cosa fare dopo
Tre mosse concrete prima del tuo prossimo round con IA consentita:
- Scegli un ruolo e riscrivi la domanda di programmazione live in una che l'IA non possa risolvere in un tentativo ma che un candidato senza IA non riesca a finire.
- Forma i tuoi intervistatori a valutare il flusso di lavoro, non l'artefatto. L'artefatto è ora elemento basilare. Il flusso di lavoro è il segnale.
- Decidi cosa "verificato" significa prima che il candidato arrivi. Bloccare la rubrica in anticipo previene la razionalizzazione post-hoc che rovina la calibrazione.
I team che lo capiscono bene nel 2026 assumeranno meglio di quelli che fingono che il modello non sia nella stanza. La competenza è reale, il gap tra utenti forti e deboli è enorme, e il formato di colloquio per misurarla non è più difficile da gestire di quello che sostituisce.