Cosa scansiona davvero per primo un recruiter
Un recruiter dedica pochi secondi al terzo superiore di un curriculum da ingegnere software prima di decidere se continuare a leggere: il tuo titolo più recente, i linguaggi e i framework nella riga delle competenze, e il primo punto elenco sotto il tuo ruolo più recente. Tutto ciò che segue conferma l'impressione già data dalla parte alta della pagina, oppure fa perdere del tutto l'attenzione del lettore.
Questo significa che l'intestazione e la prima esperienza lavorativa pesano più di qualsiasi altra parte della pagina. Metti la riga più forte e specifica per prima sotto ogni ruolo, invece di nasconderla come terzo o quarto punto elenco, e tieni la riga delle competenze vicino all'inizio così un occhio che scorre la raggiunge prima di passare al curriculum successivo nella pila.
Un esempio junior: progetti al posto dell'esperienza
Un ingegnere junior con uno stage e qualche progetto personale può comunque scrivere un curriculum completo e specifico trattando ogni progetto come una voce lavorativa. Sotto un progetto chiamato "Order Tracker", un candidato junior potrebbe scrivere: "Costruita un'app React e Node per il tracciamento ordini per una caffetteria locale; aggiunto un filtro di ricerca che ha ridotto il tempo medio di ricerca da 12 secondi a meno di 2." È un'illustrazione specifica e citata del pattern, non un'affermazione su un risultato tipico.
La voce dello stage segue la stessa regola: nomina cosa è cambiato, non solo cosa ti è stato assegnato. Una riga come "Corretti 14 bug segnalati nel flusso di checkout durante uno stage di 10 settimane, tre dei quali bloccavano il rilascio" dice a un lettore più di "Assistito il team di ingegneria nella correzione di bug." Limita questa sezione a due o tre progetti, ciascuno con uno o due punti elenco, invece di elencare ogni repository mai pubblicato.
Un esempio di livello medio: punti elenco d'impatto con un prima e un dopo
Un ingegnere di livello medio con tre-sei anni di esperienza dovrebbe sostituire i punti elenco basati sui compiti con un numero prima-e-dopo ovunque ne esista davvero uno. Per un ruolo backend, potrebbe suonare così: "Ridotta la latenza p95 del checkout da 1,8 s a 620 ms raggruppando tre query sequenziali in una, su un servizio che gestisce circa 40.000 richieste al giorno." Il numero fa il lavoro di convincere; la frase intorno dà solo il contesto.
Un secondo esempio per un tipo diverso di contributo: "Guidata la migrazione del modulo di autenticazione di un monolite verso un servizio separato, coordinandomi con altri due team per sei settimane senza tempi di inattività durante il passaggio." Non ogni punto elenco ha bisogno di una percentuale - un'indicazione di ambito come "coordinandomi con altri due team" resta concreta, perché indica chi era coinvolto e quanto tempo c'è voluto, invece di chiamare semplicemente il lavoro "collaborazione tra team."
Quando tenere una sezione progetti separata
Una sezione progetti dedicata ha senso quando hai lavori paralleli che mostrano qualcosa che la tua storia lavorativa non mostra: un linguaggio che usi fuori dal lavoro, un contributo open source, o uno strumento personale che hai costruito e mantieni ancora. Per un candidato junior spesso fa più lavoro della sezione esperienza stessa; per un candidato senior di solito è facoltativa a meno che il progetto non sia insolitamente rilevante per il ruolo a cui ti candidi.
Mantieni ogni voce di progetto a una riga di contesto e uno o due punti elenco, la stessa densità di una voce lavorativa, e collega il repository o una demo live se esistono. Una sezione progetti che elenca dieci voci senza dettagli si legge come riempitivo; tre voci con un punto elenco specifico ciascuna si leggono come prove.
Competenze e strumenti: specifici, non esaustivi
Elenca i linguaggi, i framework e gli strumenti su cui ti sentiresti davvero a tuo agio a rispondere in un colloquio, raggruppati in un modo sensato per il ruolo - linguaggi, framework, infrastruttura, e così via. Omettere una tecnologia usata solo per una settimana va bene; l'elenco dovrebbe riflettere ciò di cui puoi parlare, non tutto ciò che ha mai toccato il tuo curriculum.
Fai corrispondere la terminologia all'annuncio quando è onestamente accurata: se l'annuncio dice "PostgreSQL" e l'hai usato, scrivi "PostgreSQL" invece di solo "database SQL", perché sia un sistema di tracciamento candidati sia un lettore umano spesso cercano il termine esatto. Non aggiungere una tecnologia che non hai usato solo perché un annuncio la nomina - quel vuoto emerge alla prima conversazione tecnica.
Domande frequenti
- Un curriculum junior da ingegnere software dovrebbe elencare prima i progetti o l'esperienza?
- I progetti per primi se hai poca esperienza retribuita, perché lì si trova la tua prova più forte e specifica; sposta l'esperienza sopra i progetti non appena hai uno stage o un lavoro vero da mostrare, e tieni la sezione più forte più vicino all'inizio della pagina.
- Quanti punti elenco dovrebbe avere ogni progetto o ruolo?
- Due-quattro punti elenco per voce di solito bastano per mostrare cosa hai costruito e cosa è cambiato di conseguenza. Di più inizia a diluire la pagina, e un lettore tende a ricordare la prima o seconda riga sotto ogni voce molto più della quarta o quinta.
- Va bene riutilizzare lo stesso curriculum per ogni lavoro da ingegnere software?
- La struttura può restare la stessa, ma la riga delle competenze e l'ordine dei tuoi punti elenco dovrebbero cambiare per adattarsi ai requisiti dichiarati in ogni annuncio, perché sia un lettore umano sia un filtro automatico spesso cercano i termini specifici usati da quell'annuncio.
- Cosa dovrebbe tagliare un ingegnere di livello medio se il curriculum supera le due pagine?
- Taglia i ruoli più vecchi di circa dieci anni a meno che non siano direttamente rilevanti, riduci qualsiasi punto elenco che descrive solo una responsabilità invece di un risultato, e mantieni la sezione progetti solo se mostra qualcosa che la tua storia lavorativa non copre già davvero.