Il modo per far stare anni di lavoro ingegneristico in una pagina non è ridurre ogni progetto a un frammento illeggibile. È scegliere i tre o quattro progetti che sostengono meglio il ruolo per cui ti candidi, raggruppare il resto in un'unica riga verso il fondo, e scrivere ogni progetto rimasto come una riga compatta invece che come un paragrafo. Una pagina che cerca di contenere dodici progetti con lo stesso peso finisce per non presentarne bene nessuno; una pagina che ne mantiene quattro a pieno peso, con il resto solo accennato, si legge come un curriculum più forte, anche se tecnicamente dice meno.
Decidere quali progetti meritano un posto
Inizia classificando i progetti in base a quanto si adattano al ruolo specifico, non a quanto ne sei orgoglioso. Un progetto che ha usato lo stesso stack tecnologico del ruolo target, ha risolto un problema simile, o mostra la responsabilità di un intero sistema invece che di una piccola parte, merita un posto prima di un progetto tecnicamente impressionante ma lontano da ciò di cui il ruolo ha davvero bisogno. Anche la recenza conta, anche se meno della rilevanza: un progetto più vecchio ma vicino al ruolo target spesso batte uno recente che non lo è. Tre o quattro progetti sono di solito sufficienti per una pagina quando sono presenti anche le voci di esperienza; un curriculum fatto soprattutto di progetti, con ancora poca esperienza retribuita, può arrivare a cinque o sei prima che la pagina inizi a sembrare affollata.
Un errore comune è classificare in base allo sforzo invece che alla rilevanza: un progetto costato sei mesi di weekend può sembrare meritevole del primo posto solo per il tempo investito, anche quando un progetto più piccolo di due settimane corrisponde in modo molto più diretto a ciò che il ruolo target fa davvero ogni giorno. Lo sforzo è invisibile a un lettore che vede solo la riga finale sulla pagina, quindi vale la pena metterlo volutamente da parte e riclassificare solo in base all'aderenza prima di stabilire quali quattro progetti restano.
Raggruppare i più piccoli in un'unica riga
Un progetto che non entra tra i pochi in evidenza non deve per forza sparire. Una singola riga verso il fondo della sezione progetti, tipo "Anche realizzato: un bot di notifiche per Slack, una piccola CLI per la ricerca nei log, e due script di strumenti interni", li mantiene visibili senza dare loro lo stesso spazio delle voci in evidenza. Questa riga svolge un lavoro reale: segnala che i progetti in evidenza sono stati scelti deliberatamente e non sono tutto ciò che hai mai costruito, e offre a un lettore interessato un punto di partenza da chiedere in una conversazione, senza costringere ogni progetto alla stessa descrizione completa.
Scrivere una voce di progetto in una riga
Una voce di progetto in una riga deve comunque rispondere a cos'è, con cosa è stato costruito, e cosa ne è derivato, solo compresso in una riga invece che tre. "Dashboard di metriche - React e una piccola API Node che attinge da un flusso di eventi interno, ha sostituito tre fogli di calcolo separati che il team usava per tracciare manualmente gli stessi numeri" sta comodamente in una riga e dice comunque al lettore qualcosa di concreto. Ridurre un progetto a un semplice titolo senza contesto, al contrario, risparmia spazio ma non conserva nessuna delle informazioni che rendevano la riga degna di essere inclusa fin dall'inizio. L'obiettivo è la densità, non la brevità fine a se stessa: una riga che dice meno con meno parole non è automaticamente una riga migliore.
Esempio illustrativo: un elenco progetti accorciato
Esempio illustrativo. Un candidato ha nove progetti personali e affini al lavoro costruiti nel corso di diversi anni. Prima dell'accorciamento, ciascuno ha una propria voce di due righe, e la sola sezione progetti occupa quasi un'intera pagina. Dopo l'accorciamento: quattro progetti vengono mantenuti con tutti i dettagli, scelti perché più vicini allo stack tecnologico e all'ambito del ruolo target, ciascuno scritto in una riga che indica cos'è, cosa ha usato e cosa è cambiato grazie ad esso. I restanti cinque vengono raccolti in un'unica riga finale che li nomina brevemente. La sezione progetti ora occupa circa un terzo dello spazio di prima, e le quattro voci in evidenza si leggono con più attenzione perché non competono più con altre cinque per la stessa attenzione.
Restare leggibili mentre si comprime
Far stare più contenuti in una pagina riducendo la dimensione del carattere o i margini oltre un livello di lettura comodo scambia un problema con uno peggiore: una pagina che tecnicamente contiene tutto ma è scomoda da leggere perde più di una pagina che onestamente avrebbe avuto bisogno di un formato leggermente più lungo. La compressione dovrebbe derivare dalla scelta di cosa includere, non dal rendere il testo stesso più difficile da leggere. Se quattro voci di progetto complete più una riga di raggruppamento ancora non stanno a una dimensione di lettura normale, di solito è un segnale per tagliare un quinto progetto invece di rimpicciolire ulteriormente il testo, oppure un segnale che questo curriculum in particolare giustifica onestamente una seconda pagina.
Quando progetti ed esperienza competono per la stessa pagina
Per un ingegnere con diversi anni di esperienza retribuita e un lungo elenco di progetti personali, entrambe le sezioni competono per lo stesso spazio limitato, e l'esperienza dovrebbe di solito vincere quella competizione per prima. Un lettore che valuta un ingegnere a metà carriera generalmente pesa il lavoro retribuito e responsabile più di un progetto personale, quindi ridurre la sezione progetti alle sue poche voci in evidenza, invece di ridurre le voci di esperienza per fare spazio a più progetti, è di solito il posto più sicuro dove trovare lo spazio extra di cui un curriculum di una pagina ha bisogno.
Costruisci il tuo
Scegli un modello pensato per il lavoro ingegneristico, come il modello Developer, e ripercorri il tuo elenco di progetti con lo stesso filtro: quali pochi progetti sostengono più direttamente il ruolo, e quali possono essere nominati in un'unica riga finale invece. Per la domanda più generale su quanto dovrebbe essere lungo un curriculum prima ancora che i progetti entrino in gioco, quanto dovrebbe essere lungo un curriculum copre i compromessi più ampi, e presentare progetti personali in un curriculum da ingegnere del software approfondisce come scrivere una singola voce di progetto una volta che sai quali sono sopravvissuti alla scrematura. Inizia a comprimere e ricostruire su il generatore.