Come funziona il colloquio tecnico in una software house (vista da chi assume)
Cosa succede davvero in un colloquio tecnico? Un CTO di software house spiega il processo, cosa valuta, gli errori più comuni e come prepararsi al meglio.
Team Lasting Dynamics
Team Editoriale di Lasting Dynamics
Come funziona il colloquio tecnico in una software house (vista da chi assume)
C'era un candidato, qualche anno fa, che durante il live coding si è fermato a metà esercizio. Ha posato le mani sulla tastiera, ha guardato lo schermo per qualche secondo, poi ha detto: "Aspetta — sto risolvendo il problema sbagliato. Fammi ricominciare." Ha rifatto tutto da capo, in modo più pulito, e ha finito in anticipo. Era la prima volta in anni che vedevo qualcuno riconoscere un errore di impostazione invece di continuare a scavare nella direzione sbagliata. L'abbiamo assunto. Non perché avesse scritto il codice perfetto — ma perché aveva dimostrato esattamente il tipo di pensiero che volevamo nel team.
Questo articolo nasce da quella storia, e da centinaia di colloqui condotti nel corso degli anni. Non è una guida generica su come "fare bella impressione" o "vestirsi in modo professionale". È quello che penso davvero mentre siedo dall'altra parte del tavolo — o dello schermo — e valuto se una persona entrerà a far parte del nostro team.
Cosa stiamo cercando davvero (e non è quello che pensi)
Il problema con la maggior parte dei consigli sui colloqui tecnici è che vengono scritti da chi non ha mai assunto nessuno. Sono pieni di suggerimenti tattici — come rispondere a domande comportamentali, come ottimizzare il CV, come simulare entusiasmo — che mancano completamente il punto. Quando un hiring manager tecnico valuta un candidato, non sta compilando una checklist di competenze. Sta cercando di rispondere a una domanda molto più semplice: questa persona risolverebbe i problemi reali che affrontiamo ogni giorno?
In una software house come la nostra, i problemi reali non sono algoritmi di ordinamento su array di milioni di elementi. Sono: un'integrazione con un'API di terze parti che si comporta in modo imprevedibile, un bug che si manifesta solo in produzione con dati reali, una scelta architetturale che oggi sembra sensata ma tra due anni potrebbe diventare un debito tecnico difficile da gestire. Cerchiamo developer che sappiano ragionare su questi problemi — non developer che abbiano memorizzato le soluzioni a problemi che non incontreranno mai.
Questo non significa che le competenze tecniche non contino. Contano moltissimo. Ma sono la condizione necessaria, non sufficiente. La condizione sufficiente è la capacità di applicare quelle competenze in contesti ambigui, sotto pressione, in collaborazione con altre persone. E questa capacità si vede durante un colloquio, se il colloquio è costruito nel modo giusto.
Il processo in tre fasi: cosa succede davvero
Il nostro processo di selezione si articola in tre momenti distinti, ognuno dei quali valuta qualcosa di specifico. Conoscere la struttura in anticipo non toglie valore alla valutazione — anzi, ci permette di confrontare candidati sullo stesso piano.
La prima fase è una call conoscitiva di 30-45 minuti. Non è un colloquio tecnico — è una conversazione. Voglio capire il percorso del candidato, le scelte che ha fatto, cosa lo ha portato a candidarsi da noi. Voglio sentire come parla del proprio lavoro: con entusiasmo genuino o con distacco professionale? Con consapevolezza dei propri limiti o con la tendenza a sopravvalutarsi? Questa call mi dice già molto — non su cosa sa fare il candidato, ma su come pensa e come comunica.
La seconda fase è il colloquio tecnico vero e proprio, che dura 60-90 minuti. È diviso in due parti: una discussione sul progetto più significativo del candidato, e una sessione di live coding su un problema realistico. Entrambe le parti vengono condotte da me o da un senior developer del team — mai da un recruiter HR che non scrive codice.
La terza fase, per i candidati che superano le prime due, è un incontro con il team più ampio. Non è un ulteriore filtro tecnico — è un'opportunità per entrambe le parti di capire se c'è compatibilità culturale e di lavoro. I candidati possono fare domande al team, capire come funzioniamo davvero, e decidere se questo è il posto giusto per loro.
La discussione sul progetto: dove si vince o si perde
La parte del colloquio che più candidati sottovalutano è la discussione sul progetto. Chiedo di scegliere il progetto più significativo su cui hanno lavorato — non necessariamente il più impressionante tecnicamente, ma quello che ha insegnato di più — e di raccontarmelo come se stessi spiegando a un collega cosa avete costruito, perché, e cosa avete imparato.
Le risposte mediocri descrivono il progetto. Le risposte eccellenti ragionano sul progetto. C'è una differenza enorme tra "abbiamo usato React per il frontend e Node per il backend con un database PostgreSQL" e "abbiamo scelto PostgreSQL perché avevamo bisogno di transazioni ACID e il volume dei dati era abbastanza contenuto da non richiedere una soluzione distribuita — se il volume fosse cresciuto avrei rivalutato quella scelta." La prima risposta mi dice che il candidato sa usare degli strumenti. La seconda mi dice che capisce perché li usa.
Le domande che pongo in questa sezione sono progettate per capire quanto in profondità il candidato abbia pensato alle scelte che ha fatto. "Cosa avresti fatto diversamente?" è la domanda più rivelatrice. I candidati che non riescono a identificare nulla che avrebbero cambiato non stanno dicendo che il loro lavoro era perfetto — stanno dicendo che non ci hanno riflettuto abbastanza. I candidati che identificano tre o quattro cose specifiche che avrebbero fatto diversamente, con una spiegazione chiara del perché, mi stanno mostrando la qualità di pensiero che voglio nel team.
Il live coding: collaborazione, non performance
Il live coding è la parte del colloquio che genera più ansia nei candidati, e capisco perché. L'idea di scrivere codice mentre qualcuno guarda è intrinsecamente stressante. Ma il nostro live coding non è progettato per essere uno stress test — è progettato per simulare il modo in cui lavoriamo davvero.
Il problema che assegno è sempre realistico: qualcosa che assomiglia a un task reale che potrebbe capitare in un progetto vero. Non algoritmi di ordinamento, non problemi di teoria dei grafi, non rompicapi matematici. Tipicamente: parsare e trasformare dei dati, scrivere una funzione che gestisca casi edge in modo robusto, refactoring di un pezzo di codice che funziona ma è difficile da mantenere.
Durante il live coding, intervengo. Faccio domande. Suggerisco direzioni alternative. Questo non è un tentativo di distrarre il candidato — è una simulazione di come funziona la collaborazione in un team reale. Un developer che lavora in isolamento totale e produce codice perfetto in silenzio è meno utile di un developer che pensa ad alta voce, accetta input, e integra feedback in tempo reale. Il candidato che si ferma, come quello che ho descritto all'inizio, e dice "aspetta, sto risolvendo il problema sbagliato" — quello è il tipo di pensiero che voglio.
Le domande di architettura: senior vs junior
Per i candidati senior, aggiungo una sezione di domande architetturali. Non sono domande con una risposta corretta — sono domande progettate per capire come il candidato ragiona di fronte a trade-off reali.
"Come progetteresti un sistema di notifiche che deve gestire milioni di utenti?" Non mi aspetto un'architettura perfetta. Mi aspetto che il candidato faccia le domande giuste prima di rispondere: quante notifiche al secondo? Quali canali (email, push, SMS)? Qual è il requisito di latenza? Quanto è critica la consegna garantita? Un candidato che risponde immediatamente con "userei Kafka e un sistema di microservizi" senza fare nessuna di queste domande mi preoccupa — non perché la risposta sia sbagliata, ma perché il processo che l'ha prodotta lo è.
Il segnale più forte che posso ricevere in questa parte del colloquio è quando un candidato dice "dipende" — e poi spiega da cosa dipende. Non è un modo per evitare la risposta: è la risposta corretta. L'ingegneria del software è fatta di trade-off, e i developer che non lo hanno ancora capito tendono a prendere decisioni rigide che creano problemi a lungo termine.
Le red flag che fanno terminare un colloquio anticipatamente
Ci sono comportamenti che, quando li vedo, capisco quasi subito che il candidato non è quello giusto per il nostro team. Non li elenco per essere crudele — li elenco perché molti di questi comportamenti sono correggibili facilmente, e spesso il candidato non sa nemmeno di averli.
La prima red flag è l'incapacità di ammettere di non sapere qualcosa. Quando chiedo di un argomento che il candidato non conosce bene, la risposta peggiore è inventare una risposta plausibile sperando che non me ne accorga. Me ne accorgo sempre — e questo mi dice qualcosa di importante su come quella persona si comporterà quando si troverà bloccata su un problema in produzione. La risposta giusta è: "Non ho esperienza diretta con questo, ma ragionando per principi mi aspetterei che..." oppure semplicemente "Non lo so, ma è qualcosa che mi piacerebbe approfondire." L'onestà intellettuale vale molto più della competenza fingita.
La seconda red flag è parlare male del lavoro precedente o dei colleghi. Capisco che ci siano esperienze lavorative difficili — le ho avute anch'io. Ma un candidato che dedica parte del colloquio a spiegare quanto fosse incompetente il suo ex team, o quanto fosse tossica la sua ex azienda, mi fa chiedere cosa dirà di noi tra due anni. Non sto cercando qualcuno che abbia avuto solo esperienze positive — sto cercando qualcuno che sappia parlare delle esperienze difficili con maturità e senza rancore.
La terza red flag è la rigidità tecnologica. Il candidato che è "un developer React" e non è interessato a nient'altro, o che pensa che il proprio stack sia l'unico stack sensato, è difficile da inserire in un team che lavora su progetti diversi con esigenze diverse. Non chiediamo a nessuno di essere tuttofare — ma chiediamo apertura mentale verso tecnologie e approcci diversi da quelli che si conoscono già.
Le green flag che fanno accelerare una candidatura
Simmetricamente, ci sono segnali che fanno pensare "questo è esattamente il tipo di persona che vogliamo nel team" anche quando la preparazione tecnica non è perfetta.
La più importante è la curiosità genuina. Non la curiosità performativa — non il candidato che ha memorizzato la nostra homepage e cita i nostri valori aziendali durante il colloquio. La curiosità reale: fare domande sul problema che stiamo cercando di risolvere, voler capire come funziona il team prima ancora di sapere quanto si guadagna, mostrare interesse per le sfide tecniche specifiche che affrontiamo. Questa curiosità è quasi impossibile da insegnare, e quando la vedo so che ho davanti qualcuno che continuerà a crescere nel tempo.
Un altro segnale molto positivo è la capacità di contestualizzare le proprie scelte tecniche. Non "ho usato PostgreSQL" ma "ho usato PostgreSQL perché avevo bisogno di transazioni ACID e il volume dei dati era abbastanza contenuto da non richiedere una soluzione distribuita — se il volume fosse cresciuto avrei rivalutato." La differenza tra queste due risposte non è di competenza — è di consapevolezza. E la consapevolezza è quello che distingue un developer che esegue da un developer che progetta.
Il terzo segnale positivo è la capacità di ricevere feedback durante il colloquio stesso. Quando suggerisco un approccio alternativo durante il live coding, come reagisce il candidato? Si irrigidisce e difende la propria soluzione? O considera l'alternativa con genuina apertura, anche se alla fine decide di continuare con il proprio approccio? La capacità di integrare feedback in tempo reale è direttamente correlata alla capacità di crescere in un team.
Come prepararsi concretamente
La preparazione migliore per un colloquio tecnico in una software house non è studiare algoritmi. È riflettere profondamente sul proprio lavoro passato.
Prima del colloquio, identifica due o tre progetti su cui hai lavorato negli ultimi anni e analizzali in profondità: quali scelte tecniche hai fatto e perché? Cosa avresti fatto diversamente con il senno di poi? Quali problemi inaspettati hai incontrato e come li hai risolti? Questa riflessione non è solo utile per il colloquio — è utile per la tua crescita professionale in generale.
Per la parte di live coding, l'unica preparazione che conta è scrivere codice regolarmente in un ambiente simile a quello del colloquio. Non memorizzare soluzioni a problemi standard — allenati a pensare ad alta voce mentre scrivi codice, a spiegare le tue scelte in tempo reale, a gestire i casi edge in modo sistematico. Usa un editor semplice, senza autocomplete aggressivo, così da non dipendere dagli strumenti durante il colloquio.
Prepara anche domande per noi. I candidati che non hanno domande mi preoccupano quasi quanto quelli che non sanno rispondere alle mie. Le domande che fai dicono tanto quanto le risposte che dai — e un candidato che vuole capire come funziona davvero il team, quali sono le sfide tecniche più interessanti, come vengono prese le decisioni architetturali, è già un candidato interessante prima ancora di aver scritto una riga di codice.
Cosa succede dopo il colloquio
Cerchiamo di dare feedback entro 48-72 ore dalla fine del processo. Non feedback generici — feedback specifici su cosa ha funzionato e cosa no, in modo che il candidato possa trarne qualcosa di utile indipendentemente dall'esito.
Se la risposta è positiva, il passo successivo è una call per discutere l'offerta e rispondere a qualsiasi domanda rimasta aperta. Se il candidato viene da fuori Las Palmas, organizziamo anche una visita in sede prima della firma — vogliamo che la decisione sia presa con piena consapevolezza di cosa significa lavorare qui, non solo di cosa dice il contratto.
Se la risposta è negativa, la porta non si chiude definitivamente. Abbiamo assunto persone al secondo tentativo, dopo che avevano lavorato su specifiche aree di crescita che avevamo identificato insieme. Un "no" da parte nostra è quasi sempre un "non ancora" — e lo diciamo esplicitamente.
FAQ
Devo sapere un linguaggio specifico per candidarmi? No. Valutiamo il ragionamento, non la sintassi. Puoi usare il linguaggio con cui sei più a tuo agio durante il live coding — quello che conta è come pensi, non quale keyword usi.
Il colloquio tecnico è asincrono o in tempo reale? In tempo reale, via video call. Non utilizziamo test asincroni o piattaforme di coding automatizzate — vogliamo una conversazione, non un esame.
Posso candidarmi anche se non ho un portfolio su GitHub? Sì. Il portfolio aiuta, ma non è un requisito. L'importante è che tu possa parlare in modo approfondito del lavoro che hai fatto, anche se il codice non è pubblicamente accessibile.
Come mi preparo se vengo da un bootcamp e ho poca esperienza professionale? Sii onesto sulla tua esperienza. Quello che valutiamo nei profili junior è il potenziale di crescita, non l'esperienza accumulata. Mostraci come pensi, come impari, come affronti i problemi che non sai risolvere — è più utile di qualsiasi progetto da bootcamp ottimizzato per impressionare.
Quanto dura l'intero processo di selezione dall'inizio alla fine? Tipicamente 2-3 settimane dalla prima call alla decisione finale. Cerchiamo di essere veloci perché sappiamo che i candidati validi hanno spesso più opzioni in parallelo.
Posso candidarmi dall'estero? Sì — e anzi, molti dei nostri developer si sono trasferiti a Las Palmas da altri paesi europei. Supportiamo attivamente il processo di relocation. Se sei curioso di sapere cosa significa trasferirsi qui, leggi la nostra guida su vivere a Las Palmas da developer.
Se stai leggendo questo articolo perché stai pensando di candidarti, hai già un vantaggio: sai esattamente cosa aspettarti. Il resto dipende da te.
Team Lasting Dynamics
Team Editoriale di Lasting Dynamics
Il team di Lasting Dynamics scrive da Las Palmas de Gran Canaria, dove l'azienda ha sede.
