Hoe schrijf je een CV voor een tech baan (software engineers, ontwikkelaars, data)

Een tech-CV wordt anders gelezen — wat verandert er

Voor de tactiek komt het structurele verschil. Tech-CV's worden door een andere bril beoordeeld dan corporate CV's, en dat verschil vormt elke sectie:

• De engineering hiring manager leest het CV naast (of vlak na) een snelle blik op je GitHub, je persoonlijke site als je die hebt, en je LinkedIn. Het CV is niet het enige signaal; het is één signaal in een beoordeling uit meerdere bronnen
• De technische vaardighedensectie wordt zowel door recruiters als door engineers als eerste gelezen, maar ze zoeken er verschillende dingen in. Recruiters scannen op zoekwoordmatches met de vacature; engineers kijken of de diepte en breedte bij het seniority-niveau van de functie passen
• Projecten wegen op junior- en midniveau vaak zwaarder dan de werkgeschiedenis. Een zelfgestuurd project dat echt iets heeft opgeleverd, signaleert initiatief en uitvoeringskracht op een manier die een stage of eerste baan niet kan
• De werkgeschiedenis wordt gelezen op omvang, impact en de seniority van de context — niet alleen op bedrijfsnamen. Werken in het auth-team bij een startup van 50 mensen is iets anders dan in het auth-team bij een enterprise van 50.000; het CV moet die omvang leesbaar maken
• De GitHub-aanwezigheid wordt gecheckt. Een kandidaat met een actief GitHub-profiel (echte commits, meerdere repositories, een contributiegrafiek met recente activiteit) wordt als een geloofwaardiger engineer behandeld dan iemand zonder — zelfs als de onderliggende vaardigheid identiek is
• Het CV blijft één pagina tot dat echt niet meer kan. Twee pagina's zijn acceptabel voor engineers met 8+ jaar ervaring, maar de tweede pagina moet echte inhoud bevatten, geen vulling
• Opleiding telt op juniorniveau (vooral voor pas afgestudeerden), wordt minder belangrijk op midniveau en wordt vrijwel irrelevant op senior+ niveau. Pas de prominentie daarop aan
• Certificeringen tellen bij specifieke cloudfuncties (AWS, GCP, Azure) en specifieke specialismen (security, netwerken), maar zijn voor algemene software-engineering-functies grotendeels irrelevant

De rest van deze gids is opgebouwd rond deze structurele feiten. Elke sectie behandelt wat je schrijft, hoe je het ordent, wat je benadrukt en wat je schrapt — specifiek afgestemd op engineering-functies in plaats van generieke corporate functies.

De technische vaardighedensectie — hoe je die ordent

De technische vaardighedensectie is de meest gescande sectie van een tech-CV. Zowel recruiters als engineers kijken er als eerste naar. Hoe die geordend is, bepaalt of hij competentie of ruis uitstraalt:

• Orden op categorie, niet als één platte lijst. Talen, frameworks, databases, infrastructuur/cloud, tools, methodieken — elk als een eigen groep. Een muur van 40 technologieën gescheiden door komma's leest als een zoekwoordendump; dezelfde 40 geordend op categorie leest als een gestructureerde competentiekaart
• Vermeld technologieën waarover je vol vertrouwen kunt praten in een technisch gesprek. De interviewer kiest uit deze sectie om technische vragen op te bouwen; als je Rust vermeldt omdat je het drie jaar geleden in een tutorial gebruikte, zak je voor het gesprek
• Orden elke categorie op werkelijke vaardigheid, niet op wat je zou willen dat waar was. Ben je het sterkst in Python en het zwakst in Go, zet Python dan eerst — de volgorde wordt als een vertrouwenssignaal gelezen
• Vermijd niveaulabels (Beginner / Gevorderd / Expert / 8 op 10). Ze zijn subjectief, vaak onnauwkeurig en leiden tot ongemakkelijke vragen in gesprekken. Vermeld een technologie omdat je er vol vertrouwen over kunt praten, of laat hem weg
• Sluit aan op het technische vocabulaire in de vacature. Staat er „React, Node.js, PostgreSQL, AWS”, gebruik dan precies die termen — niet „JavaScript-frameworks, webservers, relationele databases, cloudplatforms”. De ATS-zoekwoordmatching is letterlijk
• Vermeld versies of specifieke dialecten waar relevant: „Python 3.x”, „PostgreSQL 14+”, „React 18 met hooks”. Specificiteit signaleert diepte
• Sla de basis over die bij iedereen wordt verondersteld. „HTML, CSS, Git, command line” op het CV van een senior engineer is vulling die echt signaal verdringt
• Heb je gespecialiseerde expertise (compilers, gedistribueerde systemen, ML-infrastructuur, realtime systemen), maak dan een aparte regel „specialismen” of „domeinen” die dat naar voren haalt. Op seniorniveau is specialisatie waardevoller dan breedte

