CV-voorbeeld voor Software Engineer

Een software engineer CV wordt achter elkaar door twee heel verschillende doelgroepen gelezen: eerst een geautomatiseerde CV-parser, dan een senior engineer of technische recruiter. Allebei willen ze heel andere signalen van dezelfde pagina. De parser wil exacte trefwoordovereenkomsten met de vacaturetekst — namen van talen, namen van frameworks, de juiste functietitels in het juiste format. De mens wil bewijs: de scope van wat je daadwerkelijk hebt gebouwd, technische diepgang op het niveau dat de rol vereist, en resultaten die aantonen dat jouw werk ertoe deed. Dit voorbeeld behandelt de structuur, de vaardigheidssectie, de ervaringsbullets, de projectensectie en de kleine details die een software engineer CV dat interviews oplevert onderscheiden van een cv dat eruit gefilterd wordt. Alles is aanpasbaar in de Cvida-builder; gebruik het als startpunt en stem het af op jouw stack en senioriteit.

Waarom een software engineer CV anders is dan een standaard CV

Begin bij de verschillen, want die verklaren elke keuze die volgt. Werving in software heeft zijn eigen conventies:

  • Technische specificiteit is het hele spel: 'web developer' is een label, 'TypeScript / React / Node / PostgreSQL' is een echte CV-match die de parser kan scoren
  • Projecten tellen net zo zwaar als banen: een sterke open-source bijdrage of een echt live side-project wordt door senior beoordelaars behandeld als werkervaring
  • Stack telt meer dan titel: 'Senior Engineer bij een klein bedrijf dat je niet kent' wordt beoordeeld op de gebruikte stack en de schaal waarop geleverd is, niet op de titel
  • Kwantificering is technisch, niet commercieel: latency verlaagd, requests per seconde verwerkt, MTTR verbeterd, deployfrequentie, testdekking — niet 'omzet verhoogd'
  • ATS-trefwoordmatching is keihard in tech: honderden sollicitaties per rol betekenen dat een recruiter letterlijk scant op de exacte frameworks uit de vacature

Behandel je CV als een technisch document. Dezelfde precisie die je in een system design doc zou gebruiken geldt hier ook: noem de juiste primitieven, laat zien op welke schaal je opereerde, bewijs het met meetbare resultaten.

De CV-structuur die werkt voor engineering-rollen

De meeste software engineer CVs werken het best in deze volgorde — zo plaats je het technische signaal precies waar beoordelaars als eerste kijken:

  • Header: naam, functietitel, locatie, e-mail, GitHub-URL, LinkedIn-URL, portfolio/website-URL — elk link aanklikbaar in de PDF
  • Samenvatting (3–4 regels): jaren ervaring, primaire stack, één of twee domeinspecialisaties, het type rol dat je zoekt
  • Vaardigheden: technische skills gegroepeerd (talen, frameworks, infrastructuur, tools) — in 5 seconden te scannen
  • Ervaring: functies in omgekeerd chronologische volgorde, elk met 3–6 bullets gericht op wat je hebt opgeleverd en de impact
  • Projecten (vooral voor juniors en mid-level): 2–4 persoonlijke of open-source projecten met techstack en resultaat
  • Opleiding: diploma + universiteit + jaar — kort, tenzij je een recente afgestudeerde bent met relevante vakken
  • Optioneel: certificeringen (AWS, Kubernetes, enz.) en gesproken talen indien relevant

Houd het op 1 pagina bij minder dan 5 jaar ervaring, 2 pagina's daarboven. Senior staff/principal engineers met aanzienlijke scope verdienen de tweede pagina; de rest kan één pagina beschouwen als de discipline die je dwingt de sterkste signalen te kiezen.

De basisprincipes van CV-structuur en -lengte waar dit voorbeeld op voortbouwt

De samenvatting: techstack eerst, resultaten daarna

Drie of vier regels, bovenaan de pagina. Dit is het meest gelezen onderdeel na je naam. Het moet antwoord geven op: wie je bent, wat je oplevert, wat voor rol er als volgende past:

  • Regel 1: jaren ervaring + primaire specialisatie. Voorbeeld: 'Backend engineer met 6 jaar ervaring in het bouwen van gedistribueerde Go-services op AWS.'
  • Regel 2: de schaal waarop je hebt geopereerd. Voorbeeld: 'Verantwoordelijk voor services die 50k requests/seconde verwerken; leidde incident response in een platform-team van 12 engineers.'
  • Regel 3: signaal van technische breedte. Voorbeeld: 'Sterk in Go, Kafka, Postgres; vertrouwd met TypeScript en Python voor aangrenzend werk.'
  • Regel 4 (optioneel): wat je als volgende zoekt. Voorbeeld: 'Op zoek naar senior- of staff-rollen bij het bouwen van platform-infrastructuur op consumer-schaal.'
  • Wat je weglaat: 'gepassioneerd' / 'teamspeler' / 'sterk gemotiveerd' — dat zijn opvullers die tegen je werken. De technische details doen het overtuigen

