Non esiste un modo affidabile per attribuire una percentuale a un lavoro di ingegneria che non è mai stato misurato, e inventare un numero per assecondare il consiglio generico "quantifica il tuo impatto" è peggio che lasciare il numero fuori, perché una statistica inventata o è sbagliata o è impossibile da difendere quando qualcuno chiede da dove viene. Ciò che si può descrivere onestamente, anche senza una metrica tracciata, è l'ambito: quanto era grande il sistema, quante persone o servizi ne dipendevano, con quale frequenza girava e cosa è realmente cambiato tra uno stato precedente e uno successivo. Sono fatti che di solito puoi ricostruire dalla memoria, da uno storico di ticket o da un report post-incidente, e risultano molto più credibili per chi legge il curriculum di un numero uscito dal nulla.
Perché il consiglio "aggiungi solo un numero" non regge senza una metrica
La maggior parte dei consigli sul curriculum dice agli ingegneri di quantificare ogni voce, e il consiglio non è sbagliato di per sé: chi scorre decine di curriculum reagisce davvero meglio a qualcosa di concreto piuttosto che a un'affermazione vaga. Il problema è che gran parte del lavoro di ingegneria reale non è mai stata tracciata in un modo che produca una percentuale pulita. Molti team non gestiscono una dashboard per ogni modifica, molto impatto si percepisce più che misurarsi, e molti ingegneri passano a un nuovo ruolo prima che qualcuno torni a verificare se la modifica del trimestre scorso abbia davvero aiutato. Di fronte a questo vuoto, la scorciatoia allettante è scrivere un numero che sembra plausibile e sperare che nessuno chieda da dove venga. Questa è esattamente la trappola che questo articolo vuole aiutarti a evitare, perché un numero che un intervistatore può smontare con una sola domanda successiva fa più danni della totale assenza di un numero.
Misure oneste che esistono anche senza una metrica tracciata
Per quasi ogni lavoro di ingegneria esistono diversi tipi di dettagli concreti, indipendentemente dal fatto che sia mai stata registrata una metrica. L'ambito descrive la dimensione di ciò che hai toccato: quanti servizi ha coinvolto una modifica, quanto è grande la codebase, quanti endpoint o tabelle sono stati interessati. La scala descrive quanto sopportava il sistema: quante richieste serviva, quanti record memorizzava, quanti team ci costruivano sopra, espresso in termini che puoi affermare con sicurezza invece di un numero che stai indovinando. La frequenza descrive quanto spesso qualcosa girava o veniva usato: un job batch eseguito ogni notte, una pipeline di deploy usata da ogni ingegnere del team, un report generato a ogni trimestre chiuso. Lo stato prima e dopo descrive cosa era vero prima della tua modifica e cosa lo è diventato dopo, in linguaggio semplice invece che in percentuale: cosa falliva prima, cosa richiedeva un passaggio manuale, cosa richiedeva qualcuno reperibile, e cosa ha smesso di essere vero una volta rilasciato il lavoro. Chi ne dipendeva indica il pubblico reale: il team che usava lo strumento che hai costruito, il servizio che chiamava l'API che mantenevi, la reperibilità che non veniva più allertata per il problema che hai risolto. Ognuno di questi punti è qualcosa che hai vissuto davvero e puoi descrivere in prima persona, ed è proprio questo a renderlo molto più difendibile di una percentuale arrotondata.
Esempio illustrativo: una voce riscritta attorno all'ambito invece che a una percentuale
Prima, vaga e non quantificata: "Responsabile delle prestazioni del servizio di checkout." Dopo, riscritta attorno all'ambito e a uno stato prima/dopo descritto invece che a un numero inventato: "Responsabile del livello di query del database del servizio di checkout, l'unico percorso attraversato da ogni acquisto sul sito; prima della riscrittura, le query lente erano la causa più comune di un checkout bloccato che il team di supporto doveva escalare, e dopo il rilascio quella categoria di reclami ha smesso di comparire nel triage settimanale." Niente nella versione riscritta è una statistica indovinata. Dichiara di cosa si occupava il candidato, quanto fosse centrale quella parte per il sistema, com'era il problema prima e cosa è cambiato dopo, tutto tratto da qualcosa che il candidato ha realmente vissuto e non da un numero ricostruito a posteriori.
Cosa lasciare fuori dalla riscrittura
La linea da tenere è tra un numero a cui puoi puntare oggi, proveniente da una dashboard, un report post-incidente o una metrica che hai realmente tracciato all'epoca, e un numero che ricostruisci da un ricordo vago tipo "sembrava che le cose fossero molto più veloci". Il primo si può citare direttamente senza problemi. Il secondo è proprio quello che vale la pena riscrivere usando invece un linguaggio di ambito e di prima/dopo, perché un'impressione ricordata e arrotondata in un numero che suona bene è esattamente il tipo di affermazione che crolla davanti a una sola domanda specifica in un colloquio. La versione basata sull'ambito sopra descritta regge a quella domanda, perché ogni parte di essa è qualcosa che puoi descrivere con parole tue senza appoggiarti a un numero che non hai mai davvero registrato.
Come questo si collega al più ampio schema di trasformare i compiti in risultati
Riscrivere attorno all'ambito invece che a una statistica inventata è un'applicazione specifica di un cambiamento più ampio, che si applica ben oltre l'ingegneria: trasformare una descrizione di ciò di cui eri responsabile in una descrizione di ciò che è realmente cambiato di conseguenza. Trasformare i compiti in risultati nel CV tratta questo schema di riscrittura più ampio con esempi da ruoli al di fuori dell'ingegneria, per chiunque abbia voci che oggi si leggono come un elenco di compiti assegnati invece che come risultati.
Scrivere questa voce
Come scrivere un curriculum tratta le scelte di formulazione che portano questo tipo di riscrittura nel resto del curriculum, e il modello developer di CVBuilderKit è costruito proprio per questo tipo di voce basata su ambito e progetto. Parti da un documento esistente o vuoto in l'editor e riscrivi ogni voce usando l'ambito e uno stato prima/dopo descritto prima di ricorrere a un numero che in realtà non puoi difendere.