De test voor de technische vaardighedensectie: een engineer die hem leest, zou moeten kunnen voorspellen hoe je dagelijkse werk er werkelijk uitzag. Is de sectie een generieke woordenwolk die bij elke kandidaat past, dan faalt hij. Is hij geordend, gekalibreerd en eerlijk, dan doet hij het grootste deel van het werk van de technische screening voordat die screening überhaupt plaatsvindt.

Projecten tonen — wanneer projecten zwaarder wegen dan banen

Tech-CV's bevatten naast Werkervaring vaak een sectie Projecten. Voor sommige kandidaten is de sectie Projecten het sterkste deel van het CV. Wanneer voeg je er een toe en hoe gebruik je hem:

• Junior engineers en pas afgestudeerden: een sectie Projecten is essentieel. Met een beperkte werkgeschiedenis zijn projecten het belangrijkste bewijs dat je code kunt opleveren. Plaats deze sectie boven of direct na Opleiding
• Carrièreswitchers die de engineering instappen: een sectie Projecten is essentieel. Het is de brug tussen je eerdere ervaring en je engineering-vaardigheid — en het enige bewijs dat je daadwerkelijk iets hebt gebouwd
• Midlevel engineers met een sterke werkgeschiedenis: een sectie Projecten is optioneel. Voeg hem toe als je nevenprojecten hebt die vaardigheden tonen die je werkgeschiedenis niet laat zien (open source, ML-experimenten, een gepubliceerde library, een populaire Chrome-extensie)
• Senior engineers en hoger: een sectie Projecten is meestal overbodig. De werkgeschiedenis moet op dit niveau het gewicht dragen. Uitzondering: noemenswaardig maintainerschap van open source, bekend gepubliceerd werk of substantiële bijdragen aan de community
• Elk projectitem moet hebben: de projectnaam (met link naar de repo of de live URL), een beschrijving van één regel van wat het doet, de gebruikte tech-stack, en 1-2 bullets over wat er niet-triviaal was aan het bouwen ervan
• Liever 2-4 sterke projecten dan 8 zwakke. Een todo-app die een tutorial volgt helpt niet; een project dat een echt probleem oploste en waar je diepgaand over kunt praten wel
• Is het project een kloon of een stap-voor-stap-tutorial, vermeld het dan niet als project. Zet het hoogstens neer als „leeroefening”, of laat het weg
• Bij gebruikersgerichte projecten wegen werkende links zwaarder dan repolinks. Een uitgerolde site waar de hiring manager doorheen kan klikken is veel overtuigender dan een repo die hij moet klonen
• Had het project medewerkers, noem ze dan en je eigen specifieke rol. „Bouwde de backend-API en de databaselaag voor een projectteam van 4” is eerlijk en specifiek; jezelf het alleenauteurschap van een teamproject toeschrijven is precies het soort claim dat in het gesprek wordt ontmaskerd

Het sterkste tech-CV op junior-/midniveau heeft vaak 2-3 stevige projecten waar de kandidaat diepgaand over kan praten, met live demo's. Dat weegt vaak zwaarder dan een langere maar minder onderscheidende werkgeschiedenis. Bouw de projecten bewust zodat ze het sterkste bewijs van je CV worden.

