Een sollicitatie als frontend developer vraagt om een duidelijk verhaal over je werk én een leesbare opmaak. Dit fictieve voorbeeld richt zich op hoe je interfacekeuzes uitlegt. Werk, opleiding en projecten staan apart, zodat een beoordelaar je bijdrage en omvang kan herkennen. Vergelijk het voorbeeld met je eigen achtergrond; voeg geen taken, tools of kwalificaties toe die je niet kunt onderbouwen.
Voorbeeld-cv (fictief)
Dit voorbeeld is fictief; de namen van personen en organisaties zijn niet echt.
Maak een cv met dit sjabloon ↗ Downloaden als Word-sjabloon (.docx) · Gratis Word-cv-sjablonen
Zo schrijf je dit cv
Leg interfacekeuzes uit
Koppel de bibliotheken die je gebruikt aan het gebruikersprobleem dat je oplost. Beschrijf je verantwoordelijkheid voor formuliervalidatie, toetsenbordtoegang of responsief gedrag. Noem je prestatiewinst, wees dan klaar om het meetinstrument, de testomstandigheden en de vergeleken versies toe te lichten.
Onderbouw toegankelijkheid met details
„Toegankelijke interfaces” zegt weinig. Noem wat je echt deed: de tabvolgorde in een formulier, zichtbare focusstijlen, labels gekoppeld aan invoervelden, foutmeldingen die hulptechnologie voorleest. Vermeld welke controles je uitvoerde, zoals geautomatiseerde audits of handmatig doorlopen met alleen het toetsenbord, en wees eerlijk over wat je niet hebt getest.
Behandel prestatieclaims als bewijs, niet als versiering
Noem je snellere laadtijden of kleinere bundels, ken dan de tool, de pagina, de netwerkomstandigheden en de versies van vóór en na. Een beoordelaar kan ernaar vragen. Een bescheiden, goed uitgelegde ingreep, zoals lazy loading van afbeeldingen of het splitsen van een route, is geloofwaardiger dan de vage claim dat je alles hebt geoptimaliseerd.
Maak je GitHub of portfolio makkelijk te beoordelen
Link twee of drie projecten die je diepgaand kunt toelichten. Pin ze, schrijf een README met een schermafbeelding, installatiestappen en je rol, en haal afgebroken experimenten weg. Een beoordelaar moet binnen een minuut snappen wat er is gebouwd, welk framework is gebruikt en wat jij zelf hebt bijgedragen.
Houd de vaardighedenlijst eerlijk en gestructureerd
Groepeer vaardigheden naar gebruik: talen, frameworks, testen, tooling. Noem versies of context alleen als ze ertoe doen, zoals TypeScript met React in een productie-app. Zet geen bibliotheken op de lijst die je één keer in een tutorial hebt aangeraakt; wees bereid elk onderdeel in een gesprek toe te lichten.
Laat de samenwerking met design en backend zien
Frontendwerk hangt van anderen af. Beschrijf hoe je de overdracht van het ontwerp, responsieve breekpunten, API-afspraken of laad- en foutstatussen met backendcollega’s aanpakte. Eén concrete zin over hoe je een verschil tussen ontwerp en echte data oploste, toont meer volwassenheid dan een lange lijst frameworks.
Voorbeeldzinnen om je werk te beschrijven
Pas ze aan op je eigen echte werk; schrijf nooit iets op wat je niet hebt gedaan.
- Toetsenbordnavigatie en foutmeldingen in formulieren verbeterd
- Gedeelde React-componenten gebouwd voor terugkerende schermen
- Laad- en lege toestanden gemaakt voor API-antwoorden
- Het gedrag van componenten gecontroleerd met unittests
- Breekpunten voor mobiel besproken met het designteam
- Toegankelijkheidsproblemen gedocumenteerd tijdens code review
Ideeën voor vaardigheden
Kies alleen wat voor jou klopt.
- React
- TypeScript
- JavaScript
- HTML
- CSS
- Git
- Vitest
- Toegankelijkheid
- REST-API’s
- Code review
Veelgemaakte fouten
- Elk framework opsommen dat je ooit hebt geopend, in plaats van de paar die je in een echt project vol vertrouwen gebruikt.
- „Pixel-perfect” of „volledig toegankelijke” interfaces claimen zonder te zeggen hoe je dat controleerde of aan welke richtlijnen je testte.
- Een GitHub-profiel linken vol lege forks, onafgemaakte tutorials en repositories zonder README.
- Taken beschrijven als „werkte aan de UI” zonder het onderdeel, de flow of het gebruikersprobleem te noemen.
- Vertrouwelijke code van je werkgever of schermafbeeldingen van interne tools als portfoliomateriaal publiceren.
Veelgestelde vragen
Hoe gebruik ik een GitHub-link?
Kies een paar onderhouden projecten. Zet installatiestappen, schermafbeeldingen, je bijdrage en bekende beperkingen in de README. Publiceer geen vertrouwelijke code van je werkgever.
Moet ik een link naar een live demo toevoegen?
Ja, als die werkt en stabiel is. Een gepubliceerde demo met een korte toelichting op wat hij laat zien helpt. Test hem op mobiel en in een tweede browser voordat je hem verstuurt en zorg dat er geen privégegevens of kapotte pagina’s zichtbaar zijn.
Hoe toon ik toegankelijkheidsvaardigheden zonder certificaat?
Beschrijf concreet werk: toetsenbordondersteuning, labels, contrastverbeteringen, semantische opmaak of controles met een schermlezer. Link een project waarin dit zichtbaar is. Een certificaat kan helpen, maar concrete voorbeelden die je kunt uitleggen overtuigen meestal meer.
Hoe zet een junior frontend developer het cv op?
Begin met een korte samenvatting, daarna projecten met links, dan vaardigheden en opleiding. Beschrijf elk project aan de hand van het probleem, je bijdrage en de gebruikte tools. Noem stages of open-sourcebijdragen alleen als je precies kunt uitleggen wat je hebt aangepast.
Leest een ATS mijn lijst met technologieën goed?
Gebruik gewone tekst en standaardnamen zoals JavaScript, TypeScript en React in plaats van pictogrammen of vaardigheidsbalken. Zet ze in een duidelijke vaardighedensectie en noem de belangrijkste tools ook in je ervaringsregels, zodat zowel software als mensen het kunnen volgen.
Gerelateerde gidsen
← Alle cv-voorbeelden