Cosa cercano davvero le aziende tech nei developer (parla chi assume)

C'è una domanda che quasi ogni candidato ci fa prima o poi, in un modo o nell'altro: "Cosa state cercando esattamente?" Di solito arriva verso la fine del colloquio, con un tono che mescola curiosità genuina e speranza di ricevere una risposta che possa ancora cambiare le cose. È una domanda legittima. Il problema è che la risposta che le persone si aspettano — una lista di tecnologie, un numero di anni di esperienza, una certificazione — non è la risposta vera.

La risposta vera è più difficile da mettere su un job posting, e per questo non ci finisce mai. Ma dopo centinaia di colloqui e anni a costruire un team che funziona, possiamo articolarla con una certa precisione. Questo articolo è il nostro tentativo di farlo — non per aiutarti a "passare il colloquio", ma per aiutarti a capire se il tipo di lavoro che facciamo in una software house è quello che stai cercando davvero.

Il problema con i job posting

Prima di parlare di cosa cerchiamo, vale la pena nominare il problema con i job posting in generale: sono quasi sempre scritti male, e non per cattiveria ma per necessità. Chi scrive un annuncio di lavoro deve sintetizzare un profilo complesso in qualcosa di leggibile, filtrabile, pubblicabile su LinkedIn. Il risultato è una lista di requisiti tecnici che rappresenta forse il 20% di quello che conta davvero.

"5+ anni di esperienza con React" non ti dice nulla sulla qualità del codice che quella persona scrive. "Ottime capacità comunicative" è una frase così abusata da aver perso ogni significato. E "passione per la tecnologia" è diventata una formula retorica che chiunque può scrivere senza che nessuno possa verificarla.

Noi continuiamo a pubblicare job posting perché è il meccanismo standard, ma sappiamo che il vero processo di selezione comincia quando quelle parole spariscono e inizia una conversazione reale. Ed è in quella conversazione che emergono le cose che contano.

La prima cosa: capire prima di fare

Il pattern che separa quasi invariabilmente i developer che crescono da quelli che si bloccano è la loro relazione con la comprensione. I developer che ci entusiasmano di più nei colloqui sono quelli che, di fronte a un problema, fanno domande prima di proporre soluzioni. Non domande per sembrare interessati — domande genuine, che rivelano che stanno cercando di capire il contesto reale del problema, non solo la sua formulazione superficiale.

Questo sembra ovvio, ma è sorprendentemente raro. La maggior parte dei candidati, quando gli viene presentato un problema tecnico, si precipita verso una soluzione. È comprensibile — il colloquio crea pressione, e produrre una risposta sembra dimostrare competenza. Ma quasi sempre la soluzione proposta è una risposta alla versione semplificata del problema, non al problema reale. E la differenza tra le due, nel lavoro quotidiano, è enorme.

Un developer che capisce prima di fare produce meno codice ma codice migliore. Fa meno refactoring perché ha capito i requisiti prima di scrivere la prima riga. Sorprende meno i clienti con soluzioni che tecnicamente funzionano ma non risolvono il problema che avevano in mente. Questa capacità — che alcuni chiamano "problem framing", altri semplicemente buon senso tecnico — è una delle cose più difficili da insegnare e più preziose da trovare.

La seconda cosa: ownership reale, non performativa

"Ownership" è una delle parole più inflazionate del vocabolario tech. Tutti dicono di averla, pochissimi la dimostrano quando costa qualcosa. Nella nostra esperienza, l'ownership reale si vede in un momento specifico: quando le cose vanno storte.

Un developer con ownership reale, quando un bug arriva in produzione o una feature non funziona come previsto, non cerca prima di tutto di stabilire chi è colpa di chi. Cerca di capire cosa è successo, di sistemarlo, e poi — solo poi — di capire come evitare che succeda di nuovo. Non perché sia un santo, ma perché ha interiorizzato che il prodotto è suo quanto di chiunque altro nel team.