GitHub, portfolio en aantoonbaar werk

De links die je op je tech-CV zet, worden gelezen als bewijs dat je een praktiserend engineer bent en geen diplomahouder. Welke links neem je op en hoe presenteer je ze:

• GitHub: opnemen voor vrijwel alle engineering-functies. Zorg dat het profiel waarnaar je linkt echt is (recente commits, meerdere repos, een ingevulde profiel-readme). Een lege of verlaten GitHub gelinkt vanaf je CV is erger dan geen link
• Persoonlijke site: opnemen als je er een hebt en die actueel is. De site hoeft niet chic te zijn; een eenvoudig portfolio met links naar projecten, een korte bio en contactgegevens is genoeg. Een kapotte site of een site uit 2019 is erger dan geen site
• LinkedIn: opnemen. Ook al vind je LinkedIn vooral ruis, recruiters checken het en een leeg profiel signaleert een gebrek aan professionaliteit
• Stack Overflow-profiel: alleen opnemen als je een betekenisvolle reputatie en kwalitatief goede antwoorden hebt. Een profiel met 50 reputatie signaleert niets; een profiel met 50.000 reputatie signaleert echte expertise
• Persoonlijke blog of technisch schrijven: opnemen als je regelmatig technische content schrijft. Engineering-blogposts tonen communicatievaardigheid, technische diepgang en een gewoonte van reflectie — allemaal signalen die hiring managers waarderen
• Conferentietalks, podcasts, video-optredens: opnemen als je die hebt. Ze werken als externe validatie dat je technische ideeën kunt overbrengen
• Maak alle links klikbaar in de PDF (Word en Google Docs ondersteunen dit beide via „Hyperlink invoegen”). Recruiters klikken; kapotte of niet-klikbare links kosten je de doorklik
• Maak schoon schip voordat je linkt. Voordat je je GitHub-link toevoegt, kijk dan met een frisse blik naar je profiel. Pin je beste 4-6 repos vast. Zorg dat de repo-README's geschreven zijn. Verwijder of archiveer repositories die alleen als halve tutorials bestaan. De hiring manager vormt binnen 30 seconden een indruk van je profiel — zorg dat het de indruk is die je wilt

Elke link op je tech-CV is een belofte — erop klikken onthult meer bewijs van je engineering-vaardigheid. Onthult het klikken minder dan het CV suggereerde, dan verzwakt je kandidatuur. De links zijn alleen netto-positief als het onderliggende materiaal waarmaakt wat het CV impliceert.

ATS voor tech-functies — de zoekwoordmatching die telt

Het meeste tech-werving bij grote bedrijven loopt nog steeds via ATS-systemen die op zoekwoorden filteren. De dynamiek van ATS-matching voor engineering-functies:

• ATS voor tech-functies doet vaak een letterlijke zoekwoordmatch tegen de vacature. Staat er „React” en zegt je CV „React.js”, dan matchen sommige systemen dat niet. Gebruik waar mogelijk de exacte spelling uit de vacature
• Vermeld technologieën in meerdere secties, niet alleen in de sectie Vaardigheden. Een senior engineer die bij drie bedrijven Kubernetes in productie gebruikte, zou „Kubernetes” in die drie functiebeschrijvingen plus in de sectie Vaardigheden moeten hebben — het matching-algoritme weegt het aantal voorkomens
• Specifieke frameworks en tools tellen zwaarder dan algemene categorieën. „React, Vue, Angular” is beter dan „JavaScript-frameworks”. „PostgreSQL, MongoDB, Redis” is beter dan „databases”
• Afkortingen en voluit: neem beide op. „Machine Learning (ML)” dekt zowel „ML” als „machine learning”. „Continuous Integration (CI/CD)” doet hetzelfde
• Veelvoorkomende varianten: „Node.js”, „Nodejs” en „Node” zijn dezelfde technologie, maar ATS-systemen weten dat misschien niet. Staat er „Node.js”, match dan precies die vorm
• Branchespecifieke certificeringen en normen: opnemen indien relevant. „PCI DSS”, „HIPAA”, „SOC 2”, „AVG” als je ermee hebt gewerkt. „Agile”, „Scrum”, „Kanban” als je die processen hebt geleid
• Vermijd zoekwoord-stuffing dat de leesbaarheid breekt. Na de ATS leest een mens het CV; ziet die menselijke lezer een muur van technologienamen zonder context, dan faalt de kandidatuur bij de menselijke screening, ook al kwam ze door de ATS-screening
• Stem af per sollicitatie. De zoekwoordenlijst die een CV door de ATS van Google loodst, verschilt van de lijst die het door de Greenhouse van een startup loodst. Stem af op de specifieke vacature

