Un curriculum credibile per uno sviluppatore junior senza ancora esperienza retribuita comincia con ciò che puoi davvero dimostrare, non con una sezione esperienza vuota tirata artificialmente per le lunghe. Progetti personali, lavori universitari, un progetto finale di bootcamp o qualsiasi contributo reale a una codebase diventano la sezione che altrimenti occuperebbe l'esperienza, costruita nello stesso modo di una voce lavorativa: un titolo chiaro, le date, lo stack usato e una breve descrizione di cosa è cambiato grazie a quel lavoro. La formazione sostiene tutto questo, e un breve riassunto in cima indica con chiarezza il tuo livello attuale e il tipo di ruolo che stai cercando, invece di camuffare con un linguaggio vago l'assenza di un impiego retribuito.
Metti i progetti dove normalmente starebbe l'esperienza
Per un curriculum da sviluppatore junior senza esperienza retribuita, un buon cambio strutturale è dare alla sezione progetti lo stesso peso e la stessa posizione che normalmente ha il percorso lavorativo: prima intestazione e breve riassunto, poi progetti, poi formazione, poi una sezione competenze, e solo dopo tutto ciò che è extra-curricolare. Chi seleziona il personale scorre rapidamente il documento dall'alto verso il basso, quindi il contenuto più forte e più rilevante per il ruolo deve venire per primo, e per chi ha come punto di forza principale un portfolio di cose costruite, questo significa i progetti, non uno stage o un lavoro part-time senza legame con lo sviluppo. Due o tre progetti, scelti per la rilevanza rispetto al ruolo target piuttosto che per quanto recenti siano, si leggono meglio di cinque o sei ammassati insieme. Un progetto fatto per un corso universitario, un progetto finale di bootcamp e uno strumento personale hanno tutti diritto di comparire qui, purché ciascuno riceva lo stesso trattamento: un nome, una breve descrizione, lo stack e cosa fa, non solo un elenco di titoli di corsi.
Scrivi ogni voce di progetto come un lavoro, non come un hobby
Ogni voce di progetto funziona meglio con gli stessi campi di una voce lavorativa: un titolo, un periodo, le tecnologie usate, e da una a tre righe che descrivono cosa fa il progetto, quale parte hai costruito tu se si trattava di un lavoro di gruppo, e qualsiasi cambiamento o risultato che ne è derivato. Nominare lo stack specifico, un linguaggio, un framework, un database, una piattaforma di deployment, conta più qui che in una voce lavorativa, perché spesso è la prova più chiara che un lettore ha di cosa sai realmente fare. Se un progetto è stato costruito con altri, indica cosa hai gestito tu in particolare invece di descrivere il progetto nel suo insieme lasciando poco chiaro il tuo contributo; un progetto di squadra che elenca solo il risultato complessivo del gruppo si legge più vago, non più impressionante. Un progetto ancora in corso merita di essere incluso se è abbastanza avanzato da poter essere descritto in modo concreto, ma un progetto che non è mai andato oltre l'idea è meglio lasciarlo fuori del tutto, perché una voce del curriculum ha bisogno di qualcosa di concreto da dire su cosa è stato effettivamente costruito.
Anche un contributo al codice di qualcun altro conta, e spesso si legge come più credibile di un progetto solitario perché dimostra che sai lavorare dentro un codice che non hai scritto tu. Se hai corretto un bug, aggiunto una piccola funzionalità o migliorato la documentazione di un progetto open source, nomina il progetto, descrivi la modifica specifica in una riga e spiega cosa è servito per farla accettare, ad esempio capire una suite di test già esistente o seguire per la prima volta un processo di contribuzione. Una voce così, anche piccola, dimostra qualcosa che un progetto solitario del weekend non può: lavorare dentro i vincoli di qualcun altro, non solo i propri.
Esempio illustrativo: una riga di progetto vaga riscritta come voce completa
Prima: "Ho fatto un sito web con degli amici per un progetto universitario."
Dopo: "Task Tracker, progetto di squadra, corso universitario, marzo-maggio [anno]. Ho costruito l'API backend in Node.js ed Express, gestendo autenticazione e assegnazione dei compiti per un team di quattro persone; il frontend è stato costruito da due compagni di squadra in React. Distribuito su un piano di hosting gratuito per la sessione dimostrativa del corso."
La versione riscritta mantiene lo stesso fatto di base, un piccolo progetto di squadra per un corso, ma ora indica lo stack, la parte specifica costruita, la dimensione del team e cosa ne è derivato, dando al lettore qualcosa di concreto da valutare invece di una singola frase piatta.
Competenze e formazione, mantenute oneste
Elenca le competenze raggruppate per categoria, linguaggi, framework, strumenti, cloud, invece che in un'unica lunga riga non ordinata, in modo simile a come una sezione competenze può essere raggruppata nel modello per sviluppatori di CVBuilderKit. Limita l'elenco a ciò di cui potresti parlare in un colloquio con una profondità ragionevole; un elenco lungo gonfiato con strumenti toccati una sola volta in un tutorial fa più danno di uno più corto ma accurato, perché un intervistatore che fa una domanda di approfondimento su una voce gonfiata nota il vuoto rapidamente. La formazione resta, con titolo di studio, istituto e data di laurea prevista o effettiva, insieme a qualunque corso direttamente rilevante per il ruolo target se questa sezione risulta altrimenti un po' esile.
Prima di inviare la prima versione
Una volta definita la struttura, leggi tutto come farebbe un selezionatore: la prima voce di progetto dice abbastanza da meritare un secondo sguardo, e la riga di riassunto indica un obiettivo reale invece che generico? Vale la pena leggere il riassunto da solo, separato dal resto del documento, e chiedersi se nomina un tipo di ruolo specifico, come "sviluppatore backend junior" o "sviluppatore frontend specializzato in React", invece di una frase generica come "sviluppatore motivato in cerca di opportunità" che potrebbe descrivere quasi chiunque. Scrivere un curriculum con poca o nessuna esperienza lavorativa da neolaureato affronta lo stesso problema da un'angolazione più ampia se la sola sezione progetti non porta ancora abbastanza peso, in particolare per come presentare formazione e stage. Quando la struttura ti sembra giusta, inizia a costruirlo e adatta la formulazione a ogni nuovo progetto aggiunto; un curriculum costruito così è facile da ampliare quando finalmente arriva il primo impiego retribuito, perché la sezione progetti semplicemente scende più in basso invece di dover essere ricostruita da zero.