Portfolio Projects for DevOps Engineer

Du hast drei Zertifikate, einen leeren GitHub-Account und wirst trotzdem nicht zum Gespräch eingeladen. Das ist kein Zufall. Bei DevOps-Rollen will niemand wissen, was du gelernt hast, sondern was du gebaut, kaputt gemacht und wieder repariert hast.

Zertifikate belegen Grundwissen. Sie zeigen aber nicht, ob du eine Pipeline entwerfen, ein Problem eingrenzen oder eine Entscheidung begründen kannst. Genau das wird im Bewerbungsprozess abgefragt. Dafür brauchst du Projekte, die man sich anschauen kann.

Warum Projekte mehr wiegen als Zertifikate#

Ein Recruiter sieht in deiner Bewerbung zwei Dinge: Zertifikate und Projekte. Zertifikate sind bei vielen Kandidaten gleich. Projekte sind es nicht. Sie zeigen Urteilskraft, und Urteilskraft ist das, worum es bei DevOps eigentlich geht.

Ein Reviewer verbringt mit deinem Profil selten mehr als zwei bis drei Minuten. In dieser Zeit sucht er nach konkreten Artefakten: eine Pipeline, ein Deployment, ein Monitoring-Setup, eine Entscheidung, die du erklären kannst. Ohne diese Artefakte springt er weiter.

Was Reviewer wirklich anschauen#

Die meisten Bewerber zeigen ein Tutorial nachgebaut. Ein Terraform-Repo, das einem YouTube-Video folgt. Eine CI-Pipeline mit genau einem Build-Schritt. Das erkennt ein erfahrener Reviewer sofort.

Was ihn überzeugt, ist etwas anderes.

• Du hast eine Entscheidung getroffen und kannst sagen, warum nicht die Alternative.
• Es gibt eine Form von Messung: Logs, Metriken, eine Fehlerquote, eine Deploy-Dauer.
• Das Projekt hat eine Grenze, also du weißt, was es nicht abdeckt.
• Der README erklärt Kontext, nicht nur Installationsschritte.
• Es gibt eine Version, die kaputt war, und du kannst beschreiben, was du daraus gelernt hast.
• Der Code sieht aus wie Arbeit, nicht wie ein Lehrbuch: Kommentare an den schwierigen Stellen, nicht überall.

Drei Projekte, die sich lohnen#

Projekt 1: Eine Deployment-Pipeline mit echtem Feedback

Baue eine CI/CD-Pipeline, die eine Anwendung baut, testet und auf eine Staging-Umgebung deployt. Wichtig ist der Feedback-Teil: Die Pipeline soll bei einem Fehler stoppen und eine verständliche Meldung liefern.

Nimm eine kleine Webanwendung, die du selbst geschrieben hast, zum Beispiel ein API-Service mit zwei Endpunkten. Die Pipeline läuft bei jedem Push, baut ein Container-Image, führt Unit-Tests aus und deployed nach Staging. Das Deployment dauert unter zehn Minuten, und du hast eine Möglichkeit, es zurückzunehmen.

Der interessante Teil ist nicht das Deployment. Es ist die Frage, was passiert, wenn ein Test fehlschlägt. Zeig das im README mit einem Screenshot der Fehlermeldung und beschreibe, wie du sie verbessert hast.

Projekt 2: Infrastruktur als Code mit einem echten Szenario

Terraform allein ist kein Projekt. Ein Szenario ist ein Projekt. Beschreibe einen konkreten Fall: Zum Beispiel eine Umgebung, die du mit einem Befehl aufbauen und mit einem Befehl zerstören kannst, mit getrennten Netzwerken für Datenbank und Anwendung.

Baue das Ganze in einem Cloud-Free-Tier oder lokal mit etwas wie Minikube und einem Terraform-Provider dafür. Zeige, wie du Zustand verwaltest, wie du Secrets aus dem Code hältst und was passiert, wenn jemand parallel etwas ändert.

Dann mach etwas, das fast niemand macht: Zerstö die Umgebung und baue sie neu auf. Halte fest, wie lange das dauert und was dabei schiefging. Das ist ein Satz im README, der mehr beweist als zehn Seiten Dokumentation.

Projekt 3: Monitoring und Incident-Response

Richte für deine Anwendung Monitoring ein, zum Beispiel mit Prometheus und Grafana, und definiere zwei Alarme. Einer für hohe Fehlerquote, einer für langsame Antworten. Dann simuliere einen Ausfall und dokumentiere, wie schnell der Alarm kam und was du getan hast.

Dieses Projekt zeigt etwas, das Zertifikate nie zeigen: Du denkst in Ausfällen. Schreibe im README eine kurze Postmortem. Was war die Ursache, wie hast du sie gefunden, was hättest du früher erkennen können.

So präsentierst du die Projekte auf GitHub#

Der README ist das, was gelesen wird. Der Code ist das, was überflogen wird. Schreib den README für jemanden, der keine Zeit hat.