ATS-matching is bij de meeste grote bedrijven een noodzakelijke eerste horde voor tech-functies. Behandel het als een letterlijke matching-oefening: sluit aan op het vocabulaire van de vacature, vermeld technologieën in context (in functiebeschrijvingen, niet alleen in de lijst Vaardigheden) en ga ervan uit dat de matching dom is. Voorbij de ATS neemt de menselijke lezer het over en telt inhoud zwaarder dan zoekwoorddichtheid.

Engineering-impact kwantificeren

Tech-CV's lijden vaak aan hetzelfde probleem van vage claims als corporate CV's: „ontwikkelde features”, „verbeterde de performance”, „werkte aan het platform”. Specifieke, gekwantificeerde impact is wat een sterk tech-CV onderscheidt van een generiek exemplaar:

• Performance: „verlaagde de p99-latency van de API van 850 ms naar 120 ms” verslaat „verbeterde de API-performance”. Concrete getallen zijn geloofwaardig; vage claims niet
• Schaal: „verwerkte 50K req/s op de piek” of „verwerkte 2 miljard events/dag” verankert het werk in echte schaal. Zonder getallen moet de lezer het zich voorstellen; met getallen begrijpt hij het
• Kosten: „verlaagde de AWS-infrastructuurkosten met $180K/jaar via database-optimalisatie en het juist dimensioneren van resources” is de taal die aanslaat bij engineering-leiderschap. Kostenreductie is vaak de metric met de hoogste hefboomwerking
• Betrouwbaarheid: „verlaagde het aantal productie-incidenten van 8/maand naar 1/maand” of „verbeterde de SLO van de service van 99,5% naar 99,95%” zijn concrete betrouwbaarheidsmetrics
• Team en omvang: „tech lead van een team van 6 engineers” of „verantwoordelijk voor het end-to-end ontwerp en de implementatie van de betaaldienst” vertelt de lezer wat de omvang van je verantwoordelijkheid was. Zonder dit kan het werk van alles zijn — van „schreef één feature” tot „ontwierp het hele systeem”
• Oplevering: „leverde 12 productiereleases in 18 maanden zonder grote incidenten” of „leverde het project 3 weken voor de planning op door infrastructuur- en featurewerk te parallelliseren” vertelt een opleververhaal
• Adoptie: „interne library gebruikt door 15+ teams” of „open source-project met 8K GitHub-sterren” kwantificeert de impact van werk dat geen klantgerichte metrics heeft
• Heb je geen concrete getallen, geef dan concrete beschrijvingen. „Migreerde de betaaldienst van een monoliet naar een event-driven architectuur, zonder downtime tijdens de overstap” is concreet, ook zonder getal

Het patroon: elke bullet moet de vraag „en dan?” beantwoorden. Zegt een bullet „ontwikkelde features”, dan is het „en dan” onzichtbaar. Zegt hij „bouwde de checkout-flow die de conversie tijdens het experiment van 6 weken van 2,1% naar 3,2% tilde”, dan ligt het „en dan” er bovenop. Herschrijf generieke bullets tot ze ofwel een getal ofwel een concrete, specifieke uitkomst hebben.

Open source, nevenprojecten, hackathons

Engineering-werving waardeert bijdragen buiten betaald werk als bewijs van oprechte betrokkenheid bij het vak. Hoe pak je dit aan in het CV:

