Un candidato mid-level, in un colloquio da remoto, risponde a "Qual è la differenza tra switchMap e mergeMap?" con una definizione perfetta, dopo una pausa di tre secondi. Due domande dopo gli chiedi quale dei due userebbe in una barra di ricerca, e perché. Silenzio. La prima domanda ha misurato la sua velocità nel consultare un assistente IA; la seconda ha misurato quello che ti serviva davvero sapere.
Ho fatto colloqui da entrambi i lati del tavolo, e la domanda che mi pongo sempre più spesso è semplice: oggi, con un assistente IA in ogni editor, ha ancora senso fare le domande classiche da colloquio?
Cosa è cambiato davvero
Le domande "da manuale" — definizioni, differenze tra due concetti, elenchi di caratteristiche — sono sempre state un'approssimazione: si dava per scontato che chi conosce la teoria sappia anche applicarla. Era un'approssimazione accettabile quando ricordare costava fatica. Oggi ricordare non costa niente: qualunque definizione è a portata di prompt, durante il colloquio e soprattutto dopo, nel lavoro vero.
Ed è proprio questo il punto: lo sviluppatore che assumi lavorerà con l'IA. Quello che conta non è più cosa sa a memoria, ma tre cose che l'IA non fa al posto suo:
- Giudizio: scegliere tra due soluzioni corrette in base al contesto.
- Verifica: accorgersi quando il codice generato è sbagliato, anche se compila.
- Contesto: capire il problema reale prima di scrivere una riga.
Mid e senior: le domande classiche non bastano più
Per un profilo mid o senior le domande teoriche isolate sono quasi inutili: un buon candidato le supera, ma le supera anche uno mediocre con un secondo schermo. Non vanno eliminate del tutto — vanno usate come punto di partenza per scendere in profondità. Ecco cinque formati che funzionano.
1. Code review di codice generato dall'IA
Dai al candidato un frammento plausibile, come quelli che un assistente produce ogni giorno, e chiedigli di revisionarlo come farebbe con la pull request di un collega:
// Product search bar
this.results$ = this.query$.pipe(
debounceTime(300),
mergeMap(q => this.api.search(q))
);Il codice funziona quasi sempre. Un senior deve notare che con mergeMap una risposta lenta per "ang" può arrivare dopo quella per "angular" e sovrascrivere i risultati corretti: serve switchMap, che annulla la richiesta precedente. Punti extra se chiede cosa succede con la stringa vuota o con un errore HTTP, che qui chiuderebbe lo stream per sempre.
Lo stesso esercizio funziona sul backend:
async function getOrders(userIds) {
const result = [];
for (const id of userIds) {
result.push(await db.orders.find({ userId: id }));
}
return result;
}Qui si cercano le N query sequenziali, l'assenza di paginazione e la proposta di un'unica query con $in. Non c'è una definizione da recitare: o vedi il problema o non lo vedi.
2. Scenari al posto delle definizioni
Invece di "Cos'è la change detection?" chiedi: "Una tabella con 5.000 righe diventa lenta quando l'utente scrive nel filtro. Ecco il profiler: da dove parti?". Invece di "Cos'è Redis?": "Abbiamo una cache in memoria e passiamo da una a tre istanze del backend. Cosa si rompe?". Le risposte mostrano subito se il candidato ha risolto problemi simili o ne ha solo letto.
3. Il racconto di un problema reale
"Raccontami il bug più difficile che hai risolto in produzione" resta una delle domande migliori, a patto di scavare con le domande successive: come te ne sei accorto? Quale ipotesi hai scartato per prima? Cosa hai cambiato perché non succedesse più? Un'esperienza vissuta regge cinque livelli di "perché"; una storia preparata crolla al secondo.
4. Pair programming con l'IA consentita
Invece di vietare gli strumenti, permettili e osserva come vengono usati. Un compito di 30-40 minuti su un piccolo repository reale, con l'assistente IA attivo. Non stai valutando il risultato ma il processo: il candidato legge il codice prima di chiedere? Scrive prompt precisi o generici? Scarta un suggerimento sbagliato o lo accetta perché compila? Aggiunge un test?
5. Trade-off e decisioni
Per un senior conta la capacità di decidere sotto vincoli: "Abbiamo due settimane e un team di tre persone: riscriviamo il modulo o lo mettiamo in sicurezza con dei test?". Non esiste una risposta giusta: esiste un ragionamento che considera rischio, costo e reversibilità, ed è esattamente quello che vuoi sentire.
Junior: come dovrebbe svolgersi il colloquio
Con i junior il problema è opposto. Non hanno esperienza da raccontare, e una code review complessa li penalizzerebbe ingiustamente. Ma proprio per loro il rischio legato all'IA è più alto: è facile produrre codice funzionante senza capirlo. Il colloquio deve quindi misurare comprensione e capacità di apprendimento, non la quantità di nozioni.
Uno schema da 60 minuti che uso e consiglio:
| Tempo | Attività | Cosa valuta |
|---|---|---|
| 10 min | Un progetto personale o universitario: cosa hai fatto tu, cosa rifaresti diversamente | Consapevolezza, onestà |
| 15 min | Leggere un breve codice e prevederne l'output, riga per riga | Fondamenti reali |
| 20 min | Piccolo task con IA consentita, poi domande su ogni riga scritta | Comprensione, verifica |
| 10 min | La documentazione di un'API mai vista: usarla per un caso semplice | Capacità di imparare |
| 5 min | Domande del candidato | Curiosità, interesse |
Un esempio di esercizio di lettura, perfetto per un junior JavaScript:
for (var i = 0; i < 3; i++) {
setTimeout(() => console.log(i), 0);
}
// Cosa stampa? E se usiamo let al posto di var?Non conta che il junior conosca a memoria la risposta (3 3 3, poi 0 1 2): conta che, guidato, arrivi a spiegare il perché — lo scope della variabile e l'esecuzione asincrona. È una domanda classica, ma usata per far ragionare, non per verificare un ricordo.
Nella parte con l'IA, la domanda chiave arriva dopo il codice: "Cosa succede se l'array è vuoto? E se arriva null?". Un junior che ha capito ci ragiona, anche sbagliando; uno che ha solo incollato la risposta non sa da dove cominciare. In entrambi i casi hai un'informazione preziosa.
Domanda classica → versione aggiornata
| Domanda classica | Versione aggiornata |
|---|---|
| Cos'è una closure? | Questo codice ha un memory leak: dove, e perché? |
| Differenza tra SQL e NoSQL? | Per questo caso d'uso quale scegli, e cosa perdi? |
| Quali sono i principi SOLID? | Questa classe è difficile da testare: come la ristrutturi? |
| Cos'è il lazy loading? | Il bundle iniziale pesa 4 MB: cosa controlli per primo? |
| Come funziona un JWT? | Un token rubato resta valido 30 giorni: cosa cambi? |
Cosa eliminare (o quasi)
- Definizioni a memoria come unica prova: misurano la ricerca, non la competenza.
- Esercizi a casa da 8 ore: un'IA li completa in mezz'ora, e penalizzano chi ha meno tempo libero.
- Live coding senza internet né strumenti: valuta una situazione che nel lavoro reale non esiste.
- Vietare l'IA al colloquio e pretenderne l'uso dal primo giorno: è incoerente, e i candidati migliori lo notano.
In sintesi
Le domande classiche non sono morte, ma da sole non misurano più quello che conta. Per mid e senior servono code review, scenari reali e decisioni sotto vincoli, possibilmente con l'IA sul tavolo per vedere come la governano. Per i junior servono esercizi di lettura del codice, domande sul "perché" e una prova di apprendimento: non quanto sanno già, ma quanto velocemente e onestamente imparano. In un mondo in cui il codice si genera in pochi secondi, il vero talento è capire quando quel codice è sbagliato. Se ti stai preparando dall'altra parte del tavolo, trovi le domande tecniche organizzate per livello nella guida alle 25 domande da colloquio frontend/Angular.