Come scrivere un CV per un lavoro tech (ingegneri software, sviluppatori, data)

Il CV tech si legge diversamente — cosa cambia

Prima delle tattiche, la differenza strutturale. I CV tech vengono valutati attraverso una lente diversa rispetto ai CV aziendali, e la differenza modella ogni sezione:

• L'hiring manager di ingegneria legge il CV insieme (o dopo) a una scansione rapida del tuo GitHub, del tuo sito personale se ne hai uno e del tuo LinkedIn. Il CV non è l'unico segnale; è un segnale in una valutazione multi-sorgente
• La sezione competenze tecniche viene letta per prima sia dai recruiter che dagli ingegneri, ma cercano cose diverse. I recruiter scansionano per corrispondenze di parole chiave contro il JD; gli ingegneri scansionano se profondità e ampiezza corrispondono alla seniority del ruolo
• I progetti spesso contano più della storia lavorativa ai livelli junior e mid. Un progetto auto-guidato che ha consegnato qualcosa di reale segnala iniziativa ed esecuzione in un modo che uno stage o primo lavoro non possono
• La storia lavorativa viene letta per scope, impatto e seniority del contesto — non solo per nomi di azienda. Lavorare nel team di auth in una startup di 50 persone è diverso da lavorare nel team di auth in un'azienda di 50.000 persone; il CV deve rendere lo scope leggibile
• La presenza GitHub viene controllata. Un candidato con un profilo GitHub attivo (commit reali, repository multipli, grafico di contribuzioni che mostra attività recente) viene trattato come ingegnere più credibile di uno senza — anche se l'abilità sottostante è identica
• Il CV è di una pagina finché non può esserlo. Due pagine sono accettabili per ingegneri con 8+ anni di esperienza, ma la seconda pagina deve contenere sostanza reale, non riempitivo
• L'educazione conta a livello junior (specialmente per i neolaureati), diventa meno importante a livello mid e diventa quasi irrilevante a livello senior+. Aggiusta la prominenza di conseguenza
• Le certificazioni contano per ruoli cloud specifici (AWS, GCP, Azure) e specialità specifiche (sicurezza, networking) ma sono in gran parte irrilevanti per ruoli generali di ingegneria del software

Il resto di questa guida è costruito attorno a questi fatti strutturali. Ogni sezione affronta cosa scrivere, come organizzarlo, cosa enfatizzare e cosa tagliare — calibrato specificamente per ruoli di ingegneria piuttosto che per ruoli aziendali generici.

La sezione competenze tecniche — come organizzarla

La sezione competenze tecniche è la sezione più scansionata su un CV tech. Sia i recruiter che gli ingegneri la guardano per primi. Come è organizzata determina se trasmette competenza o rumore:

• Organizza per categoria, non come singola lista piatta. Linguaggi, framework, database, infrastruttura/cloud, strumenti, metodologie — ciascuno come il proprio gruppo. Un muro di 40 tecnologie separate da virgole si legge come uno scarico di buzzword; le stesse 40 organizzate per categoria si leggono come una mappa strutturata di competenze
• Elenca tecnologie che puoi discutere con sicurezza in un'intervista tecnica. L'intervistatore sceglierà da questa sezione per progettare domande tecniche; se elenchi Rust perché lo hai usato per un tutorial tre anni fa, fallirai l'intervista
• Ordina ogni categoria per proficienza genuina, non per ciò che desideri fosse vero. Se sei più forte in Python e più debole in Go, metti Python per primo — l'ordine viene letto come segnale di fiducia
• Evita etichette di livello di competenza (Principiante / Intermedio / Esperto / 8 su 10). Sono soggettive, spesso inaccurate e creano domande imbarazzanti in interviste. O elenchi una tecnologia perché puoi discuterla con sicurezza, o lasciala fuori
• Abbina il vocabolario tecnico nella descrizione del lavoro. Se il JD dice 'React, Node.js, PostgreSQL, AWS', usa quei termini esatti — non 'framework JavaScript, server web, database relazionali, piattaforme cloud'. L'ATS keyword matching è letterale
• Elenca versioni o dialetti specifici quando rilevante: 'Python 3.x', 'PostgreSQL 14+', 'React 18 con hooks'. La specificità segnala profondità
• Salta le basi che si presume tutti abbiano. Elencare 'HTML, CSS, Git, riga di comando' su un CV di senior engineer è riempitivo che spinge fuori il segnale reale
• Se hai expertise specializzato (compilatori, sistemi distribuiti, infrastruttura ML, sistemi real-time), crea una riga separata 'specialità' o 'domini' che lo fa emergere. La specializzazione è più preziosa dell'ampiezza a livello senior