• Bijdragen aan open source: opnemen als ze substantieel zijn. „Maintainer van X (beschrijving, 8K sterren)” is een sterk signaal. „Droeg een bugfix bij aan de populaire library Y” is een gemiddeld signaal. „Diende een PR in bij project Z” is een zwak signaal, tenzij de PR substantieel was
• Vermeld de aard van de bijdrage: maintainer, vaste bijdrager, incidentele bijdrager, eenmalige bijdrager. Het onderscheid doet ertoe en de eerlijke verwoording bouwt geloofwaardigheid op
• Heb je een populaire open source-library of -tool gemaakt, zet die dan voorop in het CV. Een breed gebruikt open source-project is een van de sterkst mogelijke signalen van engineering-vaardigheid
• Nevenprojecten: neem de 2-3 sterkste op in een sectie Projecten. Sla nevenprojecten over die tutorials volgen, half af zijn of alleen als privé-repo bestaan
• Hackathons: alleen opnemen als je een noemenswaardige hebt gewonnen of er hoog bent geëindigd. Een 2e plaats op een grote universiteits- of branchehackathon is het vermelden waard; deelname aan een studentenhackathon niet, tenzij je heel junior bent
• Interne bedrijfsprojecten: tellen meestal niet als „open source”, ook al is er publiek over gesproken. Neem ze in plaats daarvan op onder werkervaring
• Betrokkenheid bij de community: meetup-organisator, conferentiespreker, podcastgast, technisch schrijver — opnemen als ze substantieel zijn. Ze signaleren een engineer die zich met de bredere community bemoeit en niet alleen zijn werk doet
• Wees eerlijk over de omvang. „Droeg bij aan React” kan betekenen „opende één issue dat zonder PR werd gesloten” of „schreef 30 PR's die in productie kwamen”. De CV-claim en het GitHub-bewijs moeten kloppen

De rol van open source en nevenprojecten verschuift met de seniority. Op juniorniveau zijn ze essentieel bewijs dat je een praktiserend engineer bent. Op midniveau onderscheiden ze. Op seniorniveau signaleren ze blijvende betrokkenheid bij het vak buiten de dagelijkse baan. Kalibreer de prominentie op je carrièrefase.

Opleiding en certificeringen — wat ertoe doet

Tech-functies wegen opleiding en certificeringen heel anders dan andere sectoren. Hoe het er nu voor staat:

• Junior engineers (0-2 jaar): opleiding telt. Een diploma informatica of een verwante studie van een bekende instelling weegt mee. Vermeld je opleiding prominent, bovenaan het CV
• Midlevel engineers (3-7 jaar): opleiding telt minder. De werkgeschiedenis is het belangrijkste signaal. Verplaats de opleiding naar de onderkant van het CV, tenzij je een bijzonder opvallend diploma hebt (topuniversiteit, een hogere graad in een relevant vakgebied)
• Senior engineers (8+ jaar): opleiding is voor de meeste functies vrijwel irrelevant. Eén regel onderaan volstaat. De uitzondering zijn functies die academische credentials expliciet waarderen (research engineering, bepaalde ML/AI-functies)
• Bootcamp-afgestudeerden: vermeld het bootcamp. De arbeidsmarkt voor bootcamp-afgestudeerden is volwassen geworden; gerenommeerde bootcamps worden herkend. Combineer met sterke projecten om de kortere leertijd te compenseren
• Zelfgeleerde engineers zonder formele informatica-opleiding: zet projecten en werkgeschiedenis voorop. Vermeld zelfgestuurd leren eerlijk („zelfgeleerd, sinds 2019 gericht op full-stack webdevelopment”). Verzin geen credentials, maar voel je ook niet verplicht er een te vermelden als je ze niet hebt
• AWS/GCP/Azure-certificeringen: tellen bij cloudgerichte functies (DevOps, SRE, cloudarchitect, infrastructuur-engineering). Vermeld het specifieke certificeringsniveau (Associate, Professional enz.)
• Security-certificeringen (CISSP, OSCP, CEH): tellen bij security-functies. Vermeld met de behaaldatum
• Algemene software-certificeringen (Oracle Java, Microsoft .NET): grotendeels genegeerd. Op het CV van een senior engineer zijn ze vulling
• Afgeronde online cursussen (Coursera, Udemy, edX): doorgaans niet vermelden. Ze signaleren dat je een cursus kunt afronden, niet dat je het werk kunt doen. Uitzondering: het afronden van een gespecialiseerd programma (Stanford ML, de deep learning-specialisatie van Andrew Ng) kan een vermelding van één regel rechtvaardigen
• PhD: bovenaan vermelden als die recent en relevant is; verschuif naar beneden met de seniority. Een PhD is een sterk signaal voor onderzoeksgerichte functies en een neutraal signaal (soms licht negatief vanwege de perceptie „te academisch”) voor product-engineering-functies

