Errore n. 1: buttarsi sul codice senza chiarire i requisiti
Arriva la domanda. Il tuo istinto è iniziare subito a scrivere codice per mostrare velocità e sicurezza. Quasi sempre è sbagliato.
I problemi dei colloqui tecnici non sono quasi mai semplici come sembrano all'inizio. I vincoli sono nascosti, i casi limite sono omessi di proposito e l'interpretazione «corretta» dipende spesso da informazioni che non hai ancora. Buttarsi subito sull'implementazione del problema come lo hai capito, prima di confermare di averlo capito bene, è il modo in cui i candidati passano 20 minuti a risolvere il problema sbagliato.
Ancora più importante, chi intervista lascia deliberatamente ambigui i requisiti per vedere se riconosci l'ambiguità e fai buone domande. Un candidato che chiede «Posso assumere che l'array in input sia ordinato?» prima di scrivere codice dimostra lo stesso giudizio che un buon ingegnere porta nei progetti reali. Un candidato che assume in silenzio che l'array sia ordinato, e costruisce attorno a quell'assunzione, dimostra l'opposto.
Prima di scrivere una sola riga di codice, verbalizza ciò che hai capito del problema e fai almeno due domande di chiarimento: una sui vincoli (dimensione dell'input, tipi di dati attesi, casi limite) e una sui requisiti (cosa deve restituire la funzione con input vuoto? e se ci sono duplicati?). Poi conferma: «Quindi il mio obiettivo è restituire X dato Y: è corretto?» Solo allora inizia a scrivere codice.
Errore n. 2: restare in silenzio mentre si risolve il problema
È l'errore che costa più offerte perché è invisibile a chi lo commette. Stai pensando. Intensamente. Stai facendo progressi reali. Ma lo fai tutto nella tua testa e chi intervista ti guarda scrivere in silenzio, senza poter capire se sei sulla strada giusta, completamente perso o solo lento.
Chi conduce i colloqui tecnici non valuta solo la tua soluzione: valuta com'è lavorare con te. Un collega che va in silenzio davanti a un problema difficile è qualcuno che non si riesce a tarare, non si riesce ad aiutare e con cui non si riesce a collaborare. Il candidato silenzioso manda esattamente quel segnale, anche se la soluzione finale è corretta.
Pensa ad alta voce. Di' cosa stai considerando e perché lo scarti: «Penso prima a un approccio brute force O(n²) solo per stabilire la correttezza, poi guarderò come ottimizzare.» Di' quando sei bloccato: «So che devo tenere traccia degli elementi già visti: sto decidendo tra una hash map e un array ordinato.» Questa narrazione permette a chi intervista di vedere il tuo processo di pensiero, aiutarti se stai deviando e valutare il tuo approccio alla risoluzione dei problemi indipendentemente dal fatto che arrivi alla soluzione ottimale.
Se il silenzio è un'abitudine sotto pressione, esercitati con uno strumento di colloquio simulato dal vivo: InterviewAce può segnalarti quando diventi troppo silenzioso e invitarti a verbalizzare il ragionamento.
Errore n. 3: non testare né fare il debug della soluzione
Molti candidati scrivono la soluzione, la guardano un attimo e dicono «Penso che sia giusta», poi la consegnano. Questo segnala che non hai l'istinto di testare il tuo lavoro, uno degli istinti più importanti dell'ingegneria del software.
Chi intervista nelle aziende solide ha spesso una policy silenziosa: una soluzione non testata dal candidato è considerata incompleta, anche se sembra corretta. Vogliono vedere che applichi le stesse abitudini che porteresti in una vera pull request.
Dopo aver scritto la soluzione, ripercorrila sempre a mano con almeno due casi di test: un caso normale e uno limite. Segui ogni riga, tieni traccia dei valori delle variabili e verifica l'output. Racconta mentre lo fai: «Ok, se l'input è [3, 1, 4], a questo passaggio i è 0 e current_max è 3, quindi...» Questo processo trova bug reali e dimostra maturità ingegneristica. Per i casi limite, ragiona in modo sistematico su: input vuoto, input con un solo elemento, elementi tutti uguali, numeri negativi (se applicabile) e dimensione massima possibile dell'input.
Errore n. 4: comunicazione debole nel system design
I colloqui di system design sono diversi da quelli di coding in modo cruciale: non esiste una sola risposta corretta. Chi intervista valuta il tuo processo di ragionamento, la consapevolezza dei compromessi e la capacità di guidare una conversazione di progettazione. I candidati che presentano con sicurezza un solo progetto, senza esplorare alternative né riconoscere i compromessi, spesso falliscono i round di system design anche quando la loro architettura è tecnicamente solida.
Modalità di fallimento comuni: buttarsi subito sui diagrammi dei componenti prima di stabilire requisiti e scala, usare parole d'ordine («useremo Kafka per lo stream di eventi») senza spiegarne il motivo e non citare i compromessi («un database relazionale qui va bene, ma a 10 volte la scala attuale inizieremmo a vedere contesa in scrittura su questa tabella»).
Struttura ogni risposta di system design con lo stesso approccio in cinque passi: (1) Chiarisci requisiti e vincoli, funzionali e non funzionali, e aspettative di scala. (2) Stima la scala: QPS, volume dei dati, rapporto lettura/scrittura. (3) Proponi un progetto ad alto livello: componenti principali, flussi di dati. (4) Approfondisci le parti interessanti, dove sta la complessità. (5) Discuti compromessi e alternative: cosa hai scelto e perché non hai scelto le alternative.
Fai abitudine di dire «Ho scelto X rispetto a Y per via del compromesso Z». Ai livelli senior chi intervista valuta se capisci perché il tuo progetto fa quei compromessi, non solo che funziona.
Errore n. 5: arrendersi invece di pensare ad alta voce
Quando i candidati incontrano un vero muro, senza vedere la strada, spesso vanno in silenzio, si bloccano e alla fine dicono «Non so come procedere». Questo chiude il colloquio e azzera ogni possibilità di ripresa, anche se avrebbero trovato la soluzione con altri 2 minuti di ragionamento strutturato.
Ecco qualcosa che la maggior parte dei candidati non sa: la maggior parte di chi intervista vuole dare suggerimenti. Non è lì per vederti fallire: cerca di capire dove sta il tuo limite, e un bravo intervistatore ti guida oltre un blocco per vedere fin dove arrivi con un supporto. Ma può aiutarti solo se sa dove sei bloccato.
Invece di andare in silenzio quando sei bloccato, racconta la situazione: «So che devo tenere un po' di stato tra le iterazioni, ma non vedo subito la struttura dati giusta. Ragiono su quali proprietà contano qui...» Segnala che sei ancora coinvolto, dà a chi intervista lo spiraglio per aiutarti e spesso fa scattare la tua soluzione: l'atto di articolare dove sei bloccato fa emergere spesso la risposta.
Se ti serve davvero un suggerimento, chiedilo in modo diretto e senza imbarazzo: «Credo di aver bisogno di una spinta: c'è una proprietà della struttura dati a cui dovrei pensare?» È professionale. Andare in silenzio no.
Bonus: come prepararsi perché questi errori non accadano
Conoscere questi errori a livello intellettuale non li previene sotto la pressione del colloquio. Per questo conta tanto esercitarsi in condizioni realistiche. Alcuni principi per la preparazione al colloquio tecnico che funzionano:
- Esercitati su una lavagna o un documento condiviso, non nel tuo IDE. Il tuo IDE ha autocompletamento, evidenziazione della sintassi e feedback immediato sugli errori. Le piattaforme dei colloqui no. Allenati senza la rete di sicurezza per non dipenderne.
- Cronometrati sempre. Una soluzione che ottieni in 45 minuti da rilassato potrebbe richiederti 20 minuti in un colloquio, oppure 55. Conosci la tua velocità reale sui problemi di difficoltà media prima di trovarti in una situazione vera.
- Fai almeno 5 colloqui simulati con un intervistatore umano o AI, non solo LeetCode da solo. Le abitudini comunicative (pensare ad alta voce, chiarire i requisiti, testare) vanno costruite con una pratica realistica, non con esercizi di coding in solitaria.
- Fai un debriefing dopo ogni sessione. Quali di questi cinque errori hai commesso? Dove sei andato in silenzio? Cosa hai assunto senza chiedere? Ogni errore in allenamento è uno che non farai nel colloquio vero.
Per esercitarti ai colloqui tecnici con l'aiuto dell'AI, InterviewAce offre sessioni tecniche simulate in cui puoi allenarti a pensare ad alta voce con un'AI che valuta sia la soluzione sia il processo comunicativo. Abbinalo alla guida alla preparazione del colloquio per coprire anche la parte comportamentale e logistica.