Cv-voorbeelden voor software-engineers

Wat een recruiter echt eerst scant

Een recruiter besteedt maar een paar seconden aan het bovenste derde deel van een cv van een software-engineer voordat hij beslist of hij verder leest: je meest recente functietitel, de talen en frameworks in je skills-regel, en de eerste bullet onder je meest recente functie. Alles daaronder bevestigt ofwel de indruk die het bovenste deel van de pagina al maakte, of verliest de aandacht van de lezer volledig.

Dat betekent dat de header en de eerste werkervaring meer gewicht dragen dan enig ander deel van de pagina. Zet je sterkste, specifiekste regel eerst onder elke functie in plaats van die als derde of vierde bullet te verstoppen, en houd de skills-regel dicht bij de bovenkant zodat een scannend oog die bereikt voordat het naar het volgende cv in de stapel gaat.

Een junior-voorbeeld: projecten in plaats van ervaring

Een junior engineer met een stage en een paar eigen projecten kan alsnog een compleet, specifiek cv schrijven door elk project als een werkervaring te behandelen. Onder een project genaamd "Order Tracker" zou een junior kandidaat kunnen schrijven: "React- en Node-app voor het volgen van bestellingen gebouwd voor een lokaal café; zoekfilter toegevoegd dat de gemiddelde zoektijd van 12 seconden naar onder de 2 seconden bracht." Dit is een specifieke, geciteerde illustratie van het patroon, geen uitspraak over een typisch resultaat.

De stage-invoer volgt dezelfde regel: benoem wat er veranderde, niet alleen wat je kreeg toegewezen. Een regel als "14 gemelde bugs in de afrekenflow opgelost tijdens een stage van 10 weken, waarvan drie de release blokkeerden" zegt een lezer meer dan "Het engineeringteam geholpen bij bugfixes." Houd deze sectie op twee of drie projecten, elk met een of twee bullets, in plaats van elke repository die je ooit gepusht hebt te vermelden.

Een medior-voorbeeld: impact-bullets met een voor en na

Een medior engineer met drie tot zes jaar ervaring moet taakgerichte bullets vervangen door een voor-en-na-cijfer waar dat er echt een is. Voor een backend-functie zou dat kunnen zijn: "P95-latentie van het afrekenen verlaagd van 1,8 s naar 620 ms door drie opeenvolgende queries te bundelen tot één, op een service die ongeveer 40.000 verzoeken per dag verwerkt." Het cijfer doet het overtuigende werk; de zin eromheen geeft alleen context.

Een tweede voorbeeld voor een ander soort bijdrage: "De migratie van de authenticatiemodule van een monoliet naar een aparte service geleid, zes weken samengewerkt met twee andere teams zonder downtime tijdens de overgang." Niet elke bullet heeft een percentage nodig - een scope-uitspraak als "samengewerkt met twee andere teams" is nog steeds concreet, omdat het noemt wie erbij betrokken was en hoe lang het duurde, in plaats van het werk simpelweg "cross-team samenwerking" te noemen.

Wanneer je een aparte projectensectie moet houden

Een aparte projectensectie is de moeite waard als je nevenwerk hebt dat iets laat zien wat je werkgeschiedenis niet laat zien: een taal die je buiten het werk gebruikt, een open-source bijdrage, of een persoonlijke tool die je hebt gebouwd en nog steeds onderhoudt. Voor een junior kandidaat doet die vaak meer werk dan de ervaringssectie zelf; voor een senior kandidaat is die meestal optioneel, tenzij het project ongewoon relevant is voor de functie waarop je solliciteert.

Houd elke projectinvoer op één contextregel en een of twee bullets, dezelfde dichtheid als een werkervaring, en link naar de repository of een live demo als die bestaan. Een projectensectie die tien items zonder detail vermeldt, leest als opvulling; drie items met elk een specifieke bullet lezen als bewijs.

Skills en tools: specifiek, niet uitputtend

Vermeld de talen, frameworks en tools waarover je je echt op je gemak zou voelen als je erover werd bevraagd in een sollicitatiegesprek, gegroepeerd op een manier die logisch is voor de functie - talen, frameworks, infrastructuur, enzovoort. Een technologie weglaten die je maar een week hebt gebruikt is prima; de lijst moet weergeven waarover je kunt praten, niet alles wat ooit je cv heeft geraakt.

Laat de bewoordingen aansluiten bij de vacature waar dat eerlijk klopt: als de vacature "PostgreSQL" zegt en je hebt het gebruikt, schrijf dan "PostgreSQL" in plaats van alleen "SQL-databases", omdat zowel een geautomatiseerd sollicitatievolgsysteem als een menselijke lezer vaak op de exacte term zoeken. Voeg geen technologie toe die je niet hebt gebruikt alleen omdat een vacature die noemt - dat gat komt naar boven in het eerste technische gesprek.

Veelgestelde vragen

Moet een junior cv voor software-engineers eerst projecten of ervaring vermelden?

Projecten eerst als je weinig betaalde ervaring hebt, want daar zit je sterkste, specifiekste bewijs; verplaats ervaring boven projecten zodra je een echte stage of baan hebt om te laten zien, en houd de sterkere sectie dichter bij de bovenkant van de pagina.

Hoeveel bullets moet elk project of elke functie hebben?

Twee tot vier bullets per invoer is meestal genoeg om te laten zien wat je gebouwd hebt en wat daardoor veranderde. Meer dan dat verdunt de pagina, en een lezer onthoudt de eerste een of twee regels onder elke invoer veel beter dan de vierde of vijfde.

Is het oké om hetzelfde cv opnieuw te gebruiken voor elke software-engineeringbaan?

De structuur kan hetzelfde blijven, maar de skills-regel en de volgorde van je bullets moeten wijzigen om aan te sluiten bij de eisen van elke vacature, omdat zowel een menselijke lezer als een geautomatiseerd filter vaak zoeken naar de specifieke termen die die vacature gebruikt.

Wat moet een medior engineer schrappen als het cv langer wordt dan twee pagina's?

Schrap functies ouder dan ongeveer tien jaar, tenzij ze direct relevant zijn, kort elke bullet in die alleen een verantwoordelijkheid beschrijft in plaats van een resultaat, en houd de projectensectie alleen als die iets laat zien wat je werkgeschiedenis nog echt niet dekt.