Ein Lebenslauf für DevOps oder Platform Engineering überzeugt am ehesten, wenn er Zuverlässigkeit, Bereitschaftsdienst, Infrastrukturmigrationen und Werkzeuge, auf die andere Teams angewiesen sind, in den Vordergrund stellt, statt der feature-lastigen Stichpunkte, die ein allgemeiner Software-Engineering-Lebenslauf üblicherweise verwendet. Beide Lebensläufe teilen sich die meisten Grundbausteine: umgekehrt chronologische Erfahrung, eine kurze Zusammenfassung, einen Skills-Abschnitt und Stichpunkte, die Ergebnisse statt Aufgaben beschreiben. Was sich ändert, ist, welche Ergebnisse in dieser Rolle tatsächlich beeindrucken, denn von Infrastrukturarbeit profitieren meist andere Ingenieurinnen und Ingenieure statt Endnutzer, und die Arbeit selbst bleibt oft unsichtbar, wenn sie gut läuft.
Warum sich der Schwerpunkt verschiebt
Ein von einem Software-Engineer gebautes Feature hat meist ein sichtbares Vorher-Nachher: einen Bildschirm, den es vorher nicht gab, einen Ablauf, der von fünf Schritten auf zwei schrumpft. Infrastruktur- und Plattformarbeit erreicht diesen sichtbaren Effekt selten, weil das beste mögliche Ergebnis oft ist, dass sich aus Nutzersicht nichts ändert: ein Deployment, das früher jemanden um 2 Uhr nachts weckte, tut das jetzt nicht mehr. Ein Lebenslauf für diese Art Rolle muss diese unsichtbare Zuverlässigkeit für eine Leserin greifbar machen, indem er benennt, was von der Arbeit abhing und was ohne sie kaputtgegangen wäre.
Zuverlässigkeit und Verfügbarkeit ehrlich beschreiben
Zuverlässigkeitsarbeit birgt dieselbe Falle wie im Beitrag technische Wirkung im Lebenslauf beziffern, ohne Zahlen zu erfinden beschrieben: eine verlockende, aber nicht überprüfbare Zahl wie "Verfügbarkeit um 40 % verbessert", obwohl eine solche Kennzahl nie wirklich erfasst wurde. Existiert eine echte, derzeit nachweisbare Kennzahl aus einem Dashboard oder einem Vorfallsbericht, gehört sie unverändert in den Lebenslauf. Existiert sie nicht, tragen Umfang und eine beschriebene Vorher-Nachher-Situation dasselbe Gewicht ohne das Risiko: wie viele Dienste von der Änderung betroffen waren, was vorher fehlschlug und danach nicht mehr.
Bereitschaftsdienst und Vorfallreaktion als Lebenslaufinhalt
Bereitschaftsdienst verdient eine direkte Nennung statt einer vagen Zeile wie "Produktionssysteme unterstützt", da er ein Maß an operativer Verantwortung signalisiert, das eine rein feature-orientierte Rolle nicht trägt. Überzeugend ist die Form der Verantwortung: für welches System oder welche Systeme man die Rufbereitschaft trug, wie die Rotation grob funktionierte, und eine konkrete Sache, die sich durch einen bearbeiteten Vorfall geändert hat, etwa ein Runbook, das es danach gab und vorher nicht gab.
Migrationen und Infrastrukturänderungen, die eine Erwähnung wert sind
Eine Migration, eine Plattformänderung oder ein Werkzeugwechsel verdient einen eigenen Stichpunkt, wenn es sich um die Art Projekt handelt, an das sich andere Ingenieurinnen und Ingenieure anpassen mussten, statt um eine rein interne Änderung, die außerhalb des Teams niemand bemerkte. Zu benennen, was sich bewegte und warum, liefert meist mehr Information als die bloße Nennung der Zieltechnologie.
Werkzeuge, auf die andere Teams angewiesen sind
Interne Werkzeuge verdienen dieselbe Behandlung wie ein kundenseitiges Feature: was sie tun, wer sie nutzt und was sie ersetzt haben. Nebenprojekte im Lebenslauf eines Software-Engineers präsentieren beschreibt dieselbe Grundstruktur für Arbeit außerhalb einer formellen Anstellung, und sie passt genauso gut auf ein internes Werkzeug, das innerhalb einer Anstellung entstand.
Illustratives Beispiel: ein Stichpunkt, neu formuliert um Infrastrukturverantwortung
Vorher, vage und feature-förmig: "Arbeit an Infrastruktur und Deployment für das Backend-Team." Nachher, neu formuliert um Verantwortung, Umfang und eine beschriebene Vorher-Nachher-Situation: "Verantwortete die Deployment-Pipeline für die elf Dienste des Backend-Teams; die Pipeline erforderte vorher für jeden Dienst einen manuellen Freigabeschritt vor dem Deployment, und nach der Überarbeitung genügte eine bestandene Testsuite für ein automatisches Deployment, wodurch die Zahl der zum Release-Zeitpunkt benötigten Ingenieurinnen und Ingenieure von drei auf eine sank." Nichts an der zweiten Version ist eine erfundene Statistik.
Eine lange Liste von Werkzeugen und Plattformen gruppieren
Ein Skills-Abschnitt für Platform Engineering läuft oft länger als der eines typischen Entwicklers, da er Cloud-Anbieter, Orchestrierungswerkzeuge, Monitoring-Systeme und Programmiersprachen gleichzeitig umfasst, genau die Art langer, gemischter Liste, die von einer Gruppierung nach Kategorien profitiert statt von einer einzigen unsortierten Zeile.
Erstellen Sie Ihren Lebenslauf
CVBuilderKits Developer-Vorlage ist um projekt- und verantwortungsgeführte Einträge herum gebaut, was Infrastruktur- und Plattformarbeit ebenso gut passt wie Anwendungscode. Starten Sie damit, oder mit einem leeren Dokument, im Editor und überarbeiten Sie Ihre Stichpunkte zu Zuverlässigkeit, Bereitschaftsdienst und Migrationen rund um das, was tatsächlich von der Arbeit abhing, bevor Sie zu einer Zahl greifen, die Sie derzeit nicht belegen können.