Een geloofwaardig cv voor een junior developer zonder betaalde werkervaring begint met wat je echt kunt laten zien, niet met een lege ervaringssectie die kunstmatig wordt opgerekt. Persoonlijke projecten, opdrachten uit je studie, een afstudeerproject van een bootcamp of elke echte bijdrage aan een codebase worden de sectie die anders onder ervaring zou vallen, opgebouwd op dezelfde manier als een werkervaring-item: een duidelijke titel, data, de gebruikte stack en een korte beschrijving van wat daardoor veranderde. De opleiding ondersteunt dat, en een korte samenvatting bovenaan geeft duidelijk je huidige niveau aan en het soort functie dat je zoekt, in plaats van het ontbreken van een betaalde baan met vage taal op te poetsen.
Zet projecten op de plek waar normaal ervaring zou staan
Voor een cv van een junior developer zonder betaalde ervaring is een goede structurele wissel om de projectensectie hetzelfde gewicht en dezelfde positie te geven die werkervaring normaal krijgt: eerst kop en korte samenvatting, dan projecten, dan opleiding, dan een vaardighedensectie, en pas daarna alles buitenschools. Recruiters en wervende managers scannen doorgaans snel van boven naar beneden, dus het sterkste, meest functierelevante materiaal hoort vooraan, en voor iemand wiens sterkste troef een portfolio van zelfgebouwde dingen is, zijn dat projecten en niet een stage of bijbaan die niets met ontwikkeling te maken heeft. Twee of drie projecten, gekozen op relevantie voor de gewenste functie in plaats van op hoe recent ze zijn gebouwd, lezen beter dan vijf of zes die erin gepropt zijn. Een project voor een studieonderdeel, een bootcamp-afstudeerproject en een persoonlijke tool mogen hier allemaal staan, zolang elk dezelfde behandeling krijgt: een naam, een korte beschrijving, de stack, en wat het doet, niet alleen een lijst met vaknamen.
Schrijf elk project-item als een baan, niet als een hobby
Elk project-item werkt het best met dezelfde velden als een werkervaring-item: een titel, een periode, de gebruikte technologieën, en een tot drie regels die beschrijven wat het project doet, welk deel je zelf hebt gebouwd als het groepswerk was, en welke verandering of welk resultaat daaruit volgde. Het noemen van de specifieke stack, een taal, een framework, een database, een deploymentplatform, telt hier zwaarder mee dan bij een werkervaring-item, omdat het vaak het duidelijkste bewijs is dat een lezer heeft van wat je daadwerkelijk kunt. Als een project samen met anderen is gebouwd, benoem dan specifiek wat jij zelf hebt gedaan in plaats van het project als geheel te beschrijven waardoor jouw bijdrage onduidelijk blijft; een gezamenlijk teamproject dat alleen de gezamenlijke prestatie van de groep noemt, leest vager, niet indrukwekkender. Een project dat nog loopt is het vermelden waard als het al ver genoeg gevorderd is om concreet te beschrijven, maar een project dat nooit verder kwam dan een idee laat je beter helemaal weg, want een cv-item heeft iets concreets nodig om over te zeggen wat er daadwerkelijk gebouwd is.
Een bijdrage aan andermans codebase telt ook mee, en leest vaak geloofwaardiger dan een soloproject omdat het laat zien dat je kunt werken in code die je niet zelf hebt geschreven. Heb je een bug opgelost, een kleine functie toegevoegd of de documentatie van een opensourceproject verbeterd, benoem dan het project, beschrijf de specifieke wijziging in één regel, en vertel wat er nodig was om die gemerged te krijgen, zoals het begrijpen van een bestaande testsuite of voor het eerst een bijdrageproces volgen. Zo'n item, ook al is het klein, laat iets zien wat een soloproject van een weekend niet kan: werken binnen andermans kaders in plaats van je eigen kaders.
Illustratief voorbeeld: een vage projectregel herschreven als item
Ervoor: "Een website gemaakt met wat vrienden voor een schoolproject."
Erna: "Task Tracker, teamproject, studieonderdeel, maart-mei [jaar]. Backend-API gebouwd in Node.js en Express, verantwoordelijk voor authenticatie en taaktoewijzing voor een team van vier; de frontend is gebouwd door twee teamgenoten in React. Gedeployed op een gratis hostingpakket voor de demosessie van het vak."
De herschreven versie behoudt hetzelfde onderliggende feit, een klein teamproject uit een studieonderdeel, maar noemt nu de stack, het specifieke deel dat gebouwd is, de teamgrootte en wat het resultaat was, waardoor de lezer iets concreets heeft om te beoordelen in plaats van één platte zin.
Vaardigheden en opleiding, eerlijk gehouden
Groepeer vaardigheden per categorie, talen, frameworks, tools, cloud, in plaats van in één lange, ongesorteerde regel, vergelijkbaar met hoe een vaardighedensectie gegroepeerd kan worden in CVBuilderKits developer-sjabloon. Beperk de lijst tot dingen waarover je in een sollicitatiegesprek met redelijke diepgang zou kunnen praten; een lange lijst vol tools die je maar één keer in een tutorial hebt aangeraakt, doet meer kwaad dan een kortere, accurate lijst, want een interviewer die doorvraagt over een opgeblazen item merkt het gat snel op. De opleiding blijft staan, met diploma, instelling en verwachte of daadwerkelijke afstudeerdatum, samen met vakken die direct relevant zijn voor de gewenste functie als deze sectie anders wat dun aanvoelt.
Voordat je de eerste versie verstuurt
Zodra de structuur staat, lees je het geheel zoals een recruiter dat zou doen: zegt het eerste project-item genoeg om een tweede blik waard te zijn, en noemt de samenvattingsregel een echt doel in plaats van een generiek. Het loont om de samenvatting ook los te lezen, apart van de rest van het document, en jezelf af te vragen of hij een specifiek soort functie noemt, zoals "junior backend developer" of "frontend developer gericht op React", in plaats van een generieke zin als "gemotiveerde developer op zoek naar kansen" die vrijwel iedereen zou kunnen beschrijven. Een cv schrijven met weinig of geen werkervaring als afgestudeerde behandelt hetzelfde probleem vanuit een breder perspectief als de projectensectie alleen nog niet genoeg gewicht draagt, vooral voor de manier waarop je opleiding en stages presenteert. Als de structuur goed voelt, begin je met bouwen en pas je de formulering aan bij elk nieuw project dat je toevoegt; een cv dat zo is opgebouwd, is makkelijk uit te breiden zodra de eerste betaalde baan er uiteindelijk op komt te staan, omdat de projectensectie gewoon een plekje naar beneden schuift in plaats van helemaal opnieuw opgebouwd te moeten worden.