Domande per il colloquio da programmatore / sviluppatore software e come rispondere

Domande frequenti per programmatore / sviluppatore software

1. 01

   Raccontami il bug più difficile che hai debuggato. Come l'hai trovato e perché ti ha dato tanto filo da torcere?

   Non descrivere il bug, descrivi il tuo metodo: come l'hai riprodotto, quali ipotesi hai scartato e come hai isolato la causa. Quello che valutano è il tuo processo di debugging, non l'aneddoto.

   «Avevamo un errore nei pagamenti che compariva solo in produzione, una transazione su mille. Per prima cosa sono riuscito a riprodurlo: ho catturato i payload reali dei casi falliti e ho montato un test che li riproduceva in locale. Ho escluso il gateway confrontando i suoi log con i nostri, e ho escluso dati corrotti validando lo schema. Alla fine era una race condition: due webhook dello stesso pagamento arrivavano a millisecondi di distanza e il secondo sovrascriveva il primo. Mi ci è voluta una settimana perché il log aggregato nascondeva l'ordine reale di arrivo. L'ho risolto con un lock per id di pagamento e ho aggiunto un test di concorrenza perché non si ripresentasse.»

2. 02

   Sei in una code review e un collega ti segnala che la tua soluzione non scala. Cosa fai?

   Dimostra che separi l'ego dal codice. Racconta come chiedi il caso concreto che manda in crisi il tuo approccio, quali domande fai per capire il limite reale e quando accetti rispetto a quando difendi con i dati.

   «La prima cosa è chiedergli il caso concreto: a partire da quale volume il mio approccio smette di funzionare? Se mi dice che con 10.000 elementi per richiesta il mio ciclo esplode, lo verifico con dati reali di produzione. Ci è successo con un elenco che avevo risolto in memoria: aveva ragione per il 5% degli account grandi, quindi ho paginato la query. Ma se il caso che mi propone non esiste né nei nostri dati né nella roadmap, lo dico con i numeri: preferiamo la semplicità oggi e lasciamo annotato il limite. Accetto quando c'è evidenza, difendo quando l'evidenza è dalla mia parte, e non lo trasformo mai in qualcosa di personale.»

3. 03

   Progettami a grandi linee un sistema che accorci gli URL (o un feed, un carrello...). Da dove parti?

   Parti dalle domande, non dalla soluzione: volume, letture vs scritture, latenza accettabile. Ragiona sui trade-off ad alta voce (consistenza vs disponibilità, dove mettere la cache) invece di sparare a memoria un'architettura chiusa.

   «Prima di disegnare qualsiasi cosa chiederei tre cose: quanti URL nuovi al giorno e quanti reindirizzamenti?, possono scadere?, conta l'analitica dei click? Supponiamo mille scritture e un milione di letture al giorno: è un sistema di letture, quindi ottimizzo lì. Genererei codici di 7 caratteri in base 62 da un contatore con blocchi pre-riservati per istanza, per evitare collisioni senza coordinare ogni richiesta. Salverei la mappatura in un database chiave-valore e metterei una cache davanti per il 20% di URL che si prende l'80% del traffico. Il reindirizzamento può essere eventualmente consistente: se un link ci mette un secondo a propagarsi, non è un problema; questo mi permette di replicare senza bloccare le scritture.»

4. 04

   Perché hai scelto [il tuo linguaggio/framework principale] nel tuo ultimo progetto e quando sarebbe stata una cattiva idea?

   Parla di criteri reali: ecosistema, prestazioni, il team che lo manterrà. Riconoscere quando NON era la scelta giusta vale più che difenderlo come se fosse perfetto per tutto.

   «Nel mio ultimo progetto ho scelto TypeScript con Node perché il team padroneggiava già JavaScript, il prodotto era un'API con molte integrazioni di terze parti e la tipizzazione ci risparmiava gli errori sciocchi nei contratti tra servizi. Non è stata una scelta di moda: ho valutato che assumere profili fosse facile e che l'ecosistema avesse librerie mature per ciò che ci serviva. Quando sarebbe stata una cattiva idea? Se il cuore fosse stato calcolo intensivo di CPU, elaborazione di immagini o qualcosa con requisiti stringenti di memoria: lì Node annaspa e sarei andato su Go o su Python con estensioni native. Di fatto un job di generazione di PDF abbiamo finito per spostarlo su un worker separato perché bloccava l'event loop.»