Het patroon: opleiding is een juniorsignaal dat met de tijd vervaagt. Certificeringen zijn een signaal voor gespecialiseerde functies dat telt wanneer het relevant is en vulling is wanneer het dat niet is. Kalibreer de prominentie van deze secties op waar je in je carrière staat.

Het remote-vriendelijke tech-CV — de nieuwe norm

Een aanzienlijk deel van de engineering-functies is in 2026 remote of hybride. Het CV moet remote-gereedheid signaleren, wat op zichzelf inmiddels een wervingsoverweging is:

• Heb je remote-werkervaring, markeer die dan: „Senior Engineer (remote), Acme Corp, 2022-2025”. Recruiters scannen hierop; remote-ervaring is een positief signaal voor remote-functies
• Locatie: vermeld je huidige stad en land, maar signaleer flexibiliteit waar relevant. „Berlijn, Duitsland (open voor remote, EU-tijdzones)” of „Amsterdam (open voor remote binnen de EU)”. Een vaag „open voor verhuizing” is zwakker dan een concrete beschikbaarheid
• Tijdzone: vermeld die als je op remote-functies in een andere geografie solliciteert. „Tijdzone: CET (UTC+1)” maakt het plannen duidelijker
• Ervaring met communicatietools: in een remote-relevante context signaleert het noemen van ervaring met Slack, Notion, Linear, Figma, pair programming via video en async-first workflows dat je past in een remote engineering-cultuur
• Taal van zelfsturing: „leidde het project end-to-end, van spec tot deployment” signaleert de autonomie die remote werk vereist. „Werkte met het team om X op te leveren” is neutraal; „dreef X zelfstandig van concept naar lancering” is sterker voor remote
• Documentatie en schrijven: licht eventueel technisch schrijfwerk, het opstellen van design docs of bijdragen aan RFC's uit. Remote-teams leunen sterk op schriftelijke communicatie; engineers die goed schrijven, zijn makkelijker remote aan te nemen
• Signalen van overlap in tijdzones: heb je expliciet over tijdzones heen gewerkt (een engineer in de VS met een team in Berlijn, of andersom), noem dat dan. De vaardigheid van asynchroon samenwerken is niet-triviaal
• Signaleer geen rigide „alleen remote” als je openstaat voor op kantoor. De vooringenomenheid bestaat bij sommige bedrijven nog; ben je flexibel, signaleer dan flexibiliteit

Remote-vriendelijkheid is verschoven van een voorkeur van de kandidaat naar een wervingscriterium. Op het CV laten zien dat je remote hebt gewerkt, asynchroon hebt gecommuniceerd en met zelfsturing hebt geopereerd, hoort nu bij de taak van het CV — niet alleen voor volledig remote functies, maar ook voor hybride en zelfs sommige kantoorfuncties waar remote-gereedheid als een kwaliteitssignaal wordt behandeld.

CV's voor junior vs mid vs senior vs staff/principal

De nadruk in een engineering-CV verschuift dramatisch over de carrièrefasen heen. Wat werkt voor een junior-CV laat een staff-CV zinken, en andersom:

De samenvatting voor technische functies

