Leitfaden für Platform-Engineer-Anschreiben

Platform-Engineering-Teams erhalten laut Hireds Report „2025 State of Tech Salaries" durchschnittlich 85 Bewerbungen pro offener Stelle, doch weniger als 12 % aller Anschreiben nehmen Bezug auf konkrete Infrastrukturherausforderungen des Zielunternehmens [1]. Ein Anschreiben, das mit „Hiermit bewerbe ich mich auf die Position als Platform Engineer" beginnt, signalisiert sofort einen Vorlagen-Ansatz. Wer Vorstellungsgespräche bekommt, schreibt Anschreiben, die die Infrastruktur-Schwachstellen des Unternehmens diagnostizieren und konkrete Lösungen aus der eigenen Erfahrung vorschlagen.

Die wichtigsten Erkenntnisse

• Beginnen Sie mit einer konkreten Beobachtung zum Tech-Stack oder Engineering-Blog des Unternehmens – nicht mit einem generischen Interessensbekundung
• Verknüpfen Sie Ihre Erfahrung mit IDP, Kubernetes oder Terraform direkt mit Herausforderungen, über die das Unternehmen publiziert hat
• Quantifizieren Sie Ihre Plattform-Wirkung: Deployment-Frequenz, MTTR-Reduktion, Entwickler-Akzeptanzraten
• Zeigen Sie Produktdenken – verstehen Sie Plattformen als interne Produkte, nicht nur als Infrastruktur
• Halten Sie es unter 400 Wörtern; Hiring Manager im Engineering lesen Anschreiben in 45 Sekunden oder weniger

Einen überzeugenden Einstiegsabsatz schreiben

Der Einstiegsabsatz entscheidet, ob Ihr Anschreiben gelesen oder aussortiert wird. Engineering-Hiring-Manager sind technisch versiert – sie respektieren Konkretheit mehr als Enthusiasmus. **Der rechercheorientierte Ansatz funktioniert am besten.** Bevor Sie ein Wort schreiben, finden Sie den Engineering-Blog, die Open-Source-Repositories, Konferenzvorträge oder Details der Stellenausschreibung. Achten Sie auf Signale zur Infrastrukturreife: Migrieren sie zu Kubernetes? Bauen sie ein Developer Portal? Kämpfen sie mit der Deployment-Geschwindigkeit? **Starkes Einstiegsbeispiel:** "Your engineering blog post on migrating from monolithic deployments to a microservices architecture on EKS caught my attention — particularly the challenge of maintaining deployment velocity across 40+ services. At [Previous Company], I faced a nearly identical scaling inflection point and built an ArgoCD-based GitOps pipeline that brought deployment lead time from 42 minutes to under 8 minutes for 45 services. I'd like to bring that experience to [Company]'s platform team." **Warum das funktioniert:** Es zeigt Recherche, stellt Relevanz her, liefert eine konkrete Kennzahl und bietet Mehrwert – alles in drei Sätzen. **Schwacher Einstieg, den Sie vermeiden sollten:** "I am excited to apply for the Platform Engineer role at [Company]. With my experience in Kubernetes and Terraform, I believe I would be a great fit for your team." Das sagt dem Hiring Manager nichts, was er nicht durch einen Blick auf Ihren Lebenslauf erfahren würde.

Der Hauptteil: Verknüpfen Sie Ihre Erfahrung mit deren Bedürfnissen

Der Hauptteil Ihres Anschreibens sollte 2–3 prägnante Absätze enthalten, die jeweils eine konkrete Leistung aus Ihrer Erfahrung mit einem Bedarf im Zielunternehmen verknüpfen. **Absatzstruktur:** deren Herausforderung identifizieren → Ihre relevante Erfahrung präsentieren → das Ergebnis quantifizieren. **Beispiel eines Hauptabsatzes:** "Your job posting emphasizes building self-service infrastructure provisioning for engineering teams. At [Company], I designed a Crossplane-based self-service catalog that enabled developers to provision databases, caches, and message queues through a simple API without filing tickets. This reduced infrastructure request wait times from 4 hours to 12 minutes and achieved 91% adoption within three months. I also established Terraform module standards that our 23-module library followed, which cut configuration drift incidents by 67%." **Was der Hauptteil abdecken sollte:**

