cvharbor editorial

Lebenslauf für DevOps Engineers: Aufbau, Inhalte, Beispiele

Viele Lebensläufe von DevOps Engineers sind eine Tool-Liste: Terraform, Kubernetes, Jenkins, fertig. Ein Personaler geht bei der Berufsbezeichnung ohnehin von Tool-Kenntnissen aus. Was fehlt, ist die Antwort auf die Frage, was sich an den Systemen verändert hat, für die Sie verantwortlich waren.

Der deutsche Lebenslauf folgt einem klaren, tabellarischen Format: rückwärts chronologisch, mit Datum, Position und Unternehmen in fester Struktur, ohne einleitenden Fließtext oder "Summary"-Absatz, wie er im angelsächsischen Raum üblich ist. Diese Form zwingt dazu, jede Station knapp und konkret zu beschreiben – genau das ist die Chance, Ergebnisse statt nur Werkzeuge aufzulisten.

Aufbau des tabellarischen Lebenslaufs

Die Struktur ist in Deutschland weitgehend standardisiert und weicht bewusst nicht ab, weil Personalverantwortliche gewohnt sind, an bestimmten Stellen bestimmte Informationen zu finden.

1. Persönliche Daten: Name, Adresse, Telefonnummer, E-Mail. Geburtsdatum und Geburtsort sind üblich, aber nicht verpflichtend – seit dem Allgemeinen Gleichbehandlungsgesetz (AGG) dürfen Arbeitgeber danach nicht diskriminieren, weshalb manche Bewerbende diese Angaben bewusst weglassen.
2. Bewerbungsfoto: in Deutschland weiterhin verbreitet, aber nicht vorgeschrieben. Ein professionelles Foto vom Fotostudio, kein Selfie und kein Urlaubsfoto. Wer unsicher ist, lässt es weg – ein fehlendes Foto ist inzwischen unauffällig, ein schlechtes Foto schadet.
3. Berufserfahrung: rückwärts chronologisch, mit Format MM/JJJJ – MM/JJJJ, Positionsbezeichnung, Unternehmen, Ort, und darunter zwei bis vier Stichpunkte zu Verantwortung und Ergebnis.
4. Ausbildung: Studium oder Berufsausbildung, ebenfalls rückwärts chronologisch, mit Abschluss und Institution.
5. Kenntnisse: IT-Kenntnisse (Tools, Plattformen, Programmiersprachen), Sprachkenntnisse mit Niveauangabe (z. B. Englisch – verhandlungssicher, C1), gegebenenfalls Zertifizierungen.
6. Ort, Datum und Unterschrift am Ende – bei digitaler Bewerbung häufig als eingescannte oder digitale Unterschrift, zunehmend aber auch ganz weggelassen.

Nicht die Tool-Liste, sondern die Wirkung beschreiben

Wer unter "Kenntnisse" nur Terraform, Kubernetes und Jenkins aufzählt, sagt damit, dass er diese Tools schon einmal geöffnet hat – mehr nicht. Interessant für Personalverantwortliche ist, was mit diesen Werkzeugen erreicht wurde: schnellere Deployments, kürzere Ausfallzeiten, eine Migration ohne Störung des Betriebs. Diese Informationen gehören in die Stichpunkte unter der jeweiligen Station, nicht in die Kenntnisliste.

Der zweite Satz bleibt auch dann unglaubwürdig, wenn die Zahl stimmt, weil kein Ausgangswert und keine Quelle genannt wird. Der erste Satz beschreibt, was langsam war, was konkret verändert wurde und woher die Zahl stammt – genau das, was in einem Vorstellungsgespräch nachgefragt werden kann.

Infrastructure as Code: mehr als der Tool-Name

• Umfang benennen: Wie viele Systeme, Umgebungen oder Konten wurden über Code verwaltet, statt manuell konfiguriert?
• Wirkung benennen: Rollback in Minuten statt Stunden, eine zweite Umgebung aus denselben Modulen aufgesetzt, ein Kollege konnte eine Dev-Umgebung selbst bereitstellen.
• Wiederverwendung erwähnen: Module, die von anderen Teams übernommen wurden, sind ein stärkeres Signal als ein einzelner erfolgreicher Rollout.
• Realistisch bleiben: Ein einzelner Dienst und eine komplette Multi-Account-Infrastruktur sind unterschiedliche Aussagen, und im Gespräch wird nach der tatsächlichen Größenordnung gefragt.

CI/CD-Pipelines und Incident-Erfahrung

Jede CI/CD-Plattform erfüllt im Kern dieselbe Aufgabe. Relevant ist, was die Pipeline verhindert hat und was vorher fehlte. "CI/CD-Pipelines in Jenkins aufgebaut" beschreibt eine Aufgabe. "Einen verpflichtenden Security-Scan eingeführt, der ein hartkodiertes Zugangsdatum vor dem Produktivbetrieb abgefangen hat" beschreibt ein Ergebnis.

Bereitschaftsdienst und Incident-Reaktion werden im deutschen Lebenslauf oft ganz weggelassen, dabei zeigen sie besonders klar, wie jemand unter Druck arbeitet. Wichtig ist der dritte Teil: was wurde danach verändert, damit sich der Vorfall nicht wiederholt.

Cloud-Plattformen: Tiefe statt Logo-Liste

AWS, Azure und GCP nebeneinander in der Kenntnisliste zu nennen, wirkt oberflächlich, wenn keine der drei mit konkreter Erfahrung unterlegt ist. Für ein Team, das überwiegend mit AWS arbeitet, ist relevant, welche Architekturentscheidungen dort tatsächlich getroffen wurden – nicht, wie viele Plattformen einmal berührt wurden.

• Konkrete Dienste nennen (EKS, RDS, Lambda, VPC-Design) statt nur den Anbieternamen.
• Migrationen zwischen Anbietern oder von On-Premise in die Cloud sind aussagekräftiger als eine reine Dienst-Aufzählung.
• Kosteneinsparungen sind eine belastbare Kennzahl, wenn sie einer konkreten Maßnahme zugeordnet werden können (Instanzgrößen angepasst, reservierte Kapazität genutzt, ungenutzte Ressourcen entfernt).
• Zertifizierungen wie AWS Certified Solutions Architect oder Certified Kubernetes Administrator gehören in die Kenntnisliste, ersetzen dort aber keine Projekterfahrung im Berufserfahrungsteil.

Ein fertiges Format für den tabellarischen Lebenslauf erleichtert den Einstieg in die Struktur. Lebenslauf erstellen

Sprachkenntnisse und Zertifizierungen richtig angeben

Deutsche Arbeitgeber erwarten bei Sprachkenntnissen eine Niveauangabe nach dem Gemeinsamen Europäischen Referenzrahmen (GER/CEFR), etwa "Englisch – verhandlungssicher (C1)" statt nur "fließend". Für internationale DevOps-Rollen mit Remote-Teams ist das Sprachniveau oft ein eigenes Auswahlkriterium und sollte nicht in einer Nebenbemerkung untergehen.

Vor dem Absenden prüfen

• Folgt der Lebenslauf der tabellarischen Struktur mit rückwärts chronologischer Berufserfahrung?
• Sind die Datumsangaben im Format MM/JJJJ durchgängig einheitlich?
• Beschreibt jeder Stichpunkt eine Veränderung, nicht nur eine Zuständigkeit?
• Lässt sich jede genannte Zahl auf ein Dashboard, Ticket oder Postmortem zurückführen?
• Ist bei mindestens einer Cloud-Plattform erkennbar, dass echte Architekturentscheidungen getroffen wurden?