De samenvatting bovenaan een tech-CV is optioneel voor juniorfuncties en wordt vanaf midniveau steeds belangrijker. Hoe schrijf je er een die werk verzet:

• Lengte: 3-5 regels. Lang genoeg om je specialisme te kaderen, kort genoeg dat de lezer het ook echt leest
• Begin met je jaren ervaring en je belangrijkste specialisme: „Backend engineer met 7 jaar ervaring in het ontwerpen van high-scale gedistribueerde systemen, voornamelijk in Go en Python.” Dit is het eerste wat de lezer ziet en het moet het hele CV verankeren
• Volg met een zin over het soort werk dat je goed doet: „Ik richt me op het raakvlak tussen API-ontwerp en infrastructuur, met diepe ervaring in event-driven architecturen en database-internals.”
• Sluit af met wat je zoekt: „Op zoek naar senior+ functies waar ik het ontwerp van een kritiek backend-systeem kan leiden en de komende 2 jaar naar staff-niveau kan doorgroeien.”
• Vermijd generieke kwalificaties: „gepassioneerd”, „resultaatgericht”, „oog voor detail”. Die dragen geen signaal en lezen als vulling
• Vat de rest van het CV niet samen. De samenvatting moet informatie toevoegen die de lezer niet uit het scannen van de rest haalt — specifiek je specialisatiegebied, je carrièrerichting en wat je tot een samenhangende kandidaat maakt
• Stem af per sollicitatie. De samenvatting is de makkelijkste plek om te signaleren dat het CV op deze specifieke functie is gericht. Een samenvatting voor een backend-infrastructuurfunctie bij een databasebedrijf moet anders lezen dan de samenvatting van dezelfde persoon voor een backend-productfunctie bij een SaaS-bedrijf
• Laat de samenvatting helemaal weg als je een junior engineer bent. In die carrièrefase dreigt de samenvatting vulling te worden zonder signaal toe te voegen; laat je werk voor zich spreken

De samenvatting is waardevolle ruimte bovenaan het CV. Goed gebruikt vertelt ze de lezer in 3-5 regels wie je bent als engineer en kadert ze alles wat volgt. Slecht gebruikt (generieke bijvoeglijke naamwoorden, vage ambities) is ze vulling die echt signaal verdringt.

Opmaakkeuzes voor het tech-CV — één pagina vs twee

De vraag één pagina versus twee is voor tech-CV's genuanceerder dan voor andere sectoren. Het kader:

• Eén pagina: junior engineers (0-3 jaar), de meeste midlevel engineers (3-7 jaar) en engineers in markten waar één pagina de culturele norm is (het grootste deel van de Amerikaanse tech-industrie)
• Twee pagina's: senior engineers met substantiële ervaring (8+ jaar), staff-/principal-engineers met aanzienlijke omvang om te communiceren, en engineers in markten waar twee pagina's normaal zijn (het grootste deel van Europa, vooral Duitsland, Frankrijk, het VK)
• Nooit drie pagina's. Past je CV niet op twee pagina's, dan is het probleem redactie, geen ruimte. Kort oudere functies in tot samenvattingen van één regel, schrap details uit functies van vroeger in je loopbaan, snoei minder relevante projecten
• Heb je een langer CV-achtig document (academische stijl, met publicaties, talks, patenten), houd dat dan apart. Het CV is de samenvatting voor de recruiter; het langere document is voor vervolgaanvragen
• Opmaak: één kolom of twee? Eén kolom is veiliger voor ATS. Gebruik je twee kolommen (zijbalk voor vaardigheden/contact, hoofdkolom voor ervaring), test het parsen dan door de PDF vóór indiening door een online cv-parser te halen
• Lettertype: houd je aan standaardlettertypen (Calibri, Helvetica, Arial, Source Sans, Inter). Designerige lettertypen kunnen het ATS-parsen breken. Bodytekst 10-11 pt, koppen 12-14 pt
• Kleur: minimaal. Eén accentkleur voor sectiekoppen is prima; een volledig kleurontwerp is overbodig en kan de ATS breken. De inhoud is het signaal, niet het ontwerp
• Foto: niet in Amerikaanse tech-CV's. In Europese landen waar foto's normaal zijn (Duitsland, Frankrijk), neem een professionele pasfoto op
• Bestandsformaat: PDF. Altijd PDF. Word-documenten verschuiven op andere machines en zien er kapot uit; PDF's renderen consistent. Geef het bestand een consistente naam: „Voornaam-Achternaam-CV.pdf” of „Voornaam-Achternaam-SeniorEngineer-CV.pdf”