• Ein Absatz zur relevantesten technischen Leistung (Kubernetes, IaC, CI/CD im großen Maßstab)
• Ein Absatz zur Developer Experience / zu Plattform-Produktergebnissen (Adoption, Zufriedenheit, Self-Service)
• Optionaler dritter Absatz zu Kultur-Fit oder konkretem Interesse an deren Mission **Technische Präzision zählt.** „ArgoCD GitOps Workflows" wiegen mehr als „Deployment-Automatisierung". „12-Node-GKE-Cluster mit Istio Service Mesh" schlägt „gemanagte Kubernetes-Infrastruktur". Hiring Manager sind Ingenieure – sie messen Ihre Tiefe an der Präzision Ihrer Sprache.

Das Zielunternehmen recherchieren

Effektive Recherche verwandelt einen generischen Brief in ein gezieltes Angebot. Investieren Sie 20–30 Minuten in:

1. **Engineering-Blog:** Die meisten Tech-Unternehmen publizieren über ihre Infrastrukturentscheidungen. Suchen Sie „[Unternehmen] engineering blog" oder prüfen Sie deren Medium/dev.to-Präsenz. Achten Sie auf Migrationsprobleme, Skalierungsthemen oder Tooling-Entscheidungen.
2. **GitHub-Repositories:** Prüfen Sie, ob das Unternehmen Open-Source-Projekte pflegt. Vor der Bewerbung zu deren Repos beizutragen ist das stärkstmögliche Signal.
3. **Konferenzvorträge:** Suchen Sie auf YouTube nach „[Unternehmen] KubeCon" oder „[Unternehmen] DevOps". Ingenieure diskutieren oft Herausforderungen, an denen sie arbeiten.
4. **Details der Stellenausschreibung:** Analysieren Sie die konkreten Anforderungen. Wenn Backstage, ArgoCD oder ein bestimmter Cloud-Anbieter genannt wird, verweisen Sie direkt auf Ihre Erfahrung.
5. **Glassdoor-Engineering-Bewertungen:** Achten Sie auf Erwähnungen von Infrastrukturproblemen, Deployment-Geschwindigkeit oder Developer-Experience-Schmerzpunkten.
6. **LinkedIn:** Sehen Sie sich Profile aktueller Platform Engineers an. Welche Tools empfehlen sie? Welche Projekte heben sie hervor?

Einen starken Schluss formulieren

Der Schluss sollte zwei bis drei Sätze umfassen. Er sollte Ihr Wertversprechen knapp wiederholen und einen klaren Handlungsaufruf enthalten, ohne anmaßend zu wirken. **Starker Schluss:** "I'm particularly drawn to [Company]'s approach to developer experience, and I believe my experience building self-service platforms for 400+ engineer organizations directly aligns with where your platform team is heading. I'd welcome the opportunity to discuss how my work on IDP architecture and GitOps at scale could accelerate your engineering velocity. I'm available for a conversation at your convenience." **Vermeiden Sie folgende Schlussformulierungen:**

• „I look forward to hearing from you soon" (passiv, abgedroschen)
• „I am confident I would be a great addition to your team" (Selbsteinschätzung ohne Beleg)
• Gehaltsvorstellungen (niemals ins Anschreiben)

3 vollständige Anschreiben-Beispiele

Beispiel 1: Senior Platform Engineer (Enterprise SaaS)

