Wird ein DevOps-Anschreiben tatsächlich gelesen?

Wer es tatsächlich liest

Bei den meisten Technologieunternehmen durchläuft eine DevOps-Stelle zunächst ein ATS. Ein Recruiter oder Hiring Manager scannt Ihren Lebenslauf nach Stack-Übereinstimmung — Kubernetes, Terraform, AWS oder GCP oder Azure, das von Ihnen verwendete CI-Tool, ob Sie etwas in Produktion betrieben haben und nicht nur in einem Tutorial. Gibt es keine Übereinstimmung, wird das Anschreiben nicht geöffnet. Das ist keine Bewertung Ihres Schreibens, sondern so funktioniert der Trichter, wenn sich auf eine Ausschreibung für eine Mid-Level-DevOps-Rolle Leute bewerben, deren einzige Infrastruktur-Erfahrung ein Uni-Projekt ist.

Gelesen wird das Schreiben später im Prozess oder bei kleineren Unternehmen, wo der Hiring Manager selbst die erste Sichtung macht. In einem Plattform-Team mit sechs Leuten bei einem Series-B-Startup liest oft der leitende Engineer jede Bewerbung direkt, weil es noch keine Recruiter-Ebene gibt. In diesem Setting wird das Schreiben genau gelesen, denn die Person, die es liest, wird um 3 Uhr nachts zusammen mit Ihnen gerufen und möchte wissen, wie Sie eine Incident-Zusammenfassung schreiben, nicht nur, ob Sie Helm kennen.

Die ehrliche Antwort lautet also: Es hängt stark von Teamgröße und Einstellungsprozess ab, und man kann aus der Stellenausschreibung normalerweise nicht erkennen, in welcher Situation man sich befindet. Schreiben Sie es so, als würde ein arbeitender Engineer es lesen, denn manchmal wird einer es tun.

Was es leisten muss, was Ihr Lebenslauf nicht kann

Ihr Lebenslauf listet Tools auf. Er kann sagen "Terraform, Ansible, ArgoCD, Prometheus, Grafana, GitLab CI" und ein Bulletpoint, der eine Migration oder eine Verringerung der Deploy-Zeit behauptet. Was er nicht gut kann, ist zeigen, warum Sie die Entscheidungen getroffen haben, die Sie getroffen haben — und das ist es, was DevOps-Hiring-Manager tatsächlich interessiert, weil der Job hauptsächlich aus Abwägungen unter Einschränkungen besteht: Verschieben Sie den Stateful Service zu Kubernetes oder lassen ihn auf einer Managed Instance, beheben Sie den Flaky Test oder quarantänen ihn, rufen Sie jemanden um 2 Uhr nachts an oder warten Sie bis zum Morgen.

Ein Anschreiben, das für dieses Feld funktioniert, beantwortet ein oder zwei Dinge, nicht mehr:

Passt Ihre Infrastruktur-Erfahrung zur Form ihrer Umgebung. Nicht nur die Tool-Namen, sondern Größenordnung und Reifegrad. "Ran Kubernetes" bedeutet etwas anderes bei einem Fünf-Personen-Startup mit einem EKS-Cluster als bei einem Unternehmen mit vierzig Microservices und einem Plattform-Team. Wenn die Ausschreibung Multi-Cluster, Multi-Region oder ein spezifisches Compliance-Regime (SOC 2, HIPAA, PCI-DSS) erwähnt, sagen Sie direkt, ob Sie in diesem Kontext gearbeitet haben und was konkret dazugehörte — Audit-Logging, Secrets-Rotation-Policy, Change-Management-Approval, was auch immer es war. Vage Behauptungen wie "Erfahrung mit Cloud-Infrastruktur im großen Maßstab" sind genau das, was jeder andere Bewerber schreibt, und sie werden überflogen.

Können Sie einen Incident übernehmen und danach darüber kommunizieren. Das ist spezifisch für DevOps- und SRE-nahe Rollen auf eine Weise, wie es bei den meisten Engineering-Jobs nicht der Fall ist: Sie werden irgendwann die Person sein, die einem Raum oder einem Postmortem-Dokument erklärt, warum etwas ausgefallen ist und was sich dadurch geändert hat. Ein konkreter Satz über einen Ausfall, den Sie diagnostiziert haben, ein Rollback, das Sie ausgeführt haben, oder eine Root Cause, die Sie gefunden haben, schlägt drei Sätze darüber, "leidenschaftlich für Reliability" zu sein. Nennen Sie den Failure Mode, wenn Sie können — ein Bad Deploy, das einen Health Check übersprungen hat, ein Terraform State Lock, der korrupt wurde, ein Zertifikat, das ablief, weil die Erneuerung nicht automatisiert war. Spezifität wirkt hier kompetent, weil sie sehr schwer zu fälschen ist.

Wenn Sie nur eine Sache in ein kurzes Schreiben packen können, machen Sie es zur Incident- oder Ownership-Story, nicht zur Tool-Liste — die Tool-Liste steht bereits in Ihrem Lebenslauf.

Wo das Schreiben wenig Gewicht hat und wo nicht