Een samenvatting die een echte stack, een echte schaal en een echte volgende stap noemt, wint het altijd van een versie vol bijvoeglijke naamwoorden. Als je geen specifieke stack kunt noemen waarvan je eigenaar zou zijn, is de samenvatting niet klaar — dat gat komt in het interview toch naar boven.

De vaardigheidssectie: dieptesignalen, geen muur van buzzwords

Groepeer je technische vaardigheden per type zodat een beoordelaar ze in seconden kan scannen. Orden binnen elke groep op echte diepgang — meest vloeiend eerst:

  • Talen: Go, TypeScript, Python, Rust (in volgorde van vloeiendheid)
  • Frameworks: React, Next.js, Node/Express, FastAPI, gRPC
  • Data / infrastructuur: PostgreSQL, Redis, Kafka, ElasticSearch, Kubernetes, Terraform, AWS (EC2, S3, RDS, Lambda)
  • Werkwijzen: gedistribueerde systeemontwerpen, observability (Prometheus, Grafana, OpenTelemetry), CI/CD (GitHub Actions, ArgoCD), incident response
  • Wat je weglaat: tools die je vijf jaar geleden één keer hebt gebruikt, talen die je alleen in een tutorial hebt aangeraakt, 'Microsoft Word' (serieus — recruiters draaien hun ogen)

Wees eerlijk over je diepgang: als je het vermeldt, wordt je ernaar gevraagd. Een korte, accurate vaardigheidssectie wint het van een lange vol valse signalen — betrapt worden op liegen over Kafka-ervaring in het technische screen kost je het aanbod.

Hoe je een geloofwaardige, specifieke vaardigheidssectie bouwt die aansluit op de rol

Ervaringsbullets: opgeleverd + schaal + impact, elke regel

De sterkste engineering-bullets volgen een strak patroon: werkwoord → wat je hebt gebouwd → de schaal of impact in cijfers. Vergelijk:

  • Zwak: 'Werkte aan het betalingsverwerkingssysteem' — geen stack, geen schaal, geen resultaat, geen eigenaarschap
  • Sterk: 'Ontworpen en opgeleverd: een gedistribueerde Go-betalingsservice die 12k transacties/seconde verwerkt met 99,99% beschikbaarheid in 3 AWS-regio's'
  • Sterk: 'p99 API-latency teruggebracht van 480ms naar 90ms door in-memory aggregatie te vervangen door een Redis-backed gematerialiseerde view; uitgerold achter feature flag over 6 weken'
  • Sterk: 'Migratie van het team van een Rails-monoliet naar 4 Go-services geleid; deploytijd teruggebracht van 35 naar 6 minuten en incident MTTR van ~2u naar 28 minuten'
  • Sterk: 'Intern feature-flag platform gebouwd dat nu door 40 engineers in 6 teams wordt gebruikt; SDK's geïntegreerd voor Go, TypeScript en Python'
  • Patroon om toe te passen: begin elke bullet met een werkwoord (ontworpen, opgeleverd, geleid, geschaald, verantwoordelijk voor, gemigreerd, geautomatiseerd), noem de technologie, noem de schaal of het voor/na

De cijfers hoeven niet indrukwekkend te zijn — ze moeten echt en specifiek zijn. '200 requests/seconde verwerkt bij een kleine e-commerce checkout' is een sterke bullet voor een mid-level engineer; eerlijkheid over schaal is overtuigender dan vage impactclaims.

Hoe je je werk kwantificeert op de manier waarop engineering-hiringpanels het scoren

De projectensectie: cruciaal voor juniors, nuttig voor iedereen

Een sterke projectensectie beantwoordt de vraag die beoordelaars altijd hebben over kandidaten wier dagelijkse werk niet hun volledige bereik toont: wat kun je bouwen als niemand je tegenhoudt? Ze weegt zwaar voor early-career engineers en mensen die van richting veranderen:

  • Kies 2–4 projecten, elk met: naam, één beschrijvingsregel, techstack, GitHub- of live-URL, en 1–2 bullets over wat interessant is aan hoe je het hebt gebouwd
  • Open-source bijdragen tellen: 'Kafka-consumer herschreven voor {project} (gemerged, 30k wekelijkse downloads)' is een serieus signaal
  • Side-projects met echte gebruikers zijn goud: '{tool} gebouwd: een CLI voor X gebruikt door ~200 developers; geschreven in Rust, verpakt via Homebrew'
  • Cursus/bootcamp-projecten zijn het zwakst — voeg ze alleen toe als je niets anders hebt en begin met wat er technisch niet vanzelfsprekend aan was
  • Als je 5+ jaar sterke werkervaring hebt, wordt deze sectie optioneel; vervang door 'Geselecteerde open-source bijdragen' als je die hebt

