Un curriculum per un ruolo DevOps o di platform engineering si legge meglio quando mette in evidenza affidabilità, reperibilità, migrazioni di infrastruttura e strumenti da cui dipendono altri team, invece dei punti elenco orientati alle funzionalità che un curriculum generico da software engineer usa spesso. I due tipi di curriculum condividono la maggior parte della stessa struttura: esperienza in ordine cronologico inverso, un breve riepilogo, una sezione competenze e punti elenco che descrivono risultati invece di compiti. Ciò che cambia è quali risultati impressionano davvero in questo tipo di ruolo, dato che a beneficiare del lavoro infrastrutturale sono di solito altri ingegneri e non utenti finali, e il lavoro stesso resta spesso invisibile quando va bene.
Perché l'enfasi si sposta
Una funzionalità costruita da un software engineer ha di solito un prima e dopo visibile: una schermata che non esisteva, un flusso che passava da cinque passaggi a due. Il lavoro infrastrutturale e di piattaforma raramente ottiene lo stesso risultato visibile, perché il miglior esito possibile è spesso che dal punto di vista dell'utente non cambi nulla: un deploy che prima svegliava qualcuno alle due di notte ora non lo fa più, un servizio che si bloccava sotto carico ora non si blocca più. Un curriculum per questo tipo di ruolo deve rendere quella affidabilità invisibile comprensibile a chi non ha mai lavorato in infrastruttura, nominando cosa dipendeva da quel lavoro e cosa si sarebbe rotto senza di esso.
Descrivere onestamente affidabilità e tempo di attività
Il lavoro sull'affidabilità porta alla stessa trappola descritta in quantificare l'impatto ingegneristico nel CV senza inventare numeri: una cifra allettante ma non verificabile come "tempo di attività migliorato del 40%" quando una cifra simile non è mai stata davvero tracciata. Dove esiste una metrica reale, ancora verificabile da una dashboard o da un report di incidente, ha il suo posto nel curriculum così com'è. Dove non esiste, l'ambito e uno stato prima-dopo descritto pesano lo stesso senza il rischio.
Reperibilità e gestione degli incidenti come contenuto del curriculum
La responsabilità di reperibilità merita una menzione diretta invece di essere nascosta in una riga vaga come "supporto ai sistemi di produzione", perché segnala un livello di responsabilità operativa che un ruolo puramente orientato alle funzionalità non porta. Ciò che si legge bene è la forma di quella responsabilità: per quale sistema o sistemi eri reperibile, come funzionava a grandi linee la rotazione, e una cosa concreta cambiata grazie a un incidente gestito.
Migrazioni e cambiamenti infrastrutturali degni di nota
Una migrazione, un cambio di piattaforma o un cambio di strumento merita un proprio punto elenco quando è il tipo di progetto a cui altri ingegneri hanno dovuto adattarsi, invece di un cambiamento puramente interno che nessuno fuori dal team ha notato. Nominare cosa si è spostato e perché fornisce di solito più informazioni della semplice menzione del nome della tecnologia di destinazione.
Strumenti da cui dipendono altri team
Uno strumento interno merita lo stesso trattamento di una funzionalità rivolta al cliente: cosa fa, chi lo usa, cosa ha sostituito. Presentare progetti personali nel CV di un software engineer copre la stessa struttura di fondo per lavoro costruito fuori da un impiego formale, e si applica altrettanto bene a uno strumento interno costruito all'interno di un impiego.
Esempio illustrativo: un punto elenco riscritto attorno alla responsabilità infrastrutturale
Prima, vago e orientato alle funzionalità: "Ho lavorato su infrastruttura e deploy per il team backend." Dopo, riscritto attorno a responsabilità, ambito e uno stato prima-dopo descritto: "Ho gestito la pipeline di deploy per gli undici servizi del team backend; prima la pipeline richiedeva un passaggio di approvazione manuale per ogni servizio prima del deploy, e dopo la riscrittura una suite di test superata bastava per il deploy automatico, riducendo da tre a uno il numero di ingegneri che dovevano essere disponibili al momento del rilascio."
Raggruppare un lungo elenco di strumenti e piattaforme
La sezione competenze di un platform engineer è spesso più lunga di quella di uno sviluppatore tipico, spaziando contemporaneamente tra provider cloud, strumenti di orchestrazione, sistemi di monitoraggio e linguaggi, esattamente il tipo di elenco lungo e misto che beneficia di un raggruppamento per categorie invece di una singola riga non ordinata.
Crea il tuo
Il modello Developer di CVBuilderKit è costruito attorno a voci guidate da progetti e responsabilità, il che si adatta al lavoro infrastrutturale e di piattaforma tanto quanto al codice applicativo. Parti da lì, o da un documento vuoto, in il creatore e riscrivi i tuoi punti elenco su affidabilità, reperibilità e migrazioni attorno a ciò che dipendeva davvero dal lavoro prima di ricorrere a un numero che al momento non puoi dimostrare.