Sollicitatiebrief voorbeeld SRE engineer
Hiring managers beoordelen een SRE-engineer-brief op vier dingen: betrouwbaarheid (welke uptime realiseerde je en hoe?), incident management (hoe snel los je problemen op en hoe voorkom je herhaling?), infrastructure as code (hoe beheer je je infrastructuur op schaal?) en kosten-optimalisatie (hoe balanceer je betrouwbaarheid met kosten?). Een brief zonder die operationele diepgang is als een monitoring-dashboard zonder alerts — het mist het punt.
Waarom een gerichte brief voor site reliability engineering?
Site reliability engineering draait om systemen betrouwbaar houden op schaal — en dat is precies wat je brief moet bewijzen. Niet met vage beweringen over "een passie voor stabiliteit", maar met harde operationele metrics. Een generieke brief met "ik heb ervaring met Linux en monitoring" verdwijnt in de inbox. Een brief die beschrijft hoe jij de uptime van een betalingsplatform verhoogde van 99,91% naar 99,99% terwijl je de infrastructuurkosten met 30% verlaagde, of hoe je de MTTR van je team terugbracht van 47 naar 8 minuten door een geautomatiseerd incident-response-framework op te zetten — die wordt doorgestuurd naar de VP Engineering. Hieronder vind je een complete voorbeeldbrief met toelichting per alinea.
Volledige voorbeeldbrief
De brief hieronder is geschreven voor een fictieve vacature bij ING. Klik op een alinea om te lezen waarom deze aanpak werkt voor site reliability engineering.
Klik op een alinea om te zien waarom deze goed werkt
Amsterdam, 1 april 2026
Beste meneer Kuipers,
Het blog-artikel van ING Engineering over de migratie naar een intern platform-as-a-service voor 1.500 development-teams trok mijn aandacht — de schaal en de betrouwbaarheidseisen zijn precies het type uitdaging waar ik als SRE engineer het meeste waarde toevoeg. Bij Booking.com ben ik de afgelopen vier jaar verantwoordelijk voor de reliability van het betaalplatform dat jaarlijks €38 miljard aan transacties verwerkt.
Bij Booking.com ben ik SRE lead voor het payments-cluster van 42 microservices op Kubernetes. In 2025 verhoogde ik de platformuptime van 99,91% naar 99,99% — een reductie van 7,8 uur naar 53 minuten ongeplande downtime per jaar. Dat bereikte ik door een combinatie van SLO-driven alerting (120 SLI's gedefinieerd in Prometheus), chaos engineering (maandelijkse game days) en geautomatiseerde incident response die de MTTR van 47 naar 8 minuten bracht. Daarnaast migreerde ik de volledige infrastructure-as-code van handmatige configuratie naar Terraform-modules, waardoor de provisioning-tijd daalde van twee dagen naar 15 minuten én de maandelijkse cloud-kosten met 30% daalden door right-sizing en spot-instance-optimalisatie.
Wat mij aantrekt aan ING is de ambitie om reliability op enterprise-schaal te democratiseren. Bij Booking.com werk ik voor één cluster — bij ING zou ik bijdragen aan een platform dat 1.500 teams bedient. Die verschuiving van "reliability voor mijn services" naar "reliability als platform-dienst" is de volgende stap in mijn carrière. Bovendien spreekt de financiële context mij aan: de combinatie van strikte compliance-eisen (PSD2, DORA) en de noodzaak om snel te innoveren maakt SRE bij een bank technisch uitdagender dan bij de meeste techbedrijven.
Ik licht graag in een gesprek toe hoe mijn ervaring met platform-reliability en SLO-driven engineering past bij de schaalambities van ING Engineering. U bereikt mij op 06-19384726 of via mark.deboer@email.nl.
Met vriendelijke groet,
Mark de Boer
Competenties die VP's Engineering zoeken
Deze zes vaardigheden komen het vaakst terug in SRE-vacatures. Noem ze niet los op — verwerk ze in een voorbeeld dat laat zien hoe je ze hebt ingezet.
SLOs, SLIs & error budgets
Beschrijf hoeveel SLO's je definieerde en hoe je ze gebruikte om beslissingen te sturen. "120 SLI's in Prometheus, error-budget-driven release decisions" toont SRE-volwassenheid. "Ik monitor systemen" niet.
Incident management & MTTR
Noem je MTTR en hoe je die verbeterde. "MTTR van 47 naar 8 minuten door geautomatiseerde incident response en runbooks" laat zien dat je niet alleen branden blust maar het hele proces optimaliseert.
Infrastructure as Code (Terraform/Pulumi)
Noem de tool, de schaal en de impact. "Terraform-modules voor 42 microservices, provisioning-tijd van 2 dagen naar 15 minuten" bewijst dat je infrastructuur op schaal beheert.
Chaos engineering & resilience testing
Beschrijf je chaos-engineering-aanpak: game days, fault injection, blast radius-testen. "Maandelijkse game days die 12 latente single points of failure identificeerden" toont een proactieve aanpak.
Kosten-optimalisatie
Reliability en kosten zijn communicerende vaten. "Cloud-kosten met 30% gereduceerd door right-sizing en spot instances, zonder impact op SLO's" bewijst dat je beide kanten beheerst.
Observability (Prometheus/Grafana/Datadog)
Noem de observability-stack én hoe je die gebruikt. "Prometheus + Grafana-dashboards met 120 SLI's en PagerDuty-integratie voor on-call-alerting" is specifieker dan "ervaring met monitoring tools".
Openingszinnen per situatie
Kopieer de opening die past bij jouw situatie en vul de specifieke gegevens aan. Elke opening is geschreven voor een ander type sollicitatie als SRE engineer.
“Het blog van [bedrijf] over [onderwerp] trok mijn aandacht — de betrouwbaarheidseisen op die schaal zijn precies mijn domein. Bij [vorige werkgever] ben ik verantwoordelijk voor de reliability van [type platform] dat [volume/schaal] verwerkt.”
“Bij [vorige werkgever] verhoogde ik de platformuptime van [oud]% naar [nieuw]% en bracht ik de MTTR terug van [oud] naar [nieuw] minuten. Die focus op meetbare betrouwbaarheid wil ik bij [bedrijf] voortzetten.”
“Cloud-kosten met [percentage]% reduceren zonder concessies aan de SLO's — dat is wat ik bij [vorige werkgever] realiseerde voor een [type platform]. Uw vacature voor SRE engineer bij [bedrijf] sluit aan bij mijn focus op de balans tussen reliability en efficiëntie.”
“Na [aantal] jaar als DevOps engineer, waarin ik steeds meer de reliability-kant opzocht — SLO's, incident response, chaos engineering — is de stap naar een dedicated SRE-rol bij [bedrijf] een logische volgende fase.”
“De schaal van [bedrijf] — [specifiek voorbeeld] — vraagt om SRE-engineers die reliability systematisch aanpakken. Met [aantal] jaar ervaring in [type platform] en een bewezen track record in [resultaat] wil ik graag bespreken hoe ik kan bijdragen.”
Zwak vs. sterk: het verschil per alinea
Links de brief die op de nee-stapel belandt. Rechts de versie die een uitnodiging oplevert. Het verschil zit in operationele metrics, reliability-aanpak en een heldere link tussen jouw SRE-werk en bedrijfscontinuïteit.
Opening
De opening bepaalt of de VP Engineering doorleest. Bij SRE-vacatures verwacht hij direct een signaal dat je op schaal hebt gewerkt en reliability meetbaar hebt verbeterd.
Hierbij solliciteer ik op de functie van SRE engineer bij ING. Ik ben een ervaren systeembeheerder met een passie voor het stabiel houden van systemen en het automatiseren van processen.
"Ervaren systeembeheerder" is geen SRE. "Passie voor stabiliteit" is een mening, geen bewijs. Geen uptime-cijfers, geen schaal, geen SRE-methodologie. Een VP Engineering ziet dit als een ops-engineer die zich SRE noemt.
Het blog van ING Engineering over de migratie naar een platform-as-a-service voor 1.500 teams trok mijn aandacht. Bij Booking.com ben ik verantwoordelijk voor de reliability van het betaalplatform dat jaarlijks €38 miljard aan transacties verwerkt.
Opent met een specifiek ING-initiatief en volgt met de ultieme SRE-credential: verantwoordelijkheid voor €38 miljard aan transacties. De VP Engineering denkt: deze engineer opereert op het niveau dat wij nodig hebben.
Ervaring
De ervaringsparagraaf is je operationele bewijslast. Kies maximaal vier resultaten die laten zien dat je reliability meetbaar verbetert en systemen op schaal beheert.
In mijn huidige functie beheer ik de servers en zorg ik ervoor dat alles draait. Ik heb ervaring met Kubernetes en Terraform en los incidenten op als die zich voordoen. Ik ben ook verantwoordelijk voor monitoring.
"Alles draait" — welke uptime? "Ervaring met Kubernetes" — hoeveel clusters, hoeveel nodes? "Los incidenten op" — met welke MTTR? Dit klinkt als een sysadmin, niet als een SRE. Zonder metrics kan de hiring manager het niveau niet inschatten.
Bij Booking.com verhoogde ik de platformuptime van 99,91% naar 99,99% — van 7,8 uur naar 53 minuten downtime per jaar. Dat bereikte ik door SLO-driven alerting (120 SLI's), chaos engineering (maandelijkse game days) en geautomatiseerde incident response die de MTTR van 47 naar 8 minuten bracht.
Vier harde metrics (99,99% uptime, 53 min downtime/jaar, 120 SLI's, MTTR 47→8 min) plus de methodologie (SLO-driven, chaos engineering). De VP Engineering kan precies inschatten: dit is een senior SRE met een systematische aanpak.
Motivatie
Hier laat je zien dat je het bedrijf en de SRE-uitdaging hebt onderzocht. Noem een specifieke schaal, compliance-eis of platformambitie en leg uit waarom dat je als SRE aantrekt.
ING is een grote bank en ik denk dat daar veel interessante technische uitdagingen zijn. Ik wil graag werken bij een bedrijf waar ik mijn SRE-vaardigheden kan inzetten.
"Grote bank" en "interessante uitdagingen" zijn generiek. Geen specifieke ING-context, geen link met compliance of schaal. De focus ligt op de kandidaat, niet op de waarde voor het bedrijf.
Wat mij aantrekt aan ING is de ambitie om reliability op enterprise-schaal te democratiseren. De verschuiving van "reliability voor mijn services" naar "reliability als platform-dienst" voor 1.500 teams is de volgende stap in mijn carrière. De combinatie van DORA-compliance en innovatietempo maakt SRE bij een bank technisch uitdagender dan bij de meeste techbedrijven.
Drie specifieke redenen: platform-schaal (1.500 teams), carrière-logica (cluster → platform) en domeinkennis (DORA-compliance). De recruiter ziet een doordachte motivatie van iemand die begrijpt wat SRE bij een bank inhoudt.
Afsluiting
Eindig actief. Herhaal kort je operationele kernwaarde en maak het de hiring manager makkelijk om contact op te nemen.
Ik sta open voor een gesprek en hoop dat mijn achtergrond aansluit bij wat jullie zoeken. Met vriendelijke groet.
Passief en onzeker. Geen herhaling van SRE-waarde, geen contactgegevens. Niet de toon van een engineer die op 3 uur 's nachts een P1-incident oplost.
Ik licht graag in een gesprek toe hoe mijn ervaring met platform-reliability en SLO-driven engineering past bij de schaalambities van ING Engineering. U bereikt mij op 06-19384726 of via mark.deboer@email.nl.
Herhaalt twee SRE-specifieke kernpunten en koppelt ze aan het bedrijfsdoel. Directe contactgegevens, professionele toon die rust uitstraalt — precies wat je wilt van iemand die verantwoordelijk is voor je uptime.
Schrijftips voor je SRE-engineer-brief
Noem je uptime in nines
SRE spreekt in nines: 99,9% (8,8 uur downtime/jaar) versus 99,99% (53 minuten/jaar). "Uptime van 99,91% naar 99,99% verhoogd" is een zin die elke VP Engineering direct begrijpt en waardeert.
Noem jezelf geen "systeembeheerder met SRE-interesse"
SRE is een engineering-discipline, geen rebranding van ops. Toon het verschil: SLO's, error budgets, chaos engineering, toil-reductie. Als je brief klinkt als een sysadmin-brief met een SRE-label, wordt dat direct herkend.
Beschrijf je incident-response-framework
Hoe ziet je incident-response-proces eruit? Alerting, triage, mitigatie, postmortem — beschrijf het en noem de MTTR die je bereikte. "Geautomatiseerd incident-response-framework dat de MTTR van 47 naar 8 minuten bracht" toont een systematische aanpak.
Vergeet niet de kosten te benoemen
Reliability zonder kostenbewustzijn is geen SRE maar overengineering. "Cloud-kosten met 30% gereduceerd door right-sizing en spot instances, zonder impact op SLO's" laat zien dat je de trade-off tussen betrouwbaarheid en kosten beheerst.
Verwijs naar je chaos-engineering-aanpak
Chaos engineering onderscheidt proactieve SRE's van reactieve. "Maandelijkse game days die 12 latente single points of failure identificeerden voordat ze incidenten werden" bewijst dat je problemen voorkomt in plaats van alleen oplost.
Som geen monitoring-tools op zonder context
"Prometheus, Grafana, Datadog, PagerDuty, ELK" zonder uitleg is een cv-rijtje. Beschrijf hoe je de stack inzet: "120 SLI's in Prometheus met Grafana-dashboards en PagerDuty-escalation voor 4-tier on-call-rotatie" toont operationele diepgang.
Meer over solliciteren als sre engineer
Verwante beroepen
Veelgestelde vragen over een SRE-engineer-brief
Eén A4, vier alinea's van elk drie tot vijf zinnen. SRE engineers worden beoordeeld op hun vermogen om complexe systemen beknopt te beschrijven — als je in vier alinea's niet kunt uitleggen waarom je de juiste kandidaat bent, hoe ga je dan een postmortem schrijven die het hele engineeringteam begrijpt?
Focus op vijf kernmetrics: (1) uptime in nines (bijv. 99,99%), (2) MTTR — mean time to recovery, (3) MTTD — mean time to detect, (4) change failure rate — percentage deployments dat een incident veroorzaakt, en (5) kostenefficiëntie — besparingen door optimalisatie. Kies de drie die het meest relevant zijn voor de vacature.
DevOps focust op de delivery-pipeline: CI/CD, deployment-automatisering, developer experience. SRE focust op de operationele betrouwbaarheid: SLO's, incident management, capacity planning, chaos engineering. In de praktijk overlappen ze, maar je brief moet het SRE-perspectief benadrukken: niet hoe snel je deployt, maar hoe betrouwbaar je systemen draaien nadat je gedeployd hebt.
Een medior SRE engineer verdient gemiddeld €4.500–€6.000 bruto per maand, een senior €6.000–€8.000. Bij grote techbedrijven (Booking.com, Adyen) en financiële instellingen (ING, ABN AMRO) liggen de salarissen hoger, vaak aangevuld met on-call-vergoedingen, RSU's of bonussen. SRE is een van de best betaalde engineering-disciplines in Nederland vanwege de schaarste en de operationele impact.
Ja, on-call is een kernonderdeel van SRE. Beschrijf je rotatie-opzet en wat je bereikte: "4-tier on-call-rotatie voor 42 microservices, gemiddeld 2,3 pages per week met een MTTA van 3 minuten" toont operationele volwassenheid. Vermeld ook hoe je de on-call-last verminderde: minder false positives, betere runbooks, geautomatiseerde mitigatie.
Focus op de SRE-elementen in je DevOps-werk: monitoring, incident response, reliability-metrics, infrastructure as code. Beschrijf hoe je van deployment-automatisering verschoof naar operationele betrouwbaarheid. "Van CI/CD-pipelines naar SLO-driven release decisions" is een overtuigende carrière-lijn. Een Google SRE-certificering of ervaring met het Google SRE-book kan het verschil maken als je formele SRE-ervaring mist.
Brief klaar? Versterk ook je cv.
Je sollicitatiebrief vertelt het verhaal, je cv levert het bewijs. Bekijk ons cv-voorbeeld voor SRE engineers met uptime-metrics, incident management en infrastructure-as-code-ervaring.