Dear [Hiring Manager], Your recent KubeCon talk on scaling internal developer platforms for 600+ engineers resonated deeply with challenges I solved at [Previous Company]. Specifically, your mention of developer onboarding friction maps directly to work where I reduced new service creation from a 3-week ticket-driven process to a 2-hour self-service workflow using Backstage golden path templates. Over the past 9 years, I've built platform infrastructure that directly improves engineering velocity. At [Company], I architected an Internal Developer Platform serving 400+ engineers across 6 product teams, implementing ArgoCD GitOps across 180 microservices with a 99.99% deployment success rate. I designed a multi-cluster Kubernetes federation across 3 AWS regions supporting 2,400+ pods, and introduced Karpenter-based autoscaling that reduced annual compute costs by $520K. What excites me about [Target Company] is your commitment to treating the platform as a product, not a cost center. My experience establishing platform SLO frameworks, running developer satisfaction surveys (achieving an 8.2/10 score), and building API-first self-service catalogs aligns directly with that philosophy. I'd welcome a conversation about how my IDP architecture experience could support your platform team's growth. I'm available at your convenience. Best regards, [Name]

Beispiel 2: Mid-Level Platform Engineer (Wachstums-Start-up)

Dear [Hiring Manager], I noticed [Company] recently raised a Series C and is scaling from 30 to 100 engineers — a phase where platform engineering transitions from "nice to have" to critical infrastructure. At [Previous Company], I joined when the engineering team was 35 and built the platform foundations that supported growth to 120 engineers without proportional infrastructure headcount increases. My most relevant experience includes implementing an ArgoCD GitOps pipeline for 45 microservices that cut deployment lead time from 38 minutes to 7 minutes, building a Terraform module library (23 modules, 89% team adoption), and designing a centralized observability stack processing 2.3TB daily log volume. I also managed a 12-node GKE cluster with Istio service mesh supporting 850+ pods with mTLS and automated canary deployments. What draws me to [Company] is the opportunity to build a platform from early foundations rather than inheriting technical debt. I'd be glad to discuss how my experience scaling platform infrastructure during rapid growth could support your engineering expansion. Sincerely, [Name]

Beispiel 3: Junior Platform Engineer (Erste Platform-Rolle)

Dear [Hiring Manager], Your job posting for a Platform Engineer mentions migrating CI/CD infrastructure and improving developer onboarding — two challenges I tackled directly in my current role at [Company]. I migrated 8 application pipelines from Jenkins to GitHub Actions, reducing build times by 41% and cutting developer feedback loops from 25 minutes to 9 minutes through parallel test execution. Beyond CI/CD, I've built Kubernetes namespace provisioning automation with Terraform and Helm for 15 development teams, implemented container security scanning with Trivy and OPA Gatekeeper (blocking 340+ vulnerable images in 6 months), and configured a Prometheus monitoring stack with 28 custom Grafana dashboards. While earlier in my career than your typical candidate, I bring hands-on experience with the core tools in your stack and a strong orientation toward developer experience. I'd appreciate the opportunity to discuss how my infrastructure automation experience could contribute to your platform team. I am available at your convenience. Best regards, [Name]

Häufige Fehler im Anschreiben

