Een cv voor een DevOps- of platform engineering-functie leest het best wanneer het betrouwbaarheid, storingsdienst, infrastructuurmigraties en tooling waar andere teams op vertrouwen vooropstelt, in plaats van de feature-gerichte bullets die een algemeen cv voor software engineering vaak gebruikt. Beide cv's delen de meeste van dezelfde mechanismen: ervaring in omgekeerd chronologische volgorde, een korte samenvatting, een vaardighedensectie en bullets die resultaten beschrijven in plaats van taken. Wat verandert, is welke resultaten in dit soort functie daadwerkelijk indruk maken, want de mensen die profiteren van infrastructuurwerk zijn meestal andere engineers en niet eindgebruikers, en het werk zelf blijft vaak onzichtbaar als het goed gaat.
Waarom de nadruk verschuift
Een feature die een software engineer bouwt, heeft meestal een zichtbaar voor-en-na: een scherm dat er nog niet was, een flow die van vijf stappen naar twee ging. Infrastructuur- en platformwerk bereikt dat zichtbare resultaat zelden, omdat het beste mogelijke resultaat vaak is dat er vanuit gebruikersperspectief niets verandert: een deploy die iemand vroeger om twee uur 's nachts wakker maakte, doet dat nu niet meer, een dienst die het begaf onder belasting begeeft het nu niet meer. Een cv voor dit soort functie moet die onzichtbare betrouwbaarheid begrijpelijk maken voor een lezer die nooit in infrastructuur heeft gewerkt, door te benoemen wat van het werk afhing en wat kapot zou zijn gegaan zonder dat werk.
Betrouwbaarheid en beschikbaarheid eerlijk beschrijven
Betrouwbaarheidswerk lokt dezelfde valkuil uit als beschreven in technische impact op je cv kwantificeren zonder cijfers te verzinnen: een verleidelijk maar niet-verifieerbaar cijfer als "beschikbaarheid met 40% verbeterd" terwijl zo'n cijfer nooit echt is bijgehouden. Waar een echte, nu nog controleerbare meetwaarde bestaat, uit een dashboard of een incidentrapport, hoort die zoals hij is op het cv. Waar die niet bestaat, wegen omvang en een beschreven voor-en-na-situatie even zwaar zonder het risico.
Storingsdienst en incidentrespons als cv-inhoud
Verantwoordelijkheid voor storingsdienst verdient een directe vermelding in plaats van weggestopt te worden in een vage regel als "ondersteuning van productiesystemen", omdat het een niveau van operationele verantwoordelijkheid signaleert dat een puur feature-gerichte rol niet heeft. Wat goed leest, is de vorm van die verantwoordelijkheid: voor welk systeem of welke systemen je storingsdienst had, hoe het rooster ongeveer werkte, en één concreet ding dat veranderde door een incident dat je afhandelde.
Migraties en infrastructuurwijzigingen die het vermelden waard zijn
Een migratie, een platformwijziging of een tooling-overstap verdient een eigen bullet wanneer het het soort project is waar andere engineers zich aan moesten aanpassen, in plaats van een puur interne wijziging die niemand buiten het team opmerkte. Benoemen wat er verplaatst is en waarom, levert meestal meer informatie op dan alleen de naam van de doeltechnologie te noemen.
Tooling waar andere teams op vertrouwen
Interne tooling verdient dezelfde behandeling als een klantgerichte feature: wat het doet, wie het gebruikt, wat het verving. Bijverdienstprojecten presenteren op een cv van een software engineer behandelt dezelfde onderliggende structuur voor werk dat buiten een formele functie is gebouwd, en die past even goed op een interne tool die binnen een functie is gebouwd.
Illustratief voorbeeld: een bullet herschreven rond infrastructuureigenaarschap
Voor, vaag en feature-gevormd: "Werkte aan infrastructuur en deployment voor het backendteam." Na, herschreven rond eigenaarschap, omvang en een beschreven voor-en-na-situatie: "Verantwoordelijk voor de deploy-pipeline van de elf diensten van het backendteam; de pipeline vereiste voorheen voor elke dienst een handmatige goedkeuringsstap voordat er gedeployd kon worden, en na de herschrijving volstond een geslaagde testsuite voor automatisch deployen, waardoor het aantal engineers dat op releasemoment beschikbaar moest zijn daalde van drie naar één."
Een lange lijst tools en platforms groeperen
De vaardighedensectie van een platform engineer loopt vaak langer dan die van een typische developer, en beslaat tegelijk cloudproviders, orkestratietools, monitoringsystemen en talen, precies het soort lange, gemengde lijst dat baat heeft bij groepering per categorie in plaats van één ongesorteerde regel.
Bouw de jouwe
CVBuilderKits Developer-sjabloon is gebouwd rond project- en eigenaarschapsgerichte items, wat net zo goed past bij infrastructuur- en platformwerk als bij applicatiecode. Begin ermee, of met een leeg document, in de bouwer en herschrijf je bullets over betrouwbaarheid, storingsdienst en migraties rond wat er echt van het werk afhing, voordat je grijpt naar een cijfer dat je momenteel niet kunt onderbouwen.