5. 05

   Devi aggiungere una feature a una parte del codice che non capisci e che nessuno ha documentato. Come procedi?

   Mostra una strategia davanti al codice ereditato: leggere i test, tracciare gli input e gli output, fare cambiamenti piccoli e verificabili. Menziona cosa ti rifiuteresti di toccare senza una rete di sicurezza.

   «Prima leggo i test, se ci sono: sono l'unica documentazione che non mente. Se non ci sono, traccio il flusso con un caso reale: metto dei log o un debugger all'ingresso e seguo i dati fino all'uscita, e con quello mi disegno una mappa di cosa tocca cosa. Prima di aggiungere la mia feature, scrivo due o tre test di caratterizzazione che fissino il comportamento attuale, anche se mi sembra strano: quel comportamento potrebbe essere un contratto che qualcuno si aspetta. Poi faccio il cambiamento più piccolo possibile e verifico che i test restino verdi. Quello che non farei è refactorizzare mentre aggiungo la feature, né toccare senza rete qualcosa che muove denaro o dati degli utenti: lì prima i test, poi i cambiamenti.»

6. 06

   Parlami di una volta in cui hai preso di proposito una scorciatoia tecnica (debito tecnico). Come l'hai giustificata?

   Metti in chiaro che è stata una decisione consapevole con un costo noto, non una svista. Spiega cosa ci hai guadagnato (una scadenza, validare un'ipotesi), come l'hai lasciata documentata e che piano c'era per ripagarla.

   «Per validare un'integrazione con un cliente grande, ho hardcodato la sua configurazione invece di costruire il sistema di configurazione per cliente che sarebbe servito. L'ho deciso con il mio responsabile davanti: montare la soluzione generica erano tre settimane e il cliente decideva in una. Ho lasciato la scorciatoia segnalata: un commento con il perché, un ticket nel backlog con la soluzione reale stimata, e un alert se un altro cliente arrivava a quel codice. Il cliente ha firmato, e nel trimestre successivo abbiamo ripagato il debito con il sistema generico. Per me la differenza tra debito buono e cattivo è questa: quello buono ha una data, un responsabile e un costo che qualcuno ha accettato ad alta voce; quello cattivo è quello che si scopre sei mesi dopo per sorpresa.»

7. 07

   Differenza tra due cose che sembrano simili nel tuo stack (p. es. lista vs dizionario, SQL vs NoSQL, sincrono vs asincrono): quando usi ciascuna?

   Rispondi con il quando, non con la definizione da manuale. Ancora ogni opzione a un caso d'uso e al costo che ti assumi (memoria, latenza, complessità). Se puoi, cita una volta in cui hai scelto male e l'hai cambiato.

   «SQL contro NoSQL, per esempio: non è una guerra di religione, è una domanda sui tuoi dati. Se hanno relazioni che contano (ordini, clienti, fatture) e ti servono transazioni, SQL, perché le garanzie te le dà il database e non le devi reinventare nel codice. NoSQL lo uso quando lo schema è volatile o il volume di letture semplici è enorme: sessioni, cataloghi denormalizzati, eventi. Il costo che ti assumi con NoSQL è che le domande che non avevi previsto diventano care. Mi è successo: abbiamo montato l'analitica su un database di documenti e dopo sei mesi ogni nuovo report era una sofferenza; abbiamo migrato quella parte su Postgres e le query sono passate da ore di lavoro a un JOIN.»

8. 08

   Il tuo codice passa in locale ma fallisce in produzione. Cosa controlli per primo?

   Elenca i sospettati per probabilità: variabili d'ambiente, versioni delle dipendenze, dati reali vs di test, concorrenza, fuso orario. L'importante è l'ordine del tuo ragionamento, non azzeccare la causa esatta.

   «Vado in ordine di probabilità. Primo, configurazione: variabili d'ambiente che mancano o puntano altrove, è la causa più comune e la più economica da controllare. Secondo, i dati: in locale provo con dati puliti e la produzione ha i casi strani (nulli, accenti, record del 2015). Terzo, le versioni: il lockfile è stato rispettato nel deploy?, la versione di Node o del database è la stessa? Quarto, tutto ciò che in locale non esiste: concorrenza reale, latenza di rete, permessi, fuso orario del server. E mentre controllo, guardo i log dell'errore reale in produzione invece di supporre: metà delle volte lo stack trace ti dice già in quale di queste quattro famiglie sei.»

Molte di queste domande sono del tipo «raccontami di una volta in cui…». Per strutturare quelle risposte con una storia chiara, usa il metodo STAR.

Consigli per distinguerti

• Pensa ad alta voce durante il coding. Il silenzio ti penalizza più di un errore: l'intervistatore ha bisogno di vedere il tuo ragionamento, non solo il risultato.
• Prima di scrivere codice, ripeti il problema e chiedi dei casi limite. Buttarti a digitare senza chiarire i requisiti è il campanello d'allarme numero uno.
• Quando difendi una decisione tecnica, nomina il trade-off che hai accettato. «Ho scelto X pur sapendo che Y» suona da senior; «X è meglio» suona da junior.
• Porta due o tre progetti pronti da raccontare in dettaglio: quale problema risolvevano, la tua decisione più difficile e cosa faresti diversamente. È il materiale da cui esce metà delle domande di approfondimento.

Domande per altri ruoli

• Colloquio per specialista di marketing
• Colloquio per impiegato/a amministrativo/a
• Colloquio per contabile