Zorg dat elke projectlink werkt. Een beoordelaar die op de GitHub-URL klikt en op een echte, recent actieve repo belandt met een nette README is half overtuigd vóórdat ze je bullets lezen — zet het signaal met één klik voor hen.

Opleiding + certificeringen: houd het kort

Voor software engineers verdient deze sectie zijn ruimte alleen als het een specifiek signaal toevoegt:

  • Als je een diploma hebt, vermeld het: type, richting, universiteit, jaar. Één regel. Laat GPA weg tenzij je een recente afgestudeerde bent met een sterk cijfer
  • Recente afgestudeerden (0–2 jaar): voeg relevante vakken of afstudeerprojecten toe, maar alleen die aansluiten op de gewenste rol
  • Bootcamp-afgestudeerden: noem de bootcamp + het jaar; zet de nadruk op projecten en productiecode die je sindsdien hebt opgeleverd, niet op het curriculum
  • Zelfstudie: sla de opleidingssectie volledig over; laat de projectensectie en werkervaring het werk doen
  • Certificeringen die de moeite waard zijn: AWS Solutions Architect / Associate, GCP Professional Cloud Architect, CKA (Certified Kubernetes Administrator). Laat 'Codecademy voltooid' weg — recruiters tellen het niet mee

Opleiding telt steeds minder naarmate je verder van je afstuderen bent. Rond jaar 5 maakt een sterke projecten- en ervaringsectie de opleidingsregel vrijwel onzichtbaar — precies wat je wilt. Het interview gaat over je code, niet over je diploma.

ATS-optimalisatie: match de vacature exact

Zelfs op senior niveau wordt je CV geparsed voordat een mens het ziet. ATS-scoring in engineering is ongebruikelijk letterlijk als het om technologienamen gaat:

  • Spiegel de exacte frameworknamen uit de vacature. Als de vacature 'React.js' zegt, schrijf dan 'React.js' (niet alleen 'React'); als er 'Node.js' staat, schrijf dan 'Node.js'
  • Schrijf zowel de afkorting als de volledige naam uit waar die verschillen: 'Kubernetes (K8s)', 'Continuous Integration (CI/CD)' — dekt beide trefwoordvarianten
  • Houd het format simpel: standaardlettertypen, geen tweekolomslay-out, geen afbeeldingen met tekst, geen fraaie sectieverdelers. ATS-parsers verknoeien alles wat visueel slim is
  • Sla op als PDF tenzij de vacature Word vraagt — de lay-out overleeft de overdracht betrouwbaarder
  • Stop geen trefwoorden in een verborgen 'skills'-regel in witte tekst. Moderne ATS-systemen markeren dit en recruiters lachen erom — en het technische screen pikt de leugen toch op

De eenvoudigste test: kun je je CV openen in een teksteditor en loopt het van boven naar beneden in een logische volgorde? Als ja, doet de parser dat ook. Als je vaardigheden in het midden van je opleidingsregel eindigen, vecht de opmaak tegen de parser.

Het volledige ATS-draaiboek voor parse-veilige CV-opmaak

Veelgemaakte fouten die goede engineers eruit filteren

Zelfs technisch sterke engineers verliezen interviews door CV-fouten die snel te herstellen zijn:

  • Elke taal vermelden die je ooit hebt aangeraakt: dat verwatert de echte signalen en lokt interviewvragen uit waar je op vastloopt. Vermeld alleen wat je vol vertrouwen kunt verdedigen in een interview, niet meer
  • Samenvattingen vol buzzwords zonder stack: 'gepassioneerde full-stack engineer met sterke communicatievaardigheden' zegt de lezer niets. Noem een stack en een schaal
  • Geen links: een software engineer CV zonder GitHub-URL of portfolio is verdacht — beoordelaars willen code zien. Voeg de URL toe ook als je GitHub bescheiden is
  • Bullets als tekstblok: bullets langer dan twee regels verliezen de scanner. Houd ze strak: actie + technologie + resultaat
  • Verouderde stacksignalen: 'jQuery' laten staan in je talenlijst terwijl je al 5 jaar TypeScript schrijft, signaleert dat je CV lang niet herschreven is — en dat je dat zelf misschien ook niet bent

Doe de recruitertest: kan een drukke beoordelaar in 30 seconden zien wat je bouwt, op welke schaal en voor welke rollen je geschikt bent? Als ja, levert dit CV je de screens op. Zo niet, zijn de fixes bijna altijd hetzelfde — strakkere bullets, stack benoemd, minder bijvoeglijke naamwoorden, werkende links.

De volledige gids voor het afstemmen van een CV op tech-rollen — stack-mapping en senioriteitssignalen

Klaar wanneer jij dat bent

Je hebt de kennis. Bouw nu het CV.

Neem wat je net hebt gelezen en maak er een CV van dat echt antwoorden krijgt. Kies een sjabloon, begin met typen, en wij bewaren je werk onderweg.