Quarantacinque minuti, un editor condiviso, uno sconosciuto che guarda ogni tasto e un problema mai visto prima: invertire una lista concatenata, trovare il sottoarray con la somma massima. Niente documentazione, niente ricerca, a volte nemmeno l'autocompletamento. E in più ti chiedono di "pensare ad alta voce". È il live coding, e in molti processi di selezione è ancora il momento che decide tutto.
Io sono contrario. Non perché sia difficile, ma perché misura la cosa sbagliata. Ho fatto colloqui da entrambi i lati del tavolo e in un altro articolo ho scritto come cambierei le domande tecniche nell'era dell'IA. Qui vado dritto al punto: perché il live coding classico non funziona, cosa concedo a chi lo difende e cosa farei al suo posto.
Di quale live coding parlo
Una distinzione, prima di tutto. Sono contrario all'esercizio algoritmico a tempo, osservato in diretta, senza strumenti, su un problema scollegato dal lavoro, il cui esito decide da solo se vai avanti o no. Non sono contrario a lavorare insieme a un candidato su un compito realistico, con documentazione e strumenti a disposizione, guardando come ragiona. Sembrano la stessa cosa, ma non lo sono: ci torno alla fine.
Misura lo stress, non la competenza
Non è solo un'impressione. Nel 2020 alcuni ricercatori della North Carolina State University e di Microsoft hanno pubblicato uno studio controllato su 48 studenti di informatica: metà ha risolto un problema alla lavagna davanti a un intervistatore, metà da sola, in una stanza privata. Chi era osservato ha ottenuto risultati peggiori di oltre la metà. Gli autori fanno notare che il formato somiglia in modo inquietante al Trier Social Stress Test, un protocollo usato in psicologia proprio per indurre stress.
Lo studio è piccolo e fatto su studenti, quindi non lo prendo come una legge. Ma conferma quello che chiunque abbia sostenuto un colloquio conosce bene: sotto osservazione la memoria di lavoro si restringe, si perde il filo, si sbagliano cose banali che in condizioni normali non si sbaglierebbero mai. Il risultato non risponde alla domanda "sa programmare?", ma a un'altra: "quanto bene programma mentre qualcuno lo giudica in diretta?". E nel lavoro vero quella situazione non esiste.
Il lavoro vero non assomiglia a un live coding
| Nel live coding | Nel lavoro vero |
|---|---|
| 45 minuti per un problema mai visto | Ore o giorni, con il tempo di capire il problema |
| Niente documentazione né ricerca | Documentazione, ricerca ed esempi sempre aperti |
| Assistente IA vietato | Assistente IA nell'editor, tutti i giorni |
| Un estraneo che osserva ogni tasto | Concentrazione, e la review arriva dopo |
| Algoritmi da manuale | Leggere codice esistente, integrare API, correggere bug |
| Conta arrivare a una soluzione | Contano leggibilità, test e manutenzione nel tempo |
Chi verrà assunto passerà le giornate a leggere codice scritto da altri, a scegliere una libreria, a capire perché un test fallisce solo in CI. Valutarlo sulla capacità di implementare a memoria un algoritmo, in mezz'ora e sotto gli occhi di qualcuno, vuol dire misurare un'abilità che userà raramente, nelle condizioni in cui non lavorerà mai.
Premia chi si allena al formato, non chi lavora bene
Il live coding algoritmico è diventato una disciplina a sé, con piattaforme, corsi e centinaia di esercizi da ripetere fino a riconoscerli a colpo d'occhio. Chi ha settimane libere per allenarsi arriva preparato. Chi lavora a tempo pieno, ha una famiglia o semplicemente passa il tempo a costruire software vero invece di risolvere puzzle, parte in svantaggio. Alla fine il colloquio seleziona soprattutto la preparazione al colloquio.
E penalizza in modo sistematico alcune persone: chi soffre d'ansia, chi è neurodivergente, chi sostiene il colloquio in una lingua che non è la sua e deve pensare ad alta voce mentre traduce nella propria testa. Nessuna di queste cose dice qualcosa su come quella persona scriverà codice in un team.
Costa anche all'azienda
Di solito si parla del candidato, molto meno dell'azienda. Ogni falso negativo è uno sviluppatore valido scartato perché si è bloccato per dieci minuti. E chi ha esperienza e alternative, spesso, un processo con il live coding lo evita del tutto: l'azienda quei candidati non li vede nemmeno.
C'è anche un effetto meno visibile. Osservando qualcuno sotto pressione, l'intervistatore finisce per valutare la sicurezza più della sostanza: chi parla con disinvoltura sembra più bravo di chi tace e pensa. È un bias che esiste in ogni colloquio, ma questo formato lo amplifica.
Cosa concedo a chi lo difende
- Verificare che una persona sappia davvero programmare è legittimo. Un curriculum si può gonfiare, e oggi anche un esercizio da fare a casa si può far risolvere a un'IA.
- I compiti a casa lunghi hanno un costo reale: ore di lavoro non pagato, spesso sproporzionate rispetto alla posizione.
- Il live coding è economico e uniforme: lo stesso esercizio per tutti, un'ora e si chiude.
Sono obiezioni serie. Ma la risposta a "dobbiamo verificare le competenze" non può essere un formato che le misura male. Serve un formato che verifichi la stessa cosa senza la parte che distorce il risultato.
Cosa farei al suo posto
- Code review di codice reale. Un frammento plausibile, con un bug e qualche scelta discutibile, da commentare come se fosse la pull request di un collega. Si vede subito chi capisce il codice, e nessuno deve scrivere sotto dettatura.
- Il progetto del candidato. Un repository, un lavoro precedente, un progetto personale: "spiegami questa scelta", "cosa cambieresti oggi". Un'esperienza vissuta regge cinque domande di approfondimento; una storia imparata a memoria crolla alla seconda.
- Un compito breve a casa, seguito da una discussione. Due o tre ore al massimo, pagate se possibile, e poi una conversazione in cui il candidato spiega e modifica la propria soluzione. Se l'ha scritta un'IA senza capirla, bastano pochi minuti di domande per accorgersene.
- Pair programming su un compito realistico. Se proprio si vuole vedere qualcuno scrivere codice: un piccolo repository vero, documentazione e IA consentite, nessun cronometro sul risultato. L'intervistatore lavora con il candidato invece di sorvegliarlo.
- Una sessione di debugging. Un test che fallisce e il tempo per capire perché: è la cosa più vicina a una normale giornata di lavoro.
Se il live coding resta, almeno così
Capisco che non tutte le aziende cambino processo da un giorno all'altro. Se il live coding resta, ci sono alcune regole minime che lo rendono meno ingiusto:
- comunicare in anticipo formato, durata e linguaggio;
- scegliere un problema legato al lavoro, non un rompicapo da manuale;
- permettere documentazione e ricerca, come in qualsiasi giornata normale;
- valutare il ragionamento, non solo il risultato finale;
- lasciare al candidato qualche minuto per leggere e pensare in silenzio prima di chiedergli di parlare.
E se il candidato sei tu
Puoi chiedere, con garbo, un'alternativa: una code review, la discussione di un tuo progetto, un compito breve da fare a casa. Non tutte le aziende accetteranno, ma chiedere non costa nulla. E la risposta dice già molto su come lavorano: un'azienda che non sa spiegare perché usa un certo formato, probabilmente, non se l'è mai chiesto.
In sintesi
Sono contrario al live coding classico perché misura come una persona regge lo stress di essere osservata, non come lavora. È un cattivo affare per il candidato e anche per l'azienda, che scarta persone valide e seleziona chi si è allenato al formato. Le alternative esistono e verificano la stessa cosa, cioè se una persona sa programmare, senza distorcere il risultato. Ho raccolto altre idee su come rinnovare i colloqui tecnici in questo articolo, e se ti stai preparando a un colloquio trovi le domande tecniche organizzate per livello nella guida alle 25 domande da colloquio frontend/Angular.