Opmaakbeslissingen moeten de inhoud dienen, niet ervan afleiden. Een tech-CV met standaardlettertypen, een eenvoudige structuur en bescheiden kleur is leesbaarder dan een dat eruit probeert te zien als een designportfolio. De uitzondering zijn design-engineering- of front-endfuncties, waar enige visuele verfijning van het CV zelf een relevant signaal is — maar zelfs daar leest terughoudendheid als zelfvertrouwen.

CV, LinkedIn, GitHub en persoonlijke site op elkaar afstemmen

Het tech-CV is één document in een afgestemde online aanwezigheid. Engineering hiring managers bekijken meerdere oppervlakken, en inconsistentie daartussen is een negatief signaal. Het afstemmingsdraaiboek:

• LinkedIn: moet hetzelfde verhaal vertellen als het CV wat betreft functies, data en omvang. De headline mag ambitieuzer zijn („Senior Backend Engineer geïnteresseerd in gedistribueerde systemen en developer tooling”), maar de inhoud moet kloppen. Een LinkedIn die het CV tegenspreekt (andere data, andere titels, andere omvang) vernietigt vertrouwen
• GitHub: moet leven. Recente commits, een ingevulde profiel-readme, 4-6 vastgepinde repositories die je beste werk vertegenwoordigen, schone README's. Een lege GitHub gelinkt vanaf het CV is erger dan geen link. Is je GitHub karig, investeer dan een weekend in het opschonen voordat je het CV verstuurt
• Persoonlijke site: optioneel maar krachtig als die goed is gedaan. Een eenvoudige pagina met een bio van één alinea, projecthighlights, een downloadlink voor het CV en contactgegevens is genoeg. Vermijd Flash, kapotte contactformulieren, dode links en een laatst-bijgewerkt-datum uit 2020
• Consistentie van naam en identiteit: gebruik dezelfde naam en pasfoto over CV, LinkedIn, GitHub en persoonlijke site. Recruiters leggen verbanden; een „Jan de Vries” op het CV die op LinkedIn „Jan-Willem de Vries” heet, creëert wrijving
• E-mailadres: consistent over alle oppervlakken. Gebruik een professioneel e-mailadres (jouwnaam@jouwdomein.nl of voornaam.achternaam@gmail.com), geen studentenmail of een gebruikersnaam uit 2005
• Telefoonnummer, locatie en tijdzone: consistent over de oppervlakken. Tegenstrijdige locatiesignalen ogen als onoplettendheid
• Heb je een portfolio van gepubliceerd werk (technische blogposts, talks, papers), link dan vanaf het CV naar de canonieke bron — je persoonlijke site of één centraal profiel — in plaats van 10 losse links
• Doe een audit voordat je solliciteert. Klik vóór het versturen op elke link op het CV alsof je een recruiter was. Bekijk het LinkedIn-profiel met een frisse blik. Blader door de GitHub. Vind je iets dat het CV tegenspreekt of ondermijnt, herstel het dan voordat je solliciteert

De hiring manager bouwt één indruk van je op uit de afgestemde oppervlakken, niet losse indrukken uit elk afzonderlijk. Het CV dat naar een samenhangende online aanwezigheid verwijst, leest geloofwaardiger dan een met een sterk CV en een zwakke of tegenstrijdige LinkedIn/GitHub. Die dertig minuten opschonen over alle oppervlakken is een van de meest hefboomrijke besteding van tijd in een tech-zoektocht.