Er is geen betrouwbare manier om een percentage te plakken op technisch werk dat nooit gemeten is, en een getal verzinnen om te voldoen aan het generieke advies "kwantificeer je impact" is erger dan het getal gewoon weglaten, want een verzonnen statistiek klopt óf niet, óf is onmogelijk te verdedigen als iemand vraagt waar die vandaan komt. Wat je wel eerlijk kunt beschrijven, ook zonder een bijgehouden meetwaarde, is de omvang: hoe groot het systeem was, hoeveel mensen of diensten ervan afhingen, hoe vaak het draaide, en wat er meetbaar veranderde tussen een situatie ervoor en een situatie erna. Dat zijn feiten die je meestal uit je geheugen, een ticketgeschiedenis of een postmortemrapport kunt reconstrueren, en ze lezen voor een lezer veel geloofwaardiger dan een getal dat uit het niets komt.
Waarom het advies "voeg gewoon een getal toe" faalt zonder meetwaarde
De meeste cv-adviezen zeggen engineers dat ze elk punt moeten kwantificeren, en dat advies is op zichzelf niet verkeerd: iemand die tientallen cv's doorneemt, reageert echt beter op iets concreets dan op een vage bewering. Het probleem is dat veel echt technisch werk nooit is bijgehouden op een manier die een nette percentage oplevert. Veel teams draaien geen dashboard voor elke wijziging, veel impact wordt gevoeld in plaats van gemeten, en veel engineers stappen over naar een nieuwe rol voordat iemand terugkomt om te checken of de wijziging van vorig kwartaal echt hielp. Tegenover dat gat ligt de verleidelijke kortere weg: een getal opschrijven dat ongeveer goed voelt en hopen dat niemand vraagt waar het vandaan komt. Precies die valkuil wil dit artikel helpen vermijden, want een getal dat een interviewer met één vervolgvraag kan doorprikken, doet meer schade dan helemaal geen getal.
Eerlijke maatstaven die er zijn, zelfs zonder bijgehouden meetwaarde
Voor bijna elk stuk technisch werk bestaan meerdere soorten concrete details, of er nu ooit een meetwaarde voor is vastgelegd of niet. Omvang beschrijft de grootte van wat je hebt aangeraakt: hoeveel diensten een wijziging raakte, hoe groot de codebase was, hoeveel endpoints of tabellen betrokken waren. Schaal beschrijft hoeveel het systeem droeg: hoeveel requests het bediende, hoeveel records het opsloeg, hoeveel teams erop bouwden, geformuleerd in termen die je zelfverzekerd kunt uitspreken in plaats van een getal dat je gokt. Frequentie beschrijft hoe vaak iets draaide of gebruikt werd: een batchtaak die elke nacht liep, een deploy-pipeline die elke engineer in het team gebruikte, een rapport dat elk afgesloten kwartaal werd gegenereerd. De situatie ervoor en erna beschrijft wat waar was vóór je wijziging en wat waar werd erna, in gewone taal in plaats van een percentage: wat er voorheen misging, wat voorheen een handmatige stap vereiste, wat voorheen iemand in de wachtdienst nodig had, en wat niet langer waar was zodra het werk live ging. Wie erop vertrouwde benoemt het echte publiek: het team dat jouw tool gebruikte, de dienst die de API aanriep die jij onderhield, de wachtdienst die niet meer gepiept werd voor het probleem dat jij verhielp. Elk van deze punten is iets wat je zelf hebt meegemaakt en uit eerste hand kunt beschrijven, en precies dat maakt het veel beter verdedigbaar dan een afgerond percentage.
Illustratief voorbeeld: een punt herschreven rond omvang in plaats van een percentage
Voor, vaag en zonder cijfers: "Verantwoordelijk voor de prestaties van de checkoutdienst." Na, herschreven rond omvang en een beschreven situatie ervoor en erna in plaats van een verzonnen getal: "Verantwoordelijk voor de databasequerylaag van de checkoutdienst, het enige pad waar elke aankoop op de site doorheen ging; vóór de herschrijving waren trage queries de meest voorkomende oorzaak van een vastgelopen checkout die het supportteam moest escaleren, en na de livegang verdween die categorie klachten uit de wekelijkse triage." Niets in de herschreven versie is een gegokte statistiek. Er staat waar de kandidaat verantwoordelijk voor was, hoe centraal dat onderdeel voor het systeem was, hoe het probleem er daarvoor uitzag, en wat er daarna veranderde, allemaal uit iets wat de kandidaat echt heeft meegemaakt in plaats van een achteraf gereconstrueerd getal.
Wat je uit de herschrijving weglaat
De grens die je moet aanhouden ligt tussen een getal waar je nu naar kunt wijzen, uit een dashboard, een postmortemrapport of een meetwaarde die je destijds echt hebt bijgehouden, en een getal dat je reconstrueert uit een vage herinnering als "het voelde alsof dingen veel sneller gingen". Het eerste kun je gerust direct citeren. Het tweede is precies het type dat het waard is om te herschrijven met taal over omvang en ervoor/erna in plaats daarvan, want een herinnerde indruk die is afgerond tot een mooi klinkend getal is precies het soort bewering dat instort bij één concrete vervolgvraag in een sollicitatiegesprek. De omvangsgebaseerde versie hierboven overleeft die vraag, omdat elk onderdeel ervan iets is wat je in je eigen woorden kunt beschrijven zonder te leunen op een getal dat je eigenlijk nooit hebt vastgelegd.
Hoe dit past bij het bredere patroon van taken naar prestaties
Herschrijven rond omvang in plaats van een verzonnen statistiek is een specifieke toepassing van een bredere verschuiving, die ver buiten engineering opgaat: een beschrijving van waar je verantwoordelijk voor was, omzetten in een beschrijving van wat daardoor daadwerkelijk veranderde. Taken omzetten in prestaties op je cv behandelt dat bredere herschrijfpatroon met voorbeelden uit rollen buiten engineering, voor iedereen wiens punten nu nog lezen als een lijst met toegewezen taken in plaats van resultaten.
Dit punt opbouwen
Hoe je een cv schrijft behandelt de woordkeuzes die dit soort herschrijving door de rest van het cv laten doorlopen, en het developer-template van CVBuilderKit is precies gebouwd voor dit soort omvang- en projectgedreven punten. Begin bij een bestaand of leeg document in de bouwer en herschrijf elk punt met omvang en een beschreven situatie ervoor en erna, voordat je grijpt naar een getal dat je eigenlijk niet kunt verdedigen.