Un CV da sviluppatore viene letto due volte: prima da un recruiter che verifica stack, anzianità e nomi delle aziende, poi da un lead tecnico che cerca prove di impatto reale: latenza ridotta, incidenti evitati, costi di infrastruttura tagliati. L'esempio qui sotto è costruito per sopravvivere a entrambe le letture: ogni punto nomina una tecnologia precisa e un risultato misurato.
La trappola classica del CV da sviluppatore è l'elenco di responsabilità («sviluppo e manutenzione di API») che descrive tutti gli sviluppatori sul mercato. La struttura giusta: verbo, tecnologia, scala, risultato. «Migrazione da RabbitMQ a Kafka su una pipeline da 40 milioni di richieste al giorno, latenza p99 ridotta del 38%» dice in una riga quello che dieci righe di responsabilità non diranno mai.
Sul formato, resti su una colonna unica e sezioni standard: le piattaforme di recruiting tech analizzano il CV in automatico prima che un umano lo legga, e le impaginazioni a colonne o con icone perdono informazioni all'estrazione. Può verificare che cosa un software di selezione estrae dal suo CV con la nostra analisi ATS del curriculum.
Nomini le tecnologie nella loro forma letterale. I filtri cercano «Go», «Kafka», «Terraform», «PostgreSQL»: scriva i nomi esatti, raggruppati per famiglie (linguaggi, infrastruttura, pratiche), e tenga la lista onesta: ogni tecnologia elencata deve essere difendibile a colloquio. Un progetto open source con trazione reale (stelle, utenti, contributi) vale quanto un'esperienza: gli dedichi una voce con gli stessi punti quantificati.
Adatti il CV a ogni annuncio in dieci minuti. Riordini i gruppi di competenze perché lo stack richiesto arrivi per primo, ritocchi la prima frase del profilo e verifichi che i primi tre punti coprano ciò che l'annuncio elenca per primo. I recruiter tech italiani leggono senza difficoltà i titoli delle sezioni in inglese (backend, DevOps, data): mantenga i termini tecnici inglesi consolidati, nessuno ne cerca la traduzione.
Capisca chi legge il CV e in quale ordine. Passa per primo un recruiter o un sourcer, che confronta pattern: traiettoria dei titoli, sovrapposizione dello stack con l'annuncio, aziende riconoscibili o indicatori di scala. Legge per secondo il responsabile tecnico, e legge diversamente: cerca i verbi di responsabilità (possiede, ha guidato, ha progettato) contro i verbi di partecipazione (ha aiutato, ha contribuito, era coinvolto), le scelte di compromesso, e se i punti suonano come quelli di qualcuno che ha davvero portato la reperibilità. Scriva il terzo superiore della pagina per il recruiter e i punti per il responsabile, e le due letture andranno entrambe a suo favore.
L'ordine delle sezioni conta più che in altri mestieri. Con esperienza in produzione: intestazione con i link (GitHub, LinkedIn), profilo di tre frasi, esperienza, progetti solo se aggiungono segnale, competenze raggruppate, istruzione in fondo su due righe. Un neolaureato inverte la parte bassa: istruzione e progetti salgono sopra i lavori occasionali, perché una tesi solida o un contributo open source pesa più di un impiego estivo. Ciò che non funziona mai è il muro di tecnologie in cima alla pagina: spinge il lavoro reale sotto la prima schermata e chiunque abbia scritto codice lo legge come riempitivo. La sezione competenze è un menu di argomenti da colloquio che lei sta offrendo: l'esaminatore ordinerà da quel menu, quindi elenchi solo ciò che regge cinque minuti di domande.
Racconti l'esperienza come una storia di perimetro crescente. Titoli e date pesano più di quanto gli sviluppatori credano: una promozione interna vale più di due cambi laterali, quindi la renda visibile con voci separate sotto lo stesso datore di lavoro. Dia al ruolo attuale da tre a cinque punti e apra con una frase di perimetro (servizi posseduti, traffico gestito, dominio funzionale): chi legge ha bisogno del denominatore prima che i suoi risultati significhino qualcosa. Ogni punto successivo si guadagna la riga con un cambiamento che lei ha causato: un numero spostato, un sistema sostituito, una classe di incidenti eliminata, un team sbloccato. Le mansioni appartengono all'annuncio a cui risponde, non alla sua storia.
Conosca le convenzioni del CV italiano prima di applicarle al tech. La foto, ancora diffusa in altri settori, nel software non aggiunge nulla e i team internazionali preferiscono non riceverla; data di nascita e stato civile non sono richiesti. L'unica riga specificamente italiana che serve davvero è l'autorizzazione al trattamento dei dati personali ai sensi del GDPR (Regolamento UE 2016/679), che il nostro editor aggiunge in automatico per le candidature in Italia. Quanto al formato Europass: resta richiesto nei concorsi pubblici, nei bandi e in molte selezioni della pubblica amministrazione, dove va usato senza discutere; per software house, scale-up e team di prodotto è invece controproducente, perché diluisce i risultati in campi standard che nessun recruiter tech legge. Se punta a entrambi i mondi, tenga due versioni.
Eviti i cinque errori che costano più colloqui. I ricorrenti nei CV da sviluppatore: verbi vaghi («ha partecipato a», «coinvolto in») dove «ha progettato» o «ha guidato» sarebbero veri; framework elencati che il candidato non sa discutere; punti che descrivono il risultato del team senza dichiarare il proprio contributo; link a portfolio o GitHub morti, che fanno sembrare trascurato l'intero documento; e la seniority gonfiata nel titolo, che crolla alla prima domanda di architettura. Quasi tutti si correggono in minuti e costano colloqui se restano: rilegga il CV una volta con questa lista sotto gli occhi prima di inviarlo.
Gli assistenti di IA sono il tema del 2026, e va maneggiato con giudizio. Usare strumenti di coding assistito è ormai dato per scontato: elencarli tra le competenze non dice nulla. Ciò che vale un colloquio è la prova di giudizio ingegneristico attorno a quegli strumenti: un punto sugli standard di review introdotti per il codice assistito, sulla copertura di test mantenuta mentre la velocità di merge cresceva, su un tool interno che li ha resi più utili al team. Lo stesso vale per il CV in sé: i CV scritti interamente dall'IA convergono sugli stessi aggettivi e sullo stesso ritmo, e chi seleziona ha ormai orecchio. Scriva partendo dal suo lavoro reale e tagli ogni frase che non difenderebbe riga per riga.
Usi questa pagina in questo spirito: il CV qui sotto è un esempio completo e realistico, renderizzato dal nostro vero motore di template, non uno screenshot ritagliato. Il pulsante in alto lo apre nell'editor, così sostituisce la storia di Marco con la sua invece di partire dalla pagina bianca. Poi attinga dalla banca di frasi, confronti la lista di parole chiave con l'annuncio a cui punta e legga l'estratto ATS in fondo per vedere letteralmente che cosa un software di selezione ricava da questa impaginazione.
Domande frequenti
- Bisogna mettere il proprio GitHub su un CV da sviluppatore?
- Sì, se il profilo mostra qualcosa: un progetto con trazione, contributi regolari o codice rappresentativo del suo livello. Un link a un profilo vuoto danneggia più di quanto aiuti. Il criterio pratico: uno sconosciuto che passa novanta secondi sul profilo deve uscirne più convinto. Novanta secondi significano repository in evidenza curati (i 2-4 migliori, ciascuno con un README che dice cosa fa, come si esegue e un benchmark o uno screenshot), attività recente che mostra codice scritto fuori dalla stagione dei colloqui, e messaggi di commit che sembrano di un ingegnere, perché i revisori cliccano nella cronologia. Il grafico dei contributi conta molto meno di quanto i candidati temano: un singolo strumento ben mantenuto batte un muro verde di ritocchi di configurazione. Se il suo lavoro migliore vive in repository privati del datore di lavoro, lo dica nel profilo e metta in evidenza le approssimazioni pubbliche più vicine. Prima di candidarsi verifichi le basi: il link risolve, il nome del profilo corrisponde a quello del CV e i progetti in evidenza compilano davvero. Se ha un progetto open source significativo, gli dedichi una voce nel CV con punti quantificati (stelle, utenti, problema risolto): è spesso la riga di cui il lead tecnico parla per prima a colloquio.
- Un CV da sviluppatore deve stare in una pagina?
- Una pagina resta l'obiettivo fino a 8-10 anni di esperienza: i recruiter tech leggono in fretta e un CV denso di una pagina regge il confronto con due pagine diluite. Quando lo spazio manca, riduca gli incarichi vecchi a una riga, tenga 4-5 punti sul ruolo attuale e 3 sul precedente, e tagli le tecnologie che non vuole più praticare: ogni tecnologia elencata è un invito a interrogarla su di essa. Se riempie davvero due pagine di impatto distinto e quantificato (brevetti, pubblicazioni, open source di peso), prenda la seconda pagina, ma renda la prima autosufficiente: molti lettori non arrivano mai alla seconda. Ciò che non si guadagna mai lo spazio: una matrice di competenze con autovalutazioni a pallini, la riga «referenze disponibili su richiesta» e gli esami universitari una volta che ha spedito codice in produzione. E il corpo del carattere non è una strategia di lunghezza: scendere a nove punti per simulare una pagina sola si vede subito per quello che è. Tagli contenuto, invece: l'esercizio stesso migliora ciò che resta.
- Come si presenta una riconversione verso lo sviluppo software?
- Parta da ciò che è verificabile: formazione (università, bootcamp, autoformazione strutturata), progetti reali con codice consultabile e, se possibile, una prima esperienza anche breve (stage, apprendistato, freelance). Porti la sezione progetti sopra l'esperienza non tecnica e colleghi il vecchio mestiere al nuovo quando ha senso: un ex contabile che automatizza riconciliazioni in Python racconta una storia coerente. Il profilo deve annunciare la riconversione in una frase, non lasciarla indovinare. Sul piano dei numeri, tratti i progetti come esperienze: utenti reali anche pochi, richieste servite, tempi di risposta, copertura di test. «Applicazione usata ogni settimana da 15 colleghi del vecchio ufficio» è una metrica onesta e difendibile che vale più di qualunque attestato. Eviti infine l'errore più comune delle riconversioni: nascondere il vecchio mestiere. Dieci anni di responsabilità, scadenze e clienti sono un segnale di affidabilità che i neolaureati non possono offrire; compressi in tre righe quantificate, lavorano per lei.
- Meglio il CV in italiano o in inglese?
- Segua la lingua dell'annuncio. Un annuncio scritto in inglese, anche per una posizione in Italia, si aspetta di norma un CV in inglese; un annuncio in italiano si aspetta un CV in italiano con i termini tecnici consolidati lasciati in inglese. Se punta a entrambi i mercati, mantenga aggiornate le due versioni: il nostro editor permette di duplicare un CV e cambiarne la lingua senza ripartire da zero.
- Come si gestisce uno stack che non corrisponde all'annuncio?
- Parta dall'esperienza di architettura trasferibile: code, caching, progettazione di API, migrazioni di schema e osservabilità non dipendono dal linguaggio, e un hiring manager sa che chi ha fatto un cutover a zero interruzioni in Python sa rifarlo in Go. Sposti ogni esposizione reale allo stack richiesto (un progetto, una migrazione, un servizio toccato) nei primi tre punti, dove si vede alla prima passata, e nomini la sovrapposizione nel profilo: «backend, 6 anni di Python, oggi Go in produzione tramite una CLI open source». Dove annuncio e percorso usano parole diverse per la stessa cosa, le scriva entrambe una volta: il filtro non dedurrà che «message broker» copre «Kafka». La linea invalicabile: non elenchi mai una tecnologia su cui non reggerebbe un colloquio. Una lista gonfiata le procura un processo di selezione pensato per un altro profilo, e fallirlo chiude la porta anche per il futuro. E se i filtri automatici continuano a scartarla prima che un umano legga la pagina, li aggiri: segnalazioni interne e candidature dirette al responsabile permettono a una persona di pesare l'architettura trasferibile come nessun confronto letterale di stringhe farà mai.
- Come si parla degli strumenti di IA su un CV da sviluppatore nel 2026?
- Elencare «Copilot» o un assistente di coding tra le competenze equivale a elencare «Google»: l'uso è dato per scontato, la riga non aggiunge nulla e può leggersi come riempitivo. Ciò che distingue è la prova di giudizio attorno agli strumenti, espressa come risultato: standard di review definiti per il codice assistito, soglie di copertura test mantenute mentre la velocità di merge cresceva, uno strumento interno che ha reso gli assistenti più utili al team. Sono punti di leadership tecnica che semplicemente coinvolgono l'IA, e invecchiano bene. Due cautele: non lasci che un modello scriva il CV da solo, perché i CV generati convergono sugli stessi aggettivi e chi seleziona ha ormai sviluppato l'orecchio; e si prepari alla domanda su come usa gli assistenti giorno per giorno, diventata una verifica standard di profondità. Una risposta che mostra dove si fida e dove no vale più di qualunque riga sul CV. Se un annuncio cita esplicitamente lo sviluppo assistito dall'IA tra i requisiti, riprenda la formula una volta, dentro un punto con risultato, e lasci che sia il colloquio a portare la profondità.