Seien Sie ehrlich zu sich selbst. Wenn die Rolle bei einer großen Organisation mit strukturierter Pipeline ist — Bewerbung, Recruiter-Screen, Technical Screen, System-Design-Interview, Panel — ist das Schreiben sehr unwahrscheinlich der entscheidende Faktor. Es könnte Sie über einen ersten Filter bringen, wenn es klar von jemandem geschrieben ist, der die Ausschreibung gelesen hat, aber die Take-Home-Aufgabe oder die Whiteboard-System-Design-Runde (Entwerfen Sie eine CI/CD-Pipeline für X, debuggen Sie dieses kaputte Kubernetes-Manifest, erklären Sie, wie Sie MTTR für einen Flaky Service reduzieren würden) ist, wo die eigentliche Entscheidung fällt. Kein Schreiben kompensiert die Unfähigkeit zu erklären, wie sich ein Terraform apply von einem plan unterscheidet, oder was passiert, wenn die Readiness Probe eines Pods während eines Rolling Updates fehlschlägt.

Wo es Gewicht trägt: kleinere Teams, die ihren ersten oder zweiten DevOps-Engineer einstellen, Rollen, die explizit funktionsübergreifende Kommunikation erwähnen (weil Sie Infrastruktur-Entscheidungen Entwicklern erklären, die nicht täglich darüber nachdenken), und jede Rolle, bei der die Ausschreibung selbst ein Anschreiben verlangt und angibt, was darin stehen soll. Wenn eine Ausschreibung sagt "erzählen Sie uns von einem Production Incident, den Sie bearbeitet haben", ist diese Anweisung nicht dekorativ. Sie zu ignorieren oder mit generischer Begeisterung statt dessen zu antworten ist ein größeres Problem, als das Schreiben ganz wegzulassen.

Es gibt auch eine Kategorie von DevOps- und Plattform-Rollen, bei denen ein öffentliches GitHub, ein persönliches Infrastructure-as-Code-Repo oder ein Blogpost über eine Migration mehr leistet als jedes Schreiben könnte. Wenn Sie eines haben, verlinken Sie es im Schreiben selbst, anstatt es im Lebenslauf zu vergraben — ein Hiring Manager, der Ihre tatsächlichen Terraform-Module oder Ihre Ansible-Playbooks sehen kann, bekommt mehr Signal aus zehn Minuten Code-Lesen als aus zehn Minuten Prosa über Ihre Fähigkeiten.

Die unangenehmen Teile handhaben

Wenn Sie von einem Sysadmin- oder NOC-Hintergrund zu einem DevOps-Titel wechseln oder von Software Engineering zu Infrastruktur, sagen Sie es klar und erklären Sie, was Sie bereits getan haben, das sich überschneidet — Deployment-Skripte schreiben, On-Call-Rotationen verwalten, interne Tools bauen — anstatt den Lebenslauf eine Titeländerung ohne Grund implizieren zu lassen. Hiring Manager in diesem Feld sehen viele Sysadmins, die sich neu benennen ohne die Automation- und IaC-Erfahrung, die das untermauert, und ein Schreiben, das spezifisch ist darüber, was Sie tatsächlich automatisiert haben versus was Sie manuell betrieben haben, wirkt glaubwürdiger als eines, das nur den neuen Titel behauptet.

Wenn es eine Lücke gibt oder Sie sich etwas außerhalb des Senioritätsniveaus in der Ausschreibung bewerben, sprechen Sie es in einem Satz an und gehen Sie weiter. Verschwenden Sie keinen Absatz damit, es zu verteidigen — verwenden Sie den Platz für die Infrastruktur-Übereinstimmung und die Incident-Story, denn das sind die Dinge, auf die der Leser tatsächlich achtet.

Was Sie damit tun sollten

Öffnen Sie die Ausschreibung erneut und finden Sie den spezifischen Stack und den spezifischen Pain Point, den sie nennt — eine Migration, eine On-Call-Belastung, ein Reliability-Problem, eine Compliance-Anforderung. Schreiben Sie einen Absatz, der Ihre tatsächliche Erfahrung mit dieser benannten Sache verbindet, mit genug Detail, dass er nicht in eine Bewerbung für ein anderes Unternehmen kopiert werden konnte. Schreiben Sie einen Absatz oder auch nur zwei Sätze, die einen Incident oder ein Projekt beschreiben, bei dem Sie eine Abwägung getroffen haben und es funktioniert hat, wobei Sie den Failure Mode oder die Metrik nennen, die sich geändert hat. Streichen Sie alles andere. Streichen Sie "leidenschaftlich für DevOps-Kultur", streichen Sie "gedeihe in schnelllebigen Umgebungen", streichen Sie alles, was genauso wahr wäre, wenn Sie einen anderen Jobtitel einsetzen würden. Zielen Sie auf unter 250 Wörter — ein Hiring Manager, der dies zwischen Tickets liest, wird nicht mehr lesen, und ein längeres Schreiben kompensiert keine schwächere technische Übereinstimmung. Wenn ein Link zu Ihrem Infrastruktur-Code oder einem relevanten Postmortem existiert, fügen Sie ihn ein.

jobmarket.pro liest die Ausschreibung vollständig und entwirft ein Anschreiben aus Ihrer tatsächlichen Projekt- und Incident-Historie statt generischer Behauptungen, was genau das Problem ist, das dieser Artikel beschrieben hat.