1. **Den Lebenslauf wiederholen.** Das Anschreiben soll ergänzen, nicht duplizieren. Nutzen Sie es, um zu erklären, warum konkrete Erfahrungen für diese Rolle relevant sind – nicht, um sie erneut aufzulisten.
2. **Schreiben, was Sie wollen, statt was Sie bieten.** „Ich möchte meine Kubernetes-Fähigkeiten ausbauen" fokussiert auf Ihre Bedürfnisse. „Ich bringe 3 Jahre Kubernetes-Produktionserfahrung in Ihre Migration ein" fokussiert auf deren Bedürfnisse.
3. **Generisches Technologie-Name-Dropping.** „Kubernetes, Terraform, Docker, AWS" ohne Verknüpfung mit konkreten Ergebnissen wirkt wie Füllwerk. Jede Tool-Erwähnung sollte an ein Resultat gebunden sein.
4. **Über 400 Wörter.** Engineering-Hiring-Manager haben wenig Zeit. Ein knappes 300–350-Wörter-Schreiben mit Recherche und quantifizierter Wirkung schlägt einen 700-Wörter-Essay jedes Mal.
5. **Anforderungen der Stellenausschreibung ignorieren.** Wenn die Ausschreibung GCP betont, Ihr Schreiben aber nur AWS nennt, verpassen Sie eine naheliegende Passung. Spiegeln Sie die Sprache und den Tool-Stack der Ausschreibung.
6. **Dasselbe Schreiben an jedes Unternehmen senden.** Platform-Teams in einem 50-Personen-Start-up stehen vor grundlegend anderen Herausforderungen als solche in einem 5.000-Personen-Unternehmen. Ihr Schreiben muss dieses Verständnis widerspiegeln.

Abschließende Erkenntnisse

Die wirksamsten Platform-Engineer-Anschreiben leisten dreierlei: Sie zeigen konkrete Recherche zu den Infrastrukturherausforderungen des Unternehmens, verknüpfen Ihre quantifizierten Erfolge damit und machen deutlich, dass Sie Plattformen als Produkte für Entwickler verstehen. Sparen Sie sich den Enthusiasmus – führen Sie mit Belegen.

Häufig gestellte Fragen

Sollten Platform Engineers immer ein Anschreiben beilegen?

Wenn das Bewerbungsformular ein Anschreiben-Feld hat, füllen Sie es aus. Wenn die Ausschreibung „optional" sagt, behandeln Sie es als Pflicht. Laut einer Umfrage von Robert Half bevorzugen 72 % der Hiring Manager ein Anschreiben, auch wenn es nicht zwingend ist [2]. Für Platform Engineering hebt Sie ein technisches Anschreiben, das auf die Infrastrukturentscheidungen des Unternehmens Bezug nimmt, von den 88 % der Bewerber ab, die generische Schreiben einreichen oder ganz verzichten.

Wie technisch sollte ein Platform-Engineer-Anschreiben sein?

Technisch genug, um Glaubwürdigkeit zu zeigen, aber nicht so technisch, dass es wie Dokumentation liest. Nennen Sie konkrete Tools (ArgoCD, Terraform, Istio) und quantifizieren Sie Ergebnisse, erklären Sie aber nicht, wie ArgoCD funktioniert. Der Leser weiß das. Ihre Aufgabe ist zu zeigen, dass Sie diese Tools genutzt haben, um reale Probleme in relevanter Größenordnung zu lösen.

Ist es in Ordnung, Gehaltsvorstellungen im Anschreiben zu nennen?

Nein. Nennen Sie niemals Gehaltsvorstellungen im Anschreiben, es sei denn, die Ausschreibung verlangt es ausdrücklich. Gehaltsverhandlungen gehören in die Phase nach einem Angebot. Eine frühe Nennung positioniert Sie entweder zu hoch oder verankert Sie unter Marktwert.

Wie schreibe ich ein Anschreiben beim Wechsel von DevOps oder SRE zu Platform Engineering?

Rahmen Sie Ihre bisherige Erfahrung durch die Plattform-Linse. DevOps-Pipeline-Arbeit wird zu „Developer-Self-Service-Deployment-Infrastruktur". SRE-Reliability-Arbeit wird zu „Plattform-SLO-Frameworks, die das Entwicklervertrauen in Produktions-Deployments erhöht haben". Die technischen Fähigkeiten überlappen stark – die Differenzierung liegt darin, wie Sie die Wirkung auf Developer Experience gegenüber operativer Stabilität rahmen.

**Quellen:** [1] Hired, "2025 State of Tech Salaries Report," hired.com/state-of-salaries, 2025. [2] Robert Half, "Cover Letter Survey Results," roberthalf.com/blog, 2024.