Ciao, e benvenuto nella settima puntata della quarta stagione. Oggi affrontiamo una prova che compare quasi sempre nei loop delle grandi aziende e che spaventa in modo diverso dalle altre: il colloquio di progettazione di sistemi. Se i problemi algoritmici sono rompicapi chiusi con una soluzione, questo è l'opposto: una discussione aperta, senza una risposta unica, in cui devi progettare a grandi linee un sistema che funzioni su scala enorme.
Cominciamo dal capire cos'è. Ti viene dato un compito volutamente vago e ambizioso, del tipo "progetta un servizio che faccia questo per milioni di utenti". Non devi scrivere codice; devi ragionare ad alta voce su come costruiresti l'intera impalcatura: quali pezzi servono, come si parlano tra loro, dove si salvano i dati, come si regge il carico quando gli utenti diventano tantissimi. È un disegno ad alto livello, fatto di riquadri e frecce e di ragionamento, non di righe di codice.
La prima cosa da chiarire, perché toglie ansia, è che non esiste la risposta giusta. In un problema algoritmico c'è una soluzione corretta; qui no. Ci sono tante soluzioni possibili, ognuna con dei compromessi. Chi ti valuta non aspetta che tu indovini un disegno perfetto: vuole vedere come pensi, come affronti l'incertezza, se capisci i compromessi tra una scelta e l'altra, se sai comunicare un'idea complessa in modo chiaro. Il processo, ancora una volta, conta più del risultato, ma qui è ancora più vero.
E qui c'è un punto importante da chiarire subito: quanto pesa questa prova dipende molto dal livello del ruolo. Per una posizione da principiante, spesso la progettazione di sistemi ha un peso minore, o viene chiesta in forma molto più semplice, perché non ci si aspetta che tu abbia ancora esperienza di sistemi grandi. Diventa invece centrale, e a volte decisiva, per i ruoli più esperti. Quindi calibra la tua preparazione: se parti da zero, non farti travolgere dall'ansia per questa prova, ma conoscine le basi; se punti a un ruolo senior, è qui che devi essere davvero forte.
Come si affronta, in pratica? La prima mossa, cruciale, è non buttarsi subito a disegnare. Come per i problemi di programmazione, ma ancora di più, devi prima chiarire il problema. Il compito è volutamente vago: fai domande per definire i confini. Quante persone lo useranno? Quali funzioni sono davvero essenziali e quali possiamo tralasciare? Cosa conta di più, la velocità o l'affidabilità? Definire il perimetro prima di progettare non è perdere tempo: è la prima cosa che fa un buon ingegnere, ed è essa stessa parte della valutazione.
Dopo aver chiarito, la strategia vincente è partire semplice e poi crescere. Comincia da una versione base del sistema, i pochi pezzi essenziali che risolvono il problema centrale. Falla funzionare a parole, poi, un passo alla volta, aggiungi complessità: cosa succede quando gli utenti aumentano di cento volte? Dove si crea un collo di bottiglia? Come lo risolveresti? Questo modo di procedere, dal semplice al complesso, mostra un ragionamento ordinato ed è molto più efficace che riversare subito sul tavolo ogni tecnologia complicata che conosci.
Un errore tipico, soprattutto di chi ha studiato tanto, è proprio questo: sfoggiare parole difficili e soluzioni sofisticate senza motivo, per fare colpo. È controproducente. Chi ti valuta vuole capire se sai perché scegli una cosa, non se conosci il nome di tante cose. Ogni scelta che proponi dovresti saperla giustificare, e saper dire cosa ci guadagni e cosa ci perdi. Dire "userei questa soluzione perché risolve questo problema, al costo di quest'altro" vale mille volte di più che elencare tecnologie alla moda senza spiegare il perché.
E la comunicazione, qui, è metà della prova. Stai progettando qualcosa di complesso a voce, davanti a una persona: devi renderlo comprensibile. Struttura il ragionamento, procedi con ordine, usa lo spazio di disegno per farti seguire, verifica ogni tanto che chi ti ascolta stia capendo dove vuoi arrivare. Una progettazione anche buona, ma spiegata in modo confuso e caotico, fa una brutta impressione. Riprendo un filo di tutte le stagioni: saper comunicare un'idea tecnica è una competenza in sé, e qui viene messa alla prova in modo diretto.
Come ci si prepara, se non si ha esperienza diretta di sistemi enormi? Studiando i concetti di base di come si costruiscono sistemi che reggono tanti utenti, che sono ormai spiegati in tante risorse dedicate, e soprattutto esercitandosi a ragionare ad alta voce su problemi di progettazione, meglio se con qualcuno che faccia da interlocutore. Come per gli algoritmi, non basta leggere: bisogna praticare il ragionamento, perché è quello, non la nozione, che ti chiederanno di mettere in campo.
Per oggi ci fermiamo qui. La progettazione di sistemi è una prova aperta, senza risposta unica, che valuta come pensi, come gestisci l'incertezza e come comunichi scelte complesse. Chiarisci il problema prima di progettare, parti semplice e cresci a passi, giustifica ogni scelta con i suoi compromessi, e cura la chiarezza. E ricorda che il suo peso dipende dal livello: fondamentale per i ruoli esperti, più leggera per chi comincia. Nella prossima puntata torniamo sull'umano, con le domande comportamentali e i valori aziendali. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.