I colloqui tecnici che saltano il live coding puntano su design review, system thinking e code walkthrough. Valutano come si ragiona, si struttura un problema e si comunica una soluzione. Richiedono di gestire requisiti ambigui, presentare trade-off credibili e difendere scelte progettuali sotto pressione. Prepararsi non significa memorizzare pattern, ma costruire un toolkit mentale e operativo per leggere il contesto, prendere decisioni e spiegare con ordine.
Chi convince non è chi ha la risposta perfetta, ma chi esplicita assunzioni, riduce l’incertezza e guida il dialogo con metodo. Servono strutture chiare, rubriche di autovalutazione e mock interview mirate. Questa guida entra nel dettaglio di framework, template e tecniche da usare in fase di studio e il giorno del colloquio.
Capire il formato e tarare le aspettative
Una sessione centrata su design review o code walkthrough misura quattro dimensioni: chiarezza (struttura e linguaggio), correttezza (coerenza tecnica), trade-off (consapevolezza dei costi) e collaborazione (ascolto e domande). Attese tipiche: definire scope, elencare requisiti funzionali e non funzionali, proporre un’architettura baseline, discutere alternative, individuare rischi e piani di test. Nel walkthrough, l’obiettivo è leggere codice reale o snippet, evidenziare complessità, bug potenziali, debt e impatto sulle performance. Prepararsi significa allenarsi a render visibili i passaggi mentali con una narrazione tecnica ordinata.
Preparare una design review: dal problema alla decisione
Per progetti end-to-end, usare una traccia ripetibile riduce il carico cognitivo. Sequenza consigliata: 1) Contesto e obiettivi in 60 secondi (chi è l’utente, qual è il valore). 2) Requisiti F/NF, vincoli e SLA. 3) Assunzioni e rischi. 4) Baseline con diagrammi leggeri (C4 livello Container/Component). 5) Alternative con matrice pro/contro. 6) Trade-off documentati come ADR (Architecture Decision Record). 7) Validazione: test strategy, osservabilità, rollback. Portare esempi concreti (p.es. cache TTL, politiche di retry, backoff, idempotenza) mostra padronanza pratica, non solo teoria.
System thinking: requisiti, carichi, failure modes
La prospettiva di system thinking chiede di collegare parti e impatti. Allenarsi a stimare ordini di grandezza (RPS, p95 latency, throughput) con calcoli a spanne e a verificare colli di bottiglia: I/O, lock contention, chiamate esterne. Esplicitare modi di guasto: cosa succede se un servizio è lento, se la rete degrada, se la cache invalida male? Descrivere circuit breaker, timeouts e backpressure. Per i dati, chiarire schema evolution, migrazioni e politiche di consistenza (eventuale vs strong). Per la sicurezza: threat model ad alto livello, principi di least privilege, audit trail. Una mappa mentale stabile: input → elaborazione → storage → uscita → osservabilità.
Code walkthrough: leggere, ipotizzare, verificare
Nel code walkthrough serve metodo. Passi consigliati: 1) Orientamento rapido (entry points, dipendenze, test). 2) Lettura top-down di funzioni critiche, segnando code smells (funzioni troppo lunghe, mutable state condiviso, accoppiamento eccessivo). 3) Verifica di edge cases: nullability, error handling, time zones, concorrenza. 4) Performance: complessità, allocazioni, N+1 query, accesso disco/rete. 5) Manutenibilità: naming, purezza, separazione dei livelli. Concludere proponendo micro-refactor con impatto misurabile (p.es. introdurre un Repository, rendere una funzione pura, aggiungere test di regressione) e un piano di rollout sicuro.
Presentare trade-off e gestire domande aperte
Alle domande aperte conviene rispondere con una cornice. Tecnica di base: chiarire lo scopo, porre 2-3 domande di contesto, fissare assunzioni. Poi proporre una soluzione baseline e due varianti estreme, spiegando il perimetro in cui ciascuna vince. Usare linguaggio di costo: complessità operativa, time-to-market, costo infrastrutturale, rischio. Visualizzare i compromessi con una tabella mentale: caching aggressiva → latenza bassa ma consistenza debole; sharding → scalabilità ma operazioni più complesse; transazioni distribuite → correttezza forte ma throughput minore. Chiudere con un criterio decisionale (SLA, traffico atteso, vincoli di compliance) e un esperimento minimo per validare.
Toolkit di studio: template, rubriche, mock mirate
Un set essenziale accelera la preparazione. 1) Template di design: pagina unica con sezioni fisse (obiettivi, requisiti, ADR, diagrammi C4, rischi, test/observability). 2) Rubrica di valutazione personalizzata con punteggi 1–4 su chiarezza, correttezza, trade-off, comunicazione. 3) Catalogo di casi da 30–45 minuti: feed in tempo reale, API rate-limited, job scheduler, ricerca full-text, carrello e pagamenti, pipeline ETL. 4) Mock interview settimanali: alternare ruoli interviewer/candidate, cronometrare, registrare audio/video, rivedere con la rubrica. 5) Deck di domande di follow-up per allenare l’adattabilità: cosa cambia con multi-region? come gestire schema drift? se il budget dimezza?
Strutture di comunicazione che fanno la differenza
Un buon contenuto può perdersi senza forma. Tecniche utili: top-down (prima il quadro, poi i dettagli), piramide (conclusione → argomenti → evidenze), STAR per racconti di incidenti e ottimizzazioni. Tenere frasi brevi, numeri rotondi e terminologia coerente. Chiedere pause consapevoli per fare sintesi. Usare lavagna mentale con tre colonne: ipotesi, opzioni, rischi. Nelle review a schermo, evidenziare con cursore i punti chiave e nominare le sezioni del diagramma. Concludere ogni blocco con una decisione provvisoria e un test per falsificarla.
Piano di 7 giorni e checklist delle 24 ore
Piano rapido: Giorno 1–2, ripasso di pattern e failure modes; Giorno 3, casi di design con template; Giorno 4, code walkthrough su repo open-source piccoli; Giorno 5, mock cronometrata con rubrica; Giorno 6, revisione errori ricorrenti e ADR sintetici; Giorno 7, simulazione completa con timing reale. Nelle 24 ore: rilegge 2 ADR, memorizza metriche chiave (p95, throughput), prepara 3 storie STAR, controlla ambienti e strumenti (diagrammi offline), definisce domande iniziali pronte. Ultimo accorgimento: portare una micro-checklist visiva per aprire il colloquio con struttura e sicurezza.