• Ein Satz am Anfang: Was das Projekt macht und für welches Problem.
• Eine Architekturskizze, selbst als Text-Block mit Pfeilen, ist besser als nichts.
• Abschnitt "Entscheidungen" mit zwei oder drei Punkten, wo du Alternativen verworfen hast.
• Abschnitt "Was fehlt" oder "Grenzen", ehrlich und kurz.
• Ein Abschnitt "Was ich gelernt habe", ein oder zwei Sätze, keine Lebensweisheiten.
• Ein reproduzierbarer Start: Welche Tools braucht man, welcher Befehl startet es.

Lösche Repositories, die nur aus einem Fork und einem halben Commit bestehen. Fünf durchdachte Repositories wirken besser als zwanzig halbfertige.

So nimmst du die Projekte in den Lebenslauf auf#

Viele schreiben: "Erfahrung mit Docker, Kubernetes, Terraform". Das steht bei allen. Schreib stattdessen, was du damit gemacht hast.

Vorher: "Kenntnisse in CI/CD, Docker und Kubernetes"

Nachher: "Deployment-Pipeline für einen Node-Service gebaut, Build-Zeit von 12 auf 4 Minuten gesenkt durch gezieltes Caching, automatisches Rollback bei fehlgeschlagenem Health-Check ergänzt"

Die Zahl muss stimmen, die du auch im Gespräch verteidigen kannst. Wenn du keine Zahl hast, nenn stattdessen den Effekt: "Rollback manuell nötig, jetzt automatisch nach drei Fehlversuchen".

Wenn du Hilfe beim Formulieren brauchst, wirf einen Blick auf die kostenlosen Karriere-Tools und Vorlagen für Lebensläufe und Anschreiben.

So redest du im Interview darüber#

Erwarte Fragen wie: "Warum hast du X und nicht Y genommen?" oder "Was wäre anders, wenn das System zehnmal so viele Nutzer hätte?" Diese Fragen prüfen, ob das Projekt wirklich deins ist.

Eine gute Antwortstruktur:

"Wir brauchten Deployments, die schnell zurücknehmbar sind. Ich habe erst manuelle Deploys über ein Skript gemacht, das hat für ein Team funktioniert. Als wir auf zwei Services gewachsen sind, habe ich das zu einer Pipeline mit Health-Checks umgebaut. Die Alternative war ein fertiges Deployment-Tool, das habe ich verworfen, weil es für unsere Größe zu viel Betriebsaufwand bedeutet hätte."

Drei Sätze. Problem, Schritt, Begründung. Keine Werkzeugliste.

Wenn du eine Frage nicht beantworten kannst, sag das direkt und beschreibe, wie du es herausfinden würdest. Das kommt besser an als eine Ausrede.

Fehler, die Projekte nach Tutorial aussehen lassen#

• Der README besteht nur aus Installationsbefehlen ohne Kontext.
• Alles ist perfekt. Kein Fehler, keine Nacharbeit, keine offenen Punkte.
• Du hast nur die Standardkonfiguration übernommen, ohne sie zu verstehen.
• Es gibt keine Version, die du hättest erklären können, bevor du sie verbessert hast.
• Die Repo-Beschreibung ist leer oder heißt "devops-project".
• Du hast das Projekt nie jemandem gezeigt, bevor du dich beworben hast.

Punkt sechs ist der häufigste. Zeig das Projekt einem Kollegen oder in einer Community und frag: "Was würdest du hier nachfragen?" Die Antworten sind wertvoller als jede Zertifikatsprüfung.

Wenn du passende Stellen suchst, schau dir die aktuellen DevOps-Stellenangebote an, um ein Gefühl dafür zu bekommen, welche Projekte in deiner Zielbranche gefragt sind. Und wenn du eine konkrete Stellenbeschreibung hast, hilft dir ein kostenloser Job-Analyse-Decoder dabei, die geforderten Projekte herauszufiltern. Vor dem Absenden kannst du mit dem kostenlosen ATS-Checker testen, ob dein Lebenslauf die relevanten Begriffe überhaupt enthält.

Häufige Fragen#

Wie viele Projekte brauche ich für eine DevOps-Bewerbung?

Drei durchdachte Projekte reichen für die meisten Bewerbungen. Fünf halbfertige sind schlechter als drei, die du erklären kannst.

Soll ich Zertifikate ganz weglassen?

Nein. Zertifikate helfen beim ersten Filter, besonders bei größeren Firmen. Aber ohne Projekte bringen sie dich selten ins Gespräch.

Müssen die Projekte auf AWS oder einer bestimmten Cloud laufen?

Nein. Lokale Setups mit Docker, Minikube oder einem Free-Tier sind völlig in Ordnung. Entscheidend ist, dass du die Architektur und deine Entscheidungen erklären kannst.

Wie aktuell müssen die Projekte sein?

Ein Projekt von vor zwei Jahren ist kein Problem, wenn du es erklären kannst. Wichtiger ist, dass die verwendeten Tools nicht komplett veraltet sind.

Was mache ich, wenn ich keine berufliche DevOps-Erfahrung habe?

Dann sind private Projekte der einzige Weg, und genau deshalb zählen sie. Beschreibe im README den Kontext klar, damit erkennbar ist, dass es eine Übung ist, aber ernsthaft gemacht.