De manier om jarenlang engineeringwerk op één pagina te laten passen is niet om elk project te verkleinen tot een onleesbaar fragment. Het is de drie of vier projecten kiezen die de functie waarop je solliciteert het beste ondersteunen, de rest samenvoegen in één regel onderaan, en elk overgebleven project als een compacte regel schrijven in plaats van een alinea. Een pagina die twaalf projecten met evenveel gewicht probeert te laten passen, presenteert er uiteindelijk geen enkel goed; een pagina met vier projecten op volle sterkte, waarbij de rest terloops genoemd wordt, leest als een sterker cv, ook al zegt het technisch gezien minder.
Bepalen welke projecten een plek verdienen
Begin met projecten te rangschikken op basis van hoe goed ze bij de specifieke functie passen, niet op hoe trots je bent op elk project. Een project dat dezelfde technische stack gebruikte als de doelfunctie, een vergelijkbaar probleem oploste, of eigenaarschap over een heel systeem laat zien in plaats van een klein onderdeel ervan, verdient een plek boven een project dat technisch indrukwekkend is maar ver afstaat van wat de functie werkelijk nodig heeft. Recentheid speelt ook mee, al minder dan relevantie: een ouder project dat nauw aansluit bij de doelfunctie wint vaak van een recent project dat dat niet doet. Drie of vier projecten zijn meestal genoeg voor één pagina als er ook werkervaring staat; een cv dat vooral uit projecten bestaat, omdat betaalde ervaring nog beperkt is, kan uitgebreid worden tot vijf of zes voordat de pagina druk begint aan te voelen.
Een veelgemaakte fout is rangschikken op inspanning in plaats van relevantie: een project dat zes maanden aan weekenden kostte, kan aanvoelen alsof het de eerste plek verdient enkel vanwege de geïnvesteerde tijd, ook al sluit een kleiner project van twee weken veel directer aan bij wat de doelfunctie dagelijks werkelijk doet. Inspanning is onzichtbaar voor een lezer die alleen de uiteindelijke regel op de pagina ziet, dus het loont om die bewust opzij te zetten en alleen op basis van fit opnieuw te rangschikken voordat je de definitieve vier projecten kiest.
De kleinere projecten samenvoegen in één regel
Een project dat het niet haalt bij de paar uitgelichte projecten hoeft niet te verdwijnen. Eén regel onderaan de projectensectie, zoiets als "Ook gebouwd: een Slack-notificatiebot, een kleine CLI voor het doorzoeken van logs, en twee interne tooling-scripts", houdt ze zichtbaar zonder ze dezelfde ruimte te geven als de uitgelichte items. Deze regel doet echt werk: het geeft aan dat de uitgelichte projecten bewust gekozen zijn en niet alles zijn wat je ooit hebt gebouwd, en het geeft een lezer die meer wil weten een startpunt om in een gesprek naar te vragen, zonder elk project door dezelfde volledige beschrijving te dwingen.
Een projectregel van één regel schrijven
Een projectregel van één regel moet nog steeds antwoord geven op wat het is, waarmee het gebouwd is, en wat eruit voortkwam, alleen samengeperst in één regel in plaats van drie. "Statistiekendashboard - React en een kleine Node-API die uit een interne eventstream leest, verving drie aparte spreadsheets die het team gebruikte om diezelfde cijfers handmatig bij te houden" past comfortabel op één regel en vertelt de lezer nog steeds iets concreets. Een project terugbrengen tot een kale titel zonder context bespaart daarentegen ruimte maar behoudt niets van de informatie die de regel het waard maakte om op te nemen. Het doel is dichtheid, geen beknoptheid om de beknoptheid zelf: een regel die minder zegt met minder woorden is niet automatisch een betere regel.
Voorbeeld ter illustratie: een ingekorte projectenlijst
Voorbeeld ter illustratie. Een kandidaat heeft negen nevenprojecten en werkgerelateerde projecten die over meerdere jaren zijn gebouwd. Vóór het inkorten krijgt elk project zijn eigen regel van twee zinnen, en alleen al de projectensectie beslaat bijna een hele pagina. Na het inkorten: vier projecten blijven volledig uitgewerkt staan, gekozen omdat ze het nauwst aansluiten bij de stack en het bereik van de doelfunctie, elk geschreven als één regel met wat het is, wat er gebruikt is en wat erdoor veranderde. De overige vijf worden samengevoegd in één afsluitende regel die elk kort benoemt. De projectensectie neemt nu ongeveer een derde van de ruimte in die het voorheen deed, en de vier uitgelichte items zijn gemakkelijker aandachtig te lezen omdat ze niet langer met vijf andere concurreren om dezelfde aandacht.
Leesbaar blijven terwijl je inkort
Meer op een pagina laten passen door de lettergrootte of marges kleiner te maken dan comfortabel leesbaar is, ruilt het ene probleem in voor een erger probleem: een pagina die technisch alles bevat maar onaangenaam leest, verliest meer dan een pagina die eerlijk gezegd een iets langer formaat nodig had. Inkorten moet voortkomen uit de keuze wat je opneemt, niet uit het moeilijker leesbaar maken van de tekst zelf. Als vier volledige projectregels plus een verzamelregel bij een normale leesgrootte nog steeds niet passen, is dat meestal een teken om een vijfde project te schrappen in plaats van de tekst verder te verkleinen, of een teken dat dit specifieke cv eerlijk gezegd een tweede pagina rechtvaardigt.
Wanneer projecten en ervaring om dezelfde pagina strijden
Voor een engineer met meerdere jaren betaalde ervaring en een lange lijst nevenprojecten strijden beide secties om dezelfde beperkte ruimte, en ervaring zou die strijd meestal als eerste moeten winnen. Een lezer die een engineer halverwege de carrière beoordeelt, weegt betaald, verantwoordelijk werk over het algemeen zwaarder dan een nevenproject, dus de projectensectie inkorten tot de paar uitgelichte items, in plaats van ervaringsregels in te korten om plek te maken voor meer projecten, is meestal de veiligere plek om de extra ruimte te vinden die een cv van één pagina nodig heeft.
Bouw de jouwe
Kies een sjabloon gebouwd voor engineeringwerk, zoals het Developer-sjabloon, en loop je eigen projectenlijst door met hetzelfde filter: welke paar projecten ondersteunen de functie het meest direct, en welke kunnen in plaats daarvan in één afsluitende regel genoemd worden. Voor de algemenere vraag hoe lang een cv zou moeten zijn voordat projecten überhaupt in beeld komen, behandelt hoe lang moet een cv zijn de bredere afwegingen, en nevenprojecten presenteren op een cv van een software-engineer gaat dieper in op hoe je één projectregel schrijft zodra je weet welke projecten de selectie hebben overleefd. Begin met inkorten en herbouwen in de bouwer.