
Perché questi colloqui pesano più di quanto gli sviluppatori si aspettino
La maggior parte degli sviluppatori si prepara fin troppo sugli algoritmi e tratta il colloquio comportamentale come una chiacchierata. Le commissioni di selezione fanno il contrario: le prove di coding sono filtri che si superano o no, mentre gli elementi raccolti nel colloquio comportamentale decidono il livello e gli spareggi. Chi valuta cerca segnali precisi: ownership oltre il tuo ticket, capacità di giudizio nell'incertezza, come metabolizzi i fallimenti e se lavorare con te dà energia o la toglie. Ogni domanda qui sotto rimanda a uno di questi segnali.
Struttura le risposte con STAR (i pesi che funzionano sono nella nostra raccolta di domande per il colloquio): dieci secondi di premessa, azioni in prima persona, risultati con i numeri.
Domande sui disaccordi tecnici
“Raccontami di una volta in cui non eri d'accordo con l'approccio tecnico di un collega.” “Il tuo tech lead ha scelto un design che ritenevi sbagliato: che cosa hai fatto?”
La trappola è raccontare una storia in cui avevi semplicemente ragione. Il segnale che gli intervistatori cercano è come hai espresso il disaccordo: avevi capito l'altra posizione tanto da saperla esporre in modo equo? Hai trasformato l'opinione in prove, cioè un benchmark, un prototipo, uno scenario di guasto messo per iscritto? Hai sostenuto la decisione senza riserve, una volta presa nell'altra direzione?
Uno schema solido: “Io pensavo X, loro Y. Y aveva un vantaggio reale, che ho riconosciuto: [dillo]. Ho costruito un piccolo benchmark per verificare il mio dubbio; ha mostrato [numero]. Abbiamo scelto una versione modificata di Y che gestiva l'hot path. Che cosa mi porto dietro: trasformare la discussione in un esperimento ha richiesto un pomeriggio e ha fatto risparmiare tre settimane di dibattito.”
Domande su incidenti e fallimenti
“Raccontami di una volta in cui hai rotto la produzione.” “Descrivi il tuo peggior disservizio.” “Un bug che hai rilasciato ha danneggiato gli utenti: raccontami com'è andata.”
Ogni sviluppatore senior ha rotto la produzione almeno una volta; fingere il contrario passa per inesperienza o per disonestà. La valutazione riguarda interamente il tuo rapporto con l'errore:
- Assumiti la catena delle decisioni. “Ho saltato il canary perché il diff sembrava banale” batte “il sistema di deploy lo permetteva”.
- Mostra disciplina nella gestione dell'incidente. Rilevamento, prima la mitigazione, poi la causa principale, comunicazioni ai team coinvolti.
- Chiudi con la correzione di sistema. La classe di test che ora esiste, l'alert che ora scatta, la voce di checklist che ora blocca il rilascio. La cultura del post-mortem senza colpevoli è la parola d'ordine; la correzione di sistema è la prova che la pratichi davvero.
Domande su ownership e iniziativa
“Raccontami di qualcosa che hai migliorato senza che nessuno te lo chiedesse.” “Una volta in cui hai fatto più di quanto prevedeva il tuo ruolo.”
Il segnale che distingue un profilo intermedio da un senior è l'ampiezza della responsabilità che senti tua: il tuo ticket, i risultati del tuo team, la traiettoria dell'organizzazione. Buon materiale di partenza: la suite di test instabile che hai sistemato sbloccando tutti, la migrazione che hai proposto e portato avanti, il runbook per la reperibilità che hai scritto dopo un turno pesante, la dipendenza tra team che hai sbrogliato. Includi anche il costo poco glorioso (“ci ho passato due venerdì”): sono i dettagli sui costi che nessuno ti ha ripagato a rendere credibili le storie di iniziativa.
Domande sul giudizio tecnico
“Raccontami una decisione tecnica difficile.” “Una volta in cui hai scelto ‘abbastanza buono’ invece di ‘giusto’.” “Descrivi un trade-off che hai sbagliato.”
Servono a capire se ragioni per trade-off o per assoluti. Una risposta da senior nomina gli assi in modo esplicito (latenza o costo, data di consegna o debito tecnico, sviluppare in casa o comprare), indica il vincolo che ha prevalso e descrive il processo decisionale: che cosa hai prototipato, chi hai consultato, che cosa ti avrebbe fatto cambiare idea. Se la domanda riguarda una scelta sbagliata, la lezione deve essere operativa (“ora metto per iscritto i criteri per tornare indietro prima di impegnarmi”), non sentimentale (“ho imparato a fare attenzione”).
Domande su collaborazione e code review
“Come gestisci una review in cui l'autore fa resistenza?” “Una volta in cui hai ricevuto un feedback duro.” “Come fai l'onboarding di uno sviluppatore junior?”
- Conflitti in code review: separa le obiezioni bloccanti (correttezza, sicurezza) dalle preferenze (stile); sulle preferenze cedi in modo esplicito. Dire ad alta voce questa distinzione è già di per sé il segnale da senior.
- Ricevere feedback: scegli una storia in cui il feedback ha fatto male ed era giusto. L'arco è: reazione difensiva iniziale → verifica → comportamento cambiato, con le prove.
- Mentoring: i meccanismi concreti battono le buone intenzioni: cadenza del pair programming, “prima PR nella prima settimana”, responsabilità crescenti, lasciare che gestiscano un incidente con te come rete di sicurezza.
15 domande comportamentali per allenarti
Allenati ad alta voce e con il cronometro: registrando la tua voce, oppure in una simulazione con un assistente AI per colloqui di lavoro che trascrive e ti restituisce un resoconto. Punta a sei storie riutilizzabili che coprano tutto l'elenco:
- Una volta in cui non eri d'accordo con il tuo tech lead e avevi torto.
- Una volta in cui non eri d'accordo e avevi ragione: come hai convinto gli altri?
- Il tuo peggior incidente in produzione, dall'inizio alla fine.
- Un progetto finito in forte ritardo: che cosa hai fatto quando hai visto che stava slittando?
- Qualcosa che hai costruito senza che nessuno lo chiedesse. Ne è valsa la pena?
- La decisione tecnica più difficile della tua carriera.
- Una volta in cui hai scelto la velocità a scapito della qualità. Lo rifaresti?
- Una volta in cui hai ereditato codice pessimo. Che cosa hai fatto, in concreto?
- Un feedback duro che hai ricevuto e che cosa è cambiato.
- Una discussione nei commenti di una review che si è scaldata.
- Come hai aiutato un collega in difficoltà a rimettersi in carreggiata.
- Una volta in cui hai dovuto dire di no a un product manager.
- Il lavoro di cui vai più fiero, e il suo compromesso più grande.
- Una volta in cui in review ti è sfuggito qualcosa di importante.
- Perché vuoi cambiare, e perché proprio qui? (Preparala fino a saperla a menadito: lo schema generale è nella raccolta.)
Le tue storie, nitide anche sotto pressione.
ChadFlow ascolta il colloquio, ti passa una prima frase ancorata al tuo contesto quando arriva la domanda e dopo ti fa da coach sulla trascrizione: invisibile in condivisione schermo.
Scarica ChadFlow