Questo si vede anche nei colloqui, in modo indiretto. Quando chiediamo ai candidati di raccontarci un progetto su cui hanno lavorato, prestiamo molta attenzione a come parlano delle cose che non sono andate bene. Chi dice "il cliente ha cambiato i requisiti all'ultimo minuto" o "il backend non era pronto" sta descrivendo una situazione esterna. Chi dice "abbiamo sottovalutato la complessità dell'integrazione e avremmo dovuto fare una discovery più approfondita" sta dimostrando qualcosa di molto più interessante.

La terza cosa: la comunicazione come competenza tecnica

In una software house che lavora con clienti reali su progetti complessi, la comunicazione non è una soft skill accessoria — è parte integrante del lavoro tecnico. Un developer che scrive codice eccellente ma non riesce a spiegare perché ha fatto certe scelte architetturali, o che non sa come gestire una conversazione difficile con un cliente, è un developer con un limite reale che prima o poi diventa un problema per il team.

Quello che cerchiamo non è la capacità di fare belle presentazioni o di usare il linguaggio del business. È qualcosa di più specifico: la capacità di tradurre. Di prendere un concetto tecnico complesso e renderlo accessibile a qualcuno che non ha il tuo background. Di ascoltare un requisito espresso in linguaggio di business e tradurlo in implicazioni tecniche concrete. Di spiegare un trade-off in modo che chi non è tecnico possa prendere una decisione informata.

Questa capacità si sviluppa con l'esperienza, ma si vede già nei colloqui. I candidati che la hanno tendono a spiegare le cose con esempi concreti, a verificare che l'interlocutore abbia capito, a modulare il livello di dettaglio in base a chi hanno davanti. Quelli che non la hanno tendono a rifugiarsi nel gergo tecnico quando si sentono sotto pressione, o a semplificare eccessivamente quando parlano con non tecnici.

Quello che non cerchiamo (e perché è importante dirlo)

Non cerchiamo il "10x developer" — il mito del genio solitario che risolve tutto da solo. Nella nostra esperienza, le persone che si presentano con questa identità tendono a creare dipendenze, a non documentare, a fare scelte tecniche che solo loro capiscono. Sono individualmente brillanti e collettivamente costose.

Non cerchiamo qualcuno che sappia tutto. Preferiamo un developer che sa esattamente cosa non sa, che è onesto sui propri limiti, e che ha un approccio strutturato all'apprendimento. L'umiltà intellettuale non è una virtù morale — è una competenza professionale. Un developer che pensa di sapere già tutto smette di imparare, e nel tech smettere di imparare è smettere di essere utile.

Non cerchiamo nemmeno qualcuno che sia d'accordo con tutto. I team migliori sono quelli dove le persone si sfidano reciprocamente — dove qualcuno dice "aspetta, sei sicuro che sia la scelta giusta?" e quella domanda migliora il risultato finale. Cerchiamo persone che sappiano dissentire in modo costruttivo: con argomenti, non con posizioni; con curiosità, non con difensività.

La risposta alla domanda originale

Allora, cosa cerchiamo davvero? Cerchiamo developer che abbiano fatto pace con il fatto che il lavoro tecnico è fondamentalmente un lavoro di collaborazione e di giudizio, non solo di esecuzione. Che capiscano i problemi prima di risolverli. Che si sentano responsabili dei risultati, non solo del codice. Che sappiano comunicare con chiunque abbiano davanti. Che siano onesti su quello che sanno e su quello che non sanno.

Le tecnologie che conosci contano — non mentiamo su questo. Ma contano come punto di partenza, non come punto di arrivo. La cosa che ci dà più fiducia in un candidato non è il numero di framework che ha nel CV, ma il modo in cui parla del proprio lavoro quando smette di recitare e comincia a conversare.

Se ti riconosci in quello che hai letto, dai un'occhiata a come lavoriamo. Siamo sempre aperti a parlare con developer che prendono il proprio mestiere sul serio.