Il test per la sezione competenze tecniche: un ingegnere che la legge dovrebbe poter prevedere come è stato effettivamente il tuo lavoro quotidiano. Se la sezione è una nuvola di parole generica che potrebbe corrispondere a qualsiasi candidato, sta fallendo. Se è organizzata, calibrata e onesta, fa la maggior parte del lavoro dello screen tecnico prima che lo screen tecnico avvenga.

Mostrare progetti — quando i progetti contano più dei lavori

I CV tech spesso includono una sezione Progetti oltre all'Esperienza Lavorativa. Per alcuni candidati la sezione Progetti è la parte più forte del CV. Quando includerne una e come usarla:

• Ingegneri junior e neolaureati: la sezione Progetti è essenziale. Con storia lavorativa limitata, i progetti sono la prova primaria che puoi consegnare codice. Posiziona questa sezione sopra o subito dopo l'Educazione
• Cambi di carriera entrando in ingegneria: la sezione Progetti è essenziale. È il ponte tra la tua esperienza precedente e la tua capacità di ingegneria — e l'unica prova che hai effettivamente costruito qualcosa
• Ingegneri mid-level con storia lavorativa forte: la sezione Progetti è opzionale. Includila se hai progetti collaterali che dimostrano competenze che la tua storia lavorativa non dimostra (open source, esperimenti ML collaterali, una libreria pubblicata, un'estensione Chrome popolare)
• Ingegneri senior e sopra: la sezione Progetti è di solito non necessaria. La storia lavorativa a questo livello dovrebbe portare il peso. Eccezione: maintenance notevole di open source, lavoro pubblicato ben noto o contributi comunitari significativi
• Ogni voce di progetto dovrebbe avere: nome del progetto (con link al repo o URL live), descrizione di una riga di cosa fa, lo stack tech usato e 1-2 bullet point su cosa è stato non-banale nel costruirlo
• Preferisci 2-4 progetti forti rispetto a 8 deboli. Un'app todo seguendo un tutorial non aiuta; un progetto che ha risolto un problema reale e di cui puoi discutere in profondità, sì
• Se il progetto è un clone o un follow-along di tutorial, non elencarlo come progetto. Elencalo come 'esercizio di apprendimento' se mai, o ometti
• I link live contano più dei link al repo per progetti orientati all'utente. Un sito deployato su cui l'hiring manager può cliccare è drammaticamente più convincente di un repo che deve clonare
• Se il progetto ha avuto collaboratori, nominali e il tuo ruolo specifico. 'Costruito API backend e layer database per progetto di team da 4 persone' è onesto e specifico; rivendicare l'autorship singolo di un progetto di team è il tipo di cosa che viene presa nell'intervista

Il CV tech più forte a livello junior/mid spesso ha 2-3 progetti sostanziali di cui il candidato può parlare in profondità, con demo live. Questo spesso supera una storia lavorativa più lunga ma meno differenziata. Costruisci i progetti deliberatamente per essere la prova più forte del tuo CV.

GitHub, portfolio e lavoro dimostrabile

I link che includi nel tuo CV tech vengono letti come prova che sei un ingegnere praticante piuttosto che un possessore di credenziali. Quali link includere e come presentarli:

• GitHub: includi per quasi tutti i ruoli di ingegneria. Assicurati che il profilo a cui linki sia reale (commit recenti, repo multipli, readme di profilo popolato). Un GitHub vuoto o stagnante linkato sul tuo CV è peggio di nessun link
• Sito personale: includi se ne hai uno ed è aggiornato. Il sito non deve essere fancy; un portfolio semplice con link a progetti, una bio breve e informazioni di contatto è sufficiente. Un sito rotto o dell'era 2019 è peggio di nessun sito
• LinkedIn: includi. Anche se pensi che LinkedIn sia per lo più rumore, i recruiter lo controllano e un profilo vuoto segnala mancanza di professionalità
• Profilo Stack Overflow: includi solo se hai reputazione significativa e risposte di alta qualità. Un profilo da 50 reputazione non segnala nulla; un profilo da 50.000 reputazione segnala expertise reale
• Blog personale o scrittura tecnica: includi se scrivi contenuto tecnico regolarmente. I post di blog di ingegneria dimostrano capacità di comunicazione, profondità tecnica e abitudine di riflessione — tutti segnali che gli hiring manager valutano
• Talk di conferenze, podcast, apparizioni video: includi se ne hai. Funzionano come validazione di terze parti che puoi comunicare idee tecniche
• Rendi tutti i link cliccabili nel PDF (Word e Google Docs entrambi supportano questo quando 'Inserisci hyperlink'). I recruiter cliccheranno; link rotti o non-cliccabili ti costano il click-through
• Cura prima di linkare. Prima di aggiungere il tuo link GitHub, guarda il tuo profilo con occhi freschi. Pinna i tuoi migliori 4-6 repo al profilo. Assicurati che i README dei repo siano scritti. Elimina o archivia repository che esistono solo come tutorial a metà terminati. L'hiring manager formerà un'impressione in 30 secondi di guardare il tuo profilo — assicurati che sia l'impressione che vuoi

Ogni link sul tuo CV tech è una promessa — cliccarci rivelerà più prove della tua capacità di ingegneria. Se cliccare rivela meno di quanto il CV ha suggerito, la candidatura si indebolisce. I link sono netto-positivi solo se il materiale sottostante è all'altezza di ciò che il CV implica.

ATS per ruoli tech — il keyword matching che conta

La maggior parte delle assunzioni tech in grandi aziende ancora passa attraverso sistemi ATS che filtrano sulle parole chiave. Le dinamiche del matching ATS per i ruoli di ingegneria:

• ATS per ruoli tech spesso esegue matching letterale di parole chiave contro il JD. Se il JD dice 'React' e il tuo CV dice 'React.js', alcuni sistemi non corrisponderanno. Usa l'ortografia esatta dal JD dove possibile
• Elenca tecnologie in più sezioni, non solo nella sezione Competenze. Un ingegnere senior che ha usato Kubernetes in produzione in tre aziende diverse dovrebbe avere 'Kubernetes' che appare in quelle tre descrizioni di lavoro più la sezione Competenze — l'algoritmo di matching pondera le occorrenze
• Framework e strumenti specifici contano più delle categorie generali. 'React, Vue, Angular' è meglio di 'framework JavaScript'. 'PostgreSQL, MongoDB, Redis' è meglio di 'database'
• Acronimi e forme complete: includi entrambi. 'Machine Learning (ML)' copre sia le query 'ML' che 'machine learning'. 'Continuous Integration (CI/CD)' fa lo stesso
• Variazioni comuni: 'Node.js' e 'Nodejs' e 'Node' sono tutte la stessa tecnologia ma i sistemi ATS potrebbero non saperlo. Se il JD dice 'Node.js', abbina quella forma esatta
• Certificazioni e framework specifici per industria: includi se rilevanti. 'PCI DSS', 'HIPAA', 'SOC 2', 'GDPR' se hai lavorato con loro. 'Agile', 'Scrum', 'Kanban' se hai eseguito questi processi
• Evita il keyword-stuffing che rompe la leggibilità. Il CV viene letto da umani dopo aver passato l'ATS; se il lettore umano vede un muro di nomi di tecnologia senza contesto, la candidatura fallisce allo screening umano anche se ha passato lo screening ATS
• Adatta per candidatura. La lista di parole chiave che passa un CV attraverso l'ATS di Google è diversa dalla lista di parole chiave che lo passa attraverso il Greenhouse di una startup. Abbina il JD specifico

Il matching ATS è un primo ostacolo necessario per i ruoli tech nella maggior parte delle grandi aziende. Trattalo come un esercizio letterale di matching: abbina il vocabolario del JD, elenca le tecnologie nel contesto (nelle descrizioni di lavoro, non solo nella lista Competenze) e supponi che il matching sia stupido. Una volta passato ATS, il lettore umano prende il controllo e il contenuto conta più della densità di parole chiave.

Quantificare l'impatto di ingegneria

I CV tech spesso soffrono dello stesso problema di affermazioni generiche dei CV aziendali: 'sviluppato features', 'migliorato le performance', 'lavorato sulla piattaforma'. L'impatto specifico quantificato è ciò che separa un CV tech forte da uno generico:

• Performance: 'ridotta latenza API p99 da 850ms a 120ms' batte 'migliorate performance API'. I numeri specifici sono credibili; le affermazioni vaghe no
• Scale: 'gestito 50K req/sec al picco' o 'processato 2B eventi/giorno' ancora il lavoro in scala reale. Senza numeri, il lettore deve immaginare; con i numeri, capisce
• Costo: 'ridotto costo infrastruttura AWS di $180K/anno attraverso ottimizzazione database e tier-rightsizing' è il linguaggio che atterra con la leadership di ingegneria. La riduzione dei costi è spesso la metrica di ingegneria con maggior leva
• Affidabilità: 'ridotto tasso di incidenti di produzione da 8/mese a 1/mese' o 'migliorato SLO del servizio da 99,5 % a 99,95 %' sono metriche concrete di affidabilità
• Team e scope: 'tech lead per team di 6 ingegneri' o 'posseduto design end-to-end e implementazione del servizio pagamenti' dice al lettore il tuo scope di responsabilità. Senza questo, il lavoro potrebbe essere qualunque cosa da 'scritto una feature' a 'progettato l'intero sistema'
• Consegna: 'consegnato 12 release di produzione in 18 mesi con zero incidenti maggiori' o 'consegnato progetto 3 settimane prima del piano parallelizzando infrastruttura e lavoro di feature' racconta una storia di consegna
• Adozione: 'libreria interna usata da 15+ team' o 'progetto open source con 8K stelle GitHub' quantifica l'impatto del lavoro che non ha metriche orientate al cliente
• Quando non hai numeri specifici, dai descrizioni specifiche. 'Migrato il servizio di pagamenti da monolite ad architettura event-driven, con zero downtime durante il cutover' è concreto anche senza un numero

Il pattern: ogni bullet dovrebbe rispondere 'e quindi?' Se un bullet dice 'sviluppato features', l'e-quindi è invisibile. Se dice 'sviluppato flusso checkout che ha guidato l'incremento di conversione da 2,1 % a 3,2 % durante l'esperimento di 6 settimane', l'e-quindi è proprio lì. Riscrivi i bullet generici finché non hanno o un numero o un risultato specifico concreto.

Open source, side project, hackathon

L'assunzione di ingegneria valuta i contributi al di fuori del lavoro retribuito come prova di impegno genuino con il mestiere. Come gestirli nel CV:

• Contributi open source: includi se sostanziali. 'Maintainer di X (descrizione progetto, 8K stelle)' è segnale alto. 'Contribuito bug fix alla libreria popolare Y' è segnale medio. 'Sottomesso PR al progetto Z' è segnale basso a meno che il PR non sia stato sostanziale
• Elenca la natura del contributo: maintainer, contributore regolare, contributore occasionale, contributore una tantum. La distinzione conta e l'inquadramento onesto costruisce credibilità
• Se hai creato una libreria o strumento open source popolare, guida con quello sul CV. Un progetto open source ampiamente usato è uno dei segnali più forti possibili di capacità di ingegneria
• Side project: includi 2-3 dei più forti in una sezione Progetti. Salta side project che sono follow-along di tutorial, a metà terminati o esistono solo come repo privati
• Hackathon: includi solo se hai vinto o sei stato piazzato in uno notevole. Un 2° posto in un hackathon universitario o industriale maggiore vale la pena elencarlo; la partecipazione a un hackathon universitario no, a meno che tu non sia molto junior
• Progetti interni di azienda: di solito non contano come 'open source' anche se discussi pubblicamente. Includili invece sotto esperienza lavorativa
• Coinvolgimento nella comunità: organizzatore di meetup, speaker di conferenze, ospite di podcast, scrittore tecnico — includi questi se sostanziali. Segnalano un ingegnere che si impegna con la comunità più ampia piuttosto che fare solo il suo lavoro
• Sii onesto sullo scope. 'Contribuito a React' potrebbe significare 'aperto un issue che è stato chiuso senza PR' o 'scritto 30 PR che sono stati consegnati'. L'affermazione del CV e la prova GitHub devono corrispondere

Il ruolo di open source e side project cambia con la seniority. A livello junior, sono prove essenziali di essere un ingegnere praticante. A livello mid, differenziano. A livello senior, segnalano impegno continuato con il mestiere oltre il lavoro quotidiano. Calibra la prominenza alla tua fase di carriera.

Educazione e certificazioni — cosa conta

I ruoli tech ponderano educazione e certificazioni molto diversamente da altre industrie. Il panorama attuale:

• Ingegneri junior (0-2 anni): l'educazione conta. Laurea in Informatica o correlata da un'istituzione conosciuta ha peso. Elenca l'educazione prominentemente, vicino alla parte alta del CV
• Ingegneri mid-level (3-7 anni): l'educazione conta meno. La storia lavorativa è il segnale primario. Sposta l'educazione in fondo al CV a meno che tu non abbia una laurea particolarmente notevole (scuola top-tier, laurea avanzata in campo rilevante)
• Ingegneri senior (8+ anni): l'educazione è quasi irrilevante per la maggior parte dei ruoli. Una voce di una riga in fondo basta. L'eccezione sono i ruoli che valutano esplicitamente le credenziali accademiche (research engineering, certi ruoli ML/AI)
• Laureati di bootcamp: elenca il bootcamp. Il mercato di assunzione per laureati di bootcamp è maturato; bootcamp reputati (Hack Reactor, App Academy, Lambda School storicamente) sono riconosciuti. Abbina con progetti forti per compensare il tempo di apprendimento più breve
• Ingegneri autodidatti senza educazione CS formale: guida con progetti e storia lavorativa. Elenca l'apprendimento auto-diretto ('autodidatta, concentrato su sviluppo web full-stack dal 2019') onestamente. Non inventare credenziali, ma non sentirti obbligato a elencarne nessuna se non le hai
• Certificazioni AWS / GCP / Azure: contano per ruoli cloud-focused (DevOps, SRE, cloud architect, ingegneria di infrastruttura). Elenca il livello specifico di certificazione (Associate, Professional, etc.)
• Certificazioni di sicurezza (CISSP, OSCP, CEH): contano per ruoli di sicurezza. Elenca con data ottenuta
• Certificazioni generali di software (Oracle Java, Microsoft .NET): in gran parte ignorate. Elencarle su un CV di senior engineer è riempitivo
• Completamenti di corsi online (Coursera, Udemy, edX): generalmente non elencare. Segnalano che puoi completare un corso, non che puoi fare il lavoro. Eccezione: completare un programma specializzato (Stanford ML, specializzazione deep learning di Andrew Ng) potrebbe giustificare una menzione di una sola riga
• PhD: elenca in alto se recente e rilevante; sposta in basso con la seniority. PhD è un segnale forte per ruoli orientati alla ricerca e un segnale neutro (a volte leggermente negativo per percezione di 'troppo accademico') per ruoli di ingegneria di prodotto

Il pattern: l'educazione è un segnale di junior engineer che svanisce nel tempo. Le certificazioni sono segnali di ruoli specializzati che contano quando sono rilevanti e sono riempitivo quando non lo sono. Calibra la prominenza di queste sezioni a dove sei nella tua carriera.

CV tech remote-friendly — la nuova norma

Una parte significativa dei ruoli di ingegneria nel 2026 è remota o ibrida. Il CV dovrebbe segnalare remote-readiness, che ora è una considerazione di assunzione di per sé:

• Se hai esperienza di lavoro remoto, marcala: 'Senior Engineer (remoto), Acme Corp, 2022-2025'. I recruiter scansionano per questo; l'esperienza remota è un segnale positivo per ruoli remoti
• Posizione: includi città e paese attuali, ma segnala flessibilità se rilevante. 'Milano, Italia (aperto al remoto, fusi orari UE)' o 'San Francisco, CA (aperto al remoto negli US)'. Vago 'aperto alla relocation' è più debole della disponibilità specifica
• Fuso orario: elencalo se applichi per ruoli remoti in una geografia diversa. 'Fuso orario: CET (UTC+1)' rende la pianificazione più chiara
• Esperienza con strumenti di comunicazione: in un contesto rilevante per il remoto, menzionare esperienza con Slack, Notion, Linear, Figma, pair programming basato su video e workflow async-first segnala fit per la cultura di ingegneria remota
• Linguaggio di auto-direzione: 'guidato il progetto end-to-end dalla spec al deployment' segnala l'autonomia che il lavoro remoto richiede. 'Lavorato con il team per consegnare X' è neutro; 'guidato X dal concept al lancio indipendentemente' è più forte per il remoto
• Documentazione e scrittura: evidenzia qualsiasi scrittura tecnica, autorship di design docs o contributi RFC. I team remoti si affidano eccessivamente alla comunicazione scritta; gli ingegneri che scrivono bene sono più facili da assumere remotamente
• Segnali di sovrapposizione di fuso orario: se hai esplicitamente lavorato attraverso fusi orari (un ingegnere US che lavora con un team a Berlino, o viceversa), menzionalo. L'abilità di collaborazione asincrona è non-banale
• Evita di segnalare inflessibilità remote-only se sei aperto all'onsite. Il bias esiste ancora in alcune aziende; se sei flessibile, segnala flessibilità

La remote-friendliness si è spostata dall'essere una preferenza del candidato all'essere un criterio di assunzione. Mostrare sul CV che hai lavorato remotamente, comunicato asincrono e operato con auto-direzione è ora parte del lavoro del CV — non solo per ruoli completamente remoti ma per ibridi e persino alcuni ruoli onsite dove la remote-readiness è trattata come segnale di qualità.

CV per junior vs mid vs senior vs staff/principal

L'enfasi del CV di ingegneria cambia drasticamente attraverso le fasi di carriera. Ciò che funziona per un CV junior affonderà un CV staff e viceversa:

La dichiarazione di sommario per ruoli tecnici

La dichiarazione di sommario in cima a un CV tech è opzionale per ruoli junior e sempre più importante dal mid-level in su. Come scriverne una che faccia lavoro:

• Lunghezza: 3-5 righe. Abbastanza lunga per inquadrare la tua specialità, abbastanza breve perché il lettore la legga effettivamente
• Guida con anni di esperienza e specialità primaria: 'Ingegnere backend con 7 anni di esperienza nella progettazione di sistemi distribuiti ad alta scala, principalmente in Go e Python.' Questo è la prima cosa che il lettore vede e dovrebbe ancorare l'intero CV
• Segui con una frase sul tipo di lavoro che fai bene: 'Mi concentro sul confine tra design di API e infrastruttura, con esperienza profonda in architetture event-driven e interni di database.'
• Finisci con cosa stai cercando: 'Cercando ruoli senior+ dove posso guidare il design di un sistema backend critico e crescere in scope staff nei prossimi 2 anni.'
• Evita descrittori generici: 'appassionato', 'orientato ai risultati', 'attento al dettaglio'. Questi sono zero-segnale e si leggono come riempitivo
• Evita di riassumere il resto del CV. Il sommario dovrebbe aggiungere informazioni che il lettore non può ottenere scansionando il resto — specificamente la tua area di specialità, la tua direzione di carriera e cosa ti rende un candidato coerente
• Adatta per candidatura. Il sommario è il posto più facile per segnalare che il CV è mirato a questo ruolo specifico. Un sommario scritto per un ruolo di infrastruttura backend in un'azienda di database dovrebbe leggersi diversamente dal sommario della stessa persona scritto per un ruolo di backend di prodotto in un'azienda SaaS
• Salta il sommario interamente se sei un ingegnere junior. A quella fase di carriera, il sommario rischia riempitivo senza aggiungere segnale; lascia che il tuo lavoro parli da sé

La dichiarazione di sommario è real estate ad alta leva in cima al CV. Usata bene, dice al lettore chi sei come ingegnere in 3-5 righe e inquadra tutto ciò che segue. Usata male (aggettivi generici, aspirazioni vaghe), è riempitivo che spinge fuori il segnale reale.

Scelte di formato di CV tech — una pagina vs due pagine

La domanda una pagina vs due pagine è più sfumata per i CV tech che per altre industrie. Il quadro:

• Una pagina: ingegneri junior (0-3 anni), la maggior parte degli ingegneri mid-level (3-7 anni) e ingegneri in mercati dove una pagina è la norma culturale (la maggior parte dell'industria tech US)
• Due pagine: ingegneri senior con esperienza sostanziale (8+ anni), ingegneri staff/principal con scope significativo da comunicare, ingegneri in mercati dove due pagine sono normali (la maggior parte dell'Europa, specialmente Germania, Francia, UK)
• Mai tre pagine. Se non puoi adattare il tuo CV in due pagine, il problema è l'editing, non lo spazio. Taglia ruoli più vecchi a riassunti di una riga, taglia dettaglio da ruoli di carriera precoce, taglia progetti meno rilevanti
• Se hai un documento più lungo in stile CV (stile accademico, con pubblicazioni, talk, brevetti), tienilo separato. Il CV è il riassunto orientato al recruiter; il documento più lungo è per richieste di follow-up
• Formato: colonna singola o doppia? Colonna singola è più sicura per ATS. Se usi due colonne (sidebar per competenze/contatti, colonna principale per esperienza), testa il parsing eseguendo il PDF attraverso un resume parser online prima di sottomettere
• Font: attieniti a font standard (Calibri, Helvetica, Arial, Source Sans, Inter). Font designer-y possono rompere il parsing ATS. Testo corpo 10-11pt, heading 12-14pt
• Colore: minimo. Un colore di accento per gli heading di sezione va bene; il design a colore completo è non necessario e può rompere ATS. Il contenuto è il segnale, non il design
• Foto: non sui CV tech US. In paesi europei dove le foto sono normali (Germania, Francia), includi un headshot professionale
• Formato file: PDF. Sempre PDF. I documenti Word ri-fluiscono su macchine diverse e sembrano rotti; i PDF rendono consistentemente. Nomina il file consistentemente: 'Nome-Cognome-CV.pdf' o 'Nome-Cognome-SeniorEngineer-CV.pdf'

Le decisioni di formato dovrebbero servire il contenuto, non distrarre da esso. Un CV tech che usa font standard, struttura semplice e colore modesto è più leggibile di uno che cerca di sembrare un portfolio di design. L'eccezione è ingegneria di design o ruoli front-end dove qualche sofisticatezza visiva sul CV stesso è un segnale rilevante — ma anche lì, la moderazione si legge come fiducia.

Coordinare CV, LinkedIn, GitHub e sito personale

Il CV tech è un documento in una presenza online coordinata. Gli hiring manager di ingegneria guarderanno multiple superfici, e l'inconsistenza tra loro è un segnale negativo. Il playbook di coordinamento:

• LinkedIn: dovrebbe raccontare la stessa storia del CV in termini di ruoli, date e scope. L'headline può essere più aspirazionale ('Senior Backend Engineer interessato a sistemi distribuiti e developer tooling'), ma la sostanza dovrebbe corrispondere. Un LinkedIn che contraddice il CV (date diverse, titoli diversi, scope diverso) distrugge la fiducia
• GitHub: dovrebbe essere vivo. Commit recenti, readme di profilo popolato, 4-6 repository pinnati che rappresentano il tuo miglior lavoro, README di repo puliti. Un GitHub vuoto linkato dal CV è peggio di nessun link. Se GitHub è scarso, investi un weekend nel ripulirlo prima di inviare il CV
• Sito personale: opzionale ma potente quando fatto bene. Una pagina semplice con una bio di un paragrafo, evidenze di progetti, un link di download CV e info di contatto basta. Evita Flash, form di contatto rotti, link morti, date di ultimo aggiornamento del 2020
• Consistenza di nome e identità: usa lo stesso nome e headshot attraverso CV, LinkedIn, GitHub, sito personale. I recruiter fanno cross-reference; un 'James Smith' sul CV che è 'Jim Smith' su LinkedIn crea frizione
• Indirizzo email: consistente su tutte le superfici. Usa un'email professionale (tuonome@tuodominio.com o nome.cognome@gmail.com), non un'email universitaria o un username del 2005
• Numero di telefono, posizione e fuso orario: consistenti attraverso le superfici. Segnali di posizione conflittuali sembrano disattenzione
• Se hai un portfolio di lavoro pubblicato (post di blog tecnico, talk, paper), linka dal CV alla sorgente canonica — il tuo sito personale o un profilo centralizzato, piuttosto che 10 link separati
• Audita prima di applicare. Prima di inviare il CV, clicca ogni link su di esso come se fossi un recruiter. Guarda il profilo LinkedIn con occhi freschi. Naviga il GitHub. Se trovi qualcosa che contraddice o sottomina il CV, ripara prima di applicare

L'hiring manager costruisce un'unica impressione di te dalle superfici coordinate, non impressioni separate da ciascuna. Il CV che punta a una presenza online coerente si legge come più credibile di uno con un CV forte e un LinkedIn/GitHub debole o contraddittorio. I trenta minuti di pulizia attraverso le superfici sono uno degli usi a maggior leva del tempo in una ricerca di lavoro tech.