cvharbor editorial

Quereinstieg Cloud und DevOps: der Lebenslauf, der im Gespräch standhält

Wer einen Lebenslauf für den Quereinstieg in Cloud oder DevOps liest, prüft eine Sache: Kann diese Person verantwortungsvoll mit Produktivsystemen umgehen. Eine Wand aus Zertifikatslogos beantwortet das nicht. Ein sauber beschriebenes Projekt schon.

Wer aus dem IT-Support, der Systemadministration oder dem Netzwerkbereich kommt, bringt meist mehr mit als der aktuelle Titel vermuten lässt. Ticketsysteme, Patchzyklen, Rufbereitschaft, das sind alles Bausteine, die in der Cloud- und DevOps-Welt gebraucht werden, nur unter anderem Namen. Das Problem beim Lebenslauf ist selten fehlende Substanz. Es ist, dass diese Substanz noch nie in die Begriffe übersetzt wurde, nach denen eine Personalabteilung sucht.

Zertifikate sammeln bringt weniger als gedacht

Zertifikate wirken als Filter in der Bewerberauswahl, nicht als Einstellungsgrund. Wer ein eindeutig relevantes Zertifikat weglässt, verliert Treffer bei Stichwortsuchen in Bewerbermanagementsystemen, das lohnt sich also aufzunehmen. Der Fehler liegt darin, das Zertifikat selbst als Leistung zu präsentieren, wenn die eigentliche Leistung das ist, was danach damit gemacht wurde.

Welche Zertifikate tatsächlich etwas bewegen

Das hängt von der Zielrolle und dem Arbeitgeber ab, aber ein paar Muster ziehen sich durch den deutschen Markt. Associate-Level-Zertifikate der großen Anbieter, AWS Solutions Architect Associate, Azure Administrator, Google Associate Cloud Engineer, werden erkannt und in Stellenanzeigen aktiv gesucht. Einsteiger-Badges wie "Fundamentals" oder "Practitioner" zeigen, dass man sich mit dem Marketingmaterial beschäftigt hat, mehr nicht, und erfahrene Personaler wissen das. CKA (Certified Kubernetes Administrator) und die Terraform-Associate-Zertifizierung zählen im DevOps-Umfeld mehr, weil beide Prüfungen praktisch sind und nicht per Multiple Choice funktionieren.

• Lohnt die Lernzeit: ein Associate-Zertifikat eines Cloud-Anbieters, ausgewählt nach den Stellenanzeigen, auf die tatsächlich beworben wird, nicht nach dem günstigsten Prüfungsgutschein.
• Lohnt sich speziell für DevOps: CKA oder Terraform Associate, beide praxisorientiert statt reiner Wissensabfrage.
• Wirkt aufgebläht statt überzeugend: mehrere "Fundamentals"- oder "Practitioner"-Badges verschiedener Anbieter. Eines ist ein vernünftiger Einstieg, drei wirken wie das Vermeiden der schwereren Prüfung.
• Eher überspringen, außer die Stellenanzeige nennt es namentlich: herstellerspezifische Zertifikate weit über dem eigenen Erfahrungsstand, oder Zertifikate für Tools, die die Zielunternehmen gar nicht einsetzen.

Lab-Projekte beschreiben, was sie sind, nicht mehr

Ein Homelab oder ein privates Projekt ist eine legitime Referenz. Es als Berufserfahrung in Produktivumgebungen darzustellen, fliegt im Gespräch schnell auf, denn Nachfragen wie "Wie viel Traffic lief darüber" oder "Wer war noch im Bereitschaftsdienst" haben bei einem Soloprojekt keine ehrliche Antwort. Wer das Projekt korrekt beschreibt, lässt den Inhalt für sich sprechen.

Die ehrliche Version überzeugt mehr, nicht weniger. Sie nennt konkrete Werkzeuge, zeigt, dass über Ausfälle nachgedacht wurde, und verlinkt etwas Nachprüfbares. Die übertriebene Version fordert eine Frage heraus, die sie nicht übersteht: welches Unternehmen, wessen SLA.

Private und Lab-Projekte gehören in einen eigenen, klar benannten Abschnitt, getrennt vom tabellarischen Werdegang. Wer sie wie reguläre Arbeitgeber in den beruflichen Werdegang mischt, riskiert, dass es genau dort auffällt, wo es am wenigsten verzeihlich ist.

Die aktuelle Rolle in Infrastruktursprache übersetzen

IT-Support und Systemadministration bringen die Fähigkeiten mit, nach denen DevOps-Stellenanzeigen fragen, nur unter anderer Bezeichnung. Ein Ticketsystem ist ein Incident-Workflow. Ein Patchplan ist Configuration Management. Die gleiche Erfahrung in der Zielsprache zu beschreiben ist keine Übertreibung, sondern präzisere Beschreibung mit Begriffen, die die Zielrolle erkennt.

Beide beschreiben dieselbe Stelle. Die erste Version hebt hervor, was für eine DevOps-Personalauswahl zählt: Automatisierung, Skalierung, messbar eingesparte Zeit, Dokumentation. Nichts davon ist erfunden, es ist dieselbe Tätigkeit, nur vollständig gelesen statt nur oberflächlich beschrieben.

Was aus angrenzenden IT-Rollen wirklich übertragbar ist

• Skripterfahrung, auch nur einfaches Bash oder PowerShell für wiederkehrende Aufgaben, ist derselbe Reflex, der Infrastructure as Code antreibt.
• Netzwerkgrundlagen aus Support oder Netzwerktechnik, Subnetze, DNS, Load Balancer, lassen sich fast unverändert auf Cloud-Netzwerkkonzepte übertragen.
• Erfahrung mit Bereitschaftsdienst und Störungsbehebung, auch informell, liegt näher an SRE-Arbeit, als viele annehmen. Unter Druck triagieren und eskalieren ist der eigentliche Kern des Jobs.
• Linux-Administration, Paketverwaltung, systemd, Logdateien lesen, überträgt sich fast unverändert in Cloud- und Container-Umgebungen.
• Dokumentationsgewohnheiten: Wer bereits Runbooks und Change-Tickets pflegt, gewöhnt sich schneller an Infrastrukturdokumentation als jemand, der bei null anfängt.

Zertifikate und Lab-Projekte lassen sich in eigenen Abschnitten aufführen, während der berufliche Werdegang chronologisch und ehrlich bleibt. Lebenslauf erstellen

Was ein Lab-Projekt nicht ersetzen kann

Ehrlichkeit sich selbst gegenüber hilft hier mehr als Beschönigung: Ein Solo-Deployment mit Terraform kennt kein Code-Review, kein Change-Approval, keine Rufbereitschaft, keine Postmortem-Kultur. Diese Lücke im Gespräch offen zu benennen und zu sagen, wie man sich der Sache annähern würde, wirkt reflektiert. Sie zu verschweigen fällt spätestens bei der ersten Frage zu einem realen Skalierungsszenario auf.

Vor dem Absenden prüfen

• Ist jedes Zertifikat mit einem Projekt im selben Lebenslauf verknüpft, statt allein aufgelistet zu stehen?
• Sind Lab- und Privatprojekte klar als solche gekennzeichnet, in einem eigenen Abschnitt, nicht im beruflichen Werdegang vermischt?
• Ist die aktuelle oder letzte IT-Rolle in Infrastruktursprache übersetzt, ohne Umfang oder Verantwortung zu erfinden, die es nicht gab?
• Nennt jede Projektbeschreibung konkrete Werkzeuge und mindestens einen Punkt, der getestet wurde oder schiefgelaufen ist, statt nur, was gebaut wurde?
• Passt die angestrebte Senioritätsstufe realistisch zu dem, was Projekte und Zertifikate tatsächlich belegen?