Anmelden Registrieren Dashboard

Alle Stellenbeschreibungen

Deutschland IT & Informatik Mittlere Erfahrung

DevOps Engineer:in

Stellenausschreibung, Gehalt, Sourcing, 15 Interviewfragen und 30/60/90-Plan, um DevOps Engineer:innen im KMU oder Mittelstand in Deutschland einzustellen.

Zusammengestellt vom Join-Team auf Basis öffentlicher Daten und unserer Recruiting-Erfahrung.

Aktualisiert

Auf einen Blick

  • Mediangehalt 72.000 € 58.000 € – 92.000 €
  • Einstellungsdauer 55–80 Tage
  • Erfahrung 3–7 Jahre

So stellen Sie einen DevOps Engineer ein

Bevor Sie die Stellenausschreibung schreiben, klären Sie drei Fragen. Sie entscheiden, welches Profil Sie tatsächlich suchen, und vermeiden die häufigsten Fehler bei DevOps-Einstellungen im deutschen KMU.

Frage 1: DevOps Engineer:in, SRE oder Plattform-Engineer:in? Die Grenzen sind in deutschen KMU oft fließend, aber die Schwerpunkte unterscheiden sich. DevOps Engineer:innen fokussieren auf den Lieferpfad: CI/CD, Deployment-Automatisierung, Tooling für App-Teams, Infrastructure-as-Code. SRE-Profile konzentrieren sich auf Zuverlässigkeit (SLOs, Error Budgets, Incident-Response, Observability, Capacity-Planning). Plattform-Engineer:innen bauen die interne Plattform als Produkt für die Entwicklungs-Teams. Im KMU mit weniger als 30 Entwickler:innen übernimmt eine DevOps-Rolle in der Regel Anteile aller drei Profile ; eine reine SRE- oder Plattform-Engineering-Rolle lohnt sich erst ab etwa 30 bis 50 Entwickler:innen. Wenn Ihr Team unter 5 Entwickler:innen liegt und Sie noch keine Cloud-Infrastruktur betreiben, ist häufig ein:e Fullstack-Profil mit DevOps-Affinität die richtige Wahl, nicht eine dedizierte DevOps-Rolle.

Frage 2: Welche Cloud-Stack haben Sie und wie reif ist sie? Ein:e gute:r DevOps Engineer:in mit AWS und Terraform wird nicht sofort auf Azure mit Pulumi produktiv, sondern braucht 3 bis 6 Wochen Einarbeitung. Für ein Mid-Level-Profil zählt Stack-Fit oft mehr als absolute Seniorität. Stellen Sie Ihre Stack prominent in der Ausschreibung dar (Cloud-Anbieter, Orchestrierung, IaC-Tool, CI/CD-System, Observability-Stack, Secrets-Management) ; das filtert schlecht passende Profile automatisch aus. Wenn Ihre Stack als Legacy gilt (klassische Jenkins-Pipelines mit shell scripts, On-Prem-VMware, keine IaC), kommunizieren Sie das offen und suchen gezielt Profile, die Modernisierung mögen, statt enttäuschte Wechsler:innen zu importieren.

Frage 3: Welche Systemkomplexität und Compliance bedienen Sie heute, welche in 18 Monaten? Ein:e Mid-Level-DevOps-Profil in einem Cluster mit 5 Services und einem Cloud-Konto trifft täglich andere Entscheidungen als in einem System mit 30 Services, mehreren Cloud-Konten, Multi-Region-Setup und BaFin- oder KRITIS-Compliance. Das ideale Profil unterscheidet sich: Pragmatismus und Tool-Aufbau im ersten Fall, tiefe Erfahrung mit verteilten Systemen, Observability und Compliance-Auditierbarkeit im zweiten. Klären Sie diese Dimension bereits in der Ausschreibung und richten Sie die Architektur-Diskussion an Ihrer realen Komplexität aus, nicht an einer hypothetischen Skala.

Wenn alle drei Antworten auf eine:n DevOps Engineer:in in Vollzeit deuten (und nicht auf eine:n Fullstack-Profil oder eine:n dedizierte:n SRE), gehen Sie zur Vorlage weiter unten.

Stellenausschreibung (Vorlage)

.docx herunterladen

DevOps Engineer:in (m/w/d): Plattform- und Produktionsbetrieb im KMU

[Firmenname], B2B-KMU [Branche] mit Sitz in [Stadt], [X] Mitarbeitende, [X] M€ ARR, sucht eine:n DevOps Engineer:in zur Verstärkung eines Engineering-Teams von [X] Entwickler:innen.

Ihre Aufgabe

Sie entwerfen, bauen und betreiben unsere Plattform (Cloud-Infrastruktur, Kubernetes-Cluster, CI/CD-Pipelines, Observability, Secrets-Management, Backup- und Disaster-Recovery), eigenständig auf bekannten Themen und in Abstimmung bei strukturierenden Entscheidungen. Sie tragen Mitverantwortung für den Produktionsbetrieb (On-Call oder Bereitschaft je nach Organisation) und befähigen die App-Teams, sichere und beobachtbare Services in Produktion zu bringen. Sie berichten an die [Tech Lead / CTO / Technische Geschäftsführung].

Hauptverantwortlichkeiten

  • Cloud-Infrastruktur und Kubernetes-Plattform als Infrastructure-as-Code entwerfen, bauen und betreiben (Terraform, Helm, Argo CD oder vergleichbar).
  • CI/CD-Pipelines aufbauen und weiterentwickeln: reproduzierbare Builds, gestaffelte Tests, sichere Deployments (Rolling, Blue-Green, Canary je nach Risiko).
  • Observability-Stack betreiben und weiterentwickeln (zentrale Logs, Metriken, verteiltes Tracing, SLO- und Error-Budget-Hygiene, sinnvolle Alarme).
  • Bei Produktionsvorfällen federführend oder unterstützend mitwirken (On-Call oder Bereitschaft), Post-mortems mitschreiben, Runbooks aktualisieren, systemische Fixes umsetzen.
  • Security- und Compliance-Anforderungen auf der Plattform-Ebene umsetzen (IAM, Secrets-Manager, Network Policies, Image-Signing, Audit-Logs, Policy-as-Code).
  • Self-Service-Workflows und Templates für die App-Teams bauen, damit Entwickler:innen sichere Services eigenständig in Produktion bringen können.
  • Wichtige technische Entscheidungen und nicht-triviale Komplexitätszonen dokumentieren (ADR oder gleichwertig).
  • Mit Entwicklungs-Teams, Sicherheits- und Datenschutz-Funktionen, PM und Geschäftsführung an Plattform-Roadmap und konkreten Anforderungen zusammenarbeiten ; nicht machbare oder kontraproduktive Vorgaben konstruktiv herausfordern.

Profil

  • Unverzichtbar: [3 bis 7] Jahre professionelle Erfahrung im DevOps-, SRE- oder Plattform-Engineering-Umfeld ; solide Beherrschung mindestens einer großen Cloud (AWS, GCP, Azure) inklusive IAM, Netzwerk und Compute ; Erfahrung mit Container-Orchestrierung (Kubernetes oder vergleichbar), Infrastructure-as-Code (Terraform, Pulumi, CloudFormation), CI/CD-Pipelines und Observability-Stacks (Prometheus, Grafana, Datadog oder vergleichbar) ; eigenständige Produktionsverantwortung mit On-Call oder Bereitschafts-Erfahrung.
  • Wünschenswert: Vertrautheit mit unserer Stack [zu ergänzen] ; Erfahrung mit GitOps (Argo CD, Flux), Service Mesh, Policy-as-Code (OPA Gatekeeper, Kyverno) oder Compliance-lastigen Umfeldern (BaFin, KRITIS, ISO 27001) ; Open-Source-Beiträge oder sichtbare Side-Projects (Terraform-Module, Helm-Charts, kubectl-Plugins).
  • Disqualifizierend: keine Erfahrung mit eigenständigem Produktionsbetrieb ; pauschale Ablehnung von On-Call oder Bereitschaft trotz operativer Anforderung ; pauschale Ablehnung von Infrastructure-as-Code oder Observability als Bürokratie.

Was wir bieten

  • Bruttojahresvergütung: [58 bis 92] k€ je nach Erfahrung. Kein strukturelles Variabel ; eventuell VSOP oder ESOP je nach Phase des Unternehmens. On-Call-Vergütung als Bereitschaftspauschale plus Einsatzstunden separat geregelt.
  • Modell: [Vollzeit, hybrid 2 bis 3 Tage / Woche vor Ort, Basis in [Stadt] / remote-friendly].
  • Benefits: [betriebliche Altersvorsorge, Fahrrad-Leasing, Mitarbeiterbeteiligung, Urlaubstage, Homeoffice-Policy, Hardware-Budget, Weiterbildungsbudget, Konferenzen].
  • Stack: [zu ergänzen: Cloud-Anbieter, Orchestrierung, IaC-Tool, CI/CD-System, Observability-Stack, Secrets-Management, Backup- und DR-Setup].

Gehaltsband

Festgehalt, brutto pro Jahr

25. Perzentil
58.000 €
Median
72.000 €
75. Perzentil
92.000 €

Bruttofixgehalt pro Jahr für eine:n DevOps Engineer:in auf Mid-Level (3 bis 7 Jahre Berufserfahrung) im deutschen KMU oder Mittelstand. Berlin, München und Hamburg im SaaS- und Scale-up-Umfeld ziehen nach oben (85 bis 105 k€), klassischer Mittelstand und Provinzstandorte tendenziell nach unten (55 bis 68 k€). Kubernetes in Produktion, AWS- oder GCP-Erfahrung mit IAM- und Netzwerk-Tiefe sowie Terraform-Modul-Ownership ziehen nach oben ; reine Jenkins- oder On-Prem-VMware-Profile ohne Cloud-Erfahrung tendenziell nach unten. Compliance-lastige Umfelder (BaFin, KRITIS, Versicherung, Health) ziehen erkennbar nach oben. Engineering-Rollen in Deutschland haben in der Regel keinen variablen Vergütungsanteil ; Scale-ups bieten ergänzend VSOP oder ESOP. On-Call-Vergütung wird oft separat als Bereitschaftspauschale plus Einsatzstunden geregelt.

Quellen: Destatis Verdiensterhebung (April 2025), Berufsgruppe 43 IKT-Berufe ; StepStone Gehaltsreport 2026, DevOps Engineer Deutschland ; Glassdoor Gehaltsdaten DevOps Engineer Deutschland 2026 ; Honeypot State of Software Engineering Germany 2025

Wo Sie diese Rolle finden

  1. LinkedIn

    Recruiter Lite ab 170 € / Monat, plus 200 bis 400 € / Monat für Job Slots

    Der wichtigste aktive Sourcing-Kanal für DevOps-Profile in Deutschland. Aktives Sourcing über Recruiter Lite plus personalisierte InMails schlägt reine Job Posts deutlich: erfahrene DevOps Engineer:innen suchen selten aktiv, sind aber für gezielte Ansprache mit klarem Stack- und Skalierungs-Bezug offen. Filtern Sie präzise auf Kubernetes, Terraform, AWS oder GCP, Observability-Stacks (Prometheus, Datadog, Grafana) und auf Erfahrung mit On-Call sowie Incident-Response, bevor Sie anschreiben. Generische Sequenzen liegen unter 5 % Antwortquote ; präzise Nachrichten mit konkretem Stack- und Skalierungs-Bezug erreichen 15 bis 25 %.

  2. XING

    ProJobs ab 195 € / Monat

    Für DevOps-Profile im klassischen Mittelstand außerhalb der Berliner Startup-Szene weiterhin relevant, vor allem in NRW, Bayern und Baden-Württemberg. Besonders für Profile zwischen 30 und 50 Jahren mit Linux- und Netzwerk-Hintergrund (frühere SysAdmin- oder Site-Reliability-Rollen) in Versicherungen, Industrie 4.0 oder Maschinenbau, die LinkedIn nicht aktiv pflegen. In klassischen Industriebranchen oft pari mit LinkedIn oder besser. Für reine Cloud-native- und Kubernetes-Profile schwächeres Signal als LinkedIn ; für hybride On-Prem-zu-Cloud-Migrationen das stärkere Signal.

  3. heise jobs, Honeypot, We Are Developers

    heise jobs 800 bis 1 500 € pro Anzeige (30 Tage), Honeypot Erfolgshonorar 15 % des Jahresfixgehalts

    heise jobs spricht das klassische deutsche Tech-Publikum an, das die iX und c't liest ; hohe Signalqualität für Profile mit Linux-, Netzwerk- und Security-Tiefe, oft im Mittelstand und Behördenumfeld verankert. Honeypot ist die DE-spezifische Tech-Reverse-Recruiting-Plattform: DevOps-Profile erstellen Profile mit Stack und Gehaltsvorstellung, Unternehmen bewerben sich. Funktioniert besonders gut für Senior-Profile mit Kubernetes- oder Cloud-Native-Erfahrung. Insgesamt geringeres Volumen als LinkedIn und XING, aber deutlich höhere Signalqualität pro Kontakt.

  4. Stack Overflow Jobs, GitHub Sponsorings, Empfehlungen

    Stack Overflow Jobs ab 500 € pro Anzeige (30 Tage), Empfehlungsbonus 1 500 bis 3 000 €

    Stack Overflow Jobs liefert in Deutschland geringeres Volumen als LinkedIn, aber Profile mit sichtbarem Stack-Engagement (hohe Reputation in DevOps-, Kubernetes- oder Terraform-Tags) sind oft besonders technisch tief. GitHub-Sponsorings und sichtbare Open-Source-Beiträge geben für Senior-DevOps-Profile zusätzliches Signal (Helm-Chart-Maintainer:innen, Terraform-Modul-Autor:innen, kubectl-Plugin-Entwickler:innen). Empfehlungen aus dem eigenen Engineering-Team liefern bei DevOps-Rollen erfahrungsgemäß die höchste Trefferquote: das DACH-DevOps-Netzwerk ist klein und gut vernetzt. Setzen Sie ein Empfehlungs-Bonus-Programm von 1 500 bis 3 000 € auf.

Alle Jobbörsen in diesem Markt vergleichen →

Evaluations-Playbook

Die Rolle der DevOps Engineer:in zeigt sich über vier Evaluations-Stufen. Die Incident- und Architektur-Stufe (Stufe 3) ist für diese Rolle die prädiktivste: DevOps-Profile treffen täglich Entscheidungen zu Infrastruktur, Deployment-Strategie und Observability, die später schwer rückbaubar sind und im Produktionsbetrieb sichtbar werden.

  1. Stufe 1: CV-Lektüre

    Suchen Sie nach Stack-Konsistenz (ein Profil mit AWS und Terraform wechselt nicht ohne 3 bis 6 Monate Einarbeitung zu Azure und Pulumi), Stabilität (mindestens 18 bis 24 Monate auf vorherigen Positionen) und konkreten Produktionssignalen (eigenständig betriebene Cluster, On-Call-Erfahrung, sichtbares GitHub mit IaC-Modulen oder kubectl-Plugins, Mitarbeit an Post-mortems oder Runbooks). Der Abschluss zählt weniger als die letzten 3 bis 5 Jahre Praxis: ein:e Autodidakt:in mit 5 Jahren On-Call und Kubernetes in Produktion skaliert oft besser als ein:e Top-Uni-Absolvent:in ohne Pager-Erfahrung.

  2. Stufe 2: Phone Screen (30 Min.)

    Nur vier Fragen: (1) Beschreiben Sie die Infrastruktur, für die Sie zuletzt verantwortlich waren ; was war Ihr Beitrag?, (2) Erzählen Sie mir vom jüngsten Production-Incident, den Sie federführend bearbeitet haben., (3) Welche technische Entscheidung haben Sie kürzlich getroffen, an der Sie noch zweifeln? (Demut und Reflexion), (4) Warum suchen Sie jetzt einen Wechsel? Ergebnis: Go/No-Go in 5 Min. Debrief. Vermeiden Sie technische Gotcha-Fragen auf dieser Stufe.

  3. Stufe 3: Technisches Interview und Architektur (90 Min.)

    Zwei Teile: 40 bis 50 Min. Incident-Walkthrough auf einem realen Vorfall der:des Kandidat:in (Symptom, Hypothesen, Validierung, Grundursache, systemischer Fix, was beim nächsten Mal anders), gefolgt von 30 bis 40 Min. Architektur-Diskussion zu einem konkreten Fall (Wie würden Sie [konkrete Plattform-Komponente] aufbauen? Welche Trade-offs?). Bewerten Sie die Fähigkeit, laut zu denken, Annahmen vor der Lösung zu klären (erwartetes Volumen, Konsistenzgarantien, Failover, Compliance), zwischen Einfachheit und Skalierbarkeit abzuwägen und Unsicherheitszonen zu erkennen. Vermeiden Sie reine Trivia-Fragen ; bevorzugen Sie Fragen mit Bezug zum Tagesgeschäft.

  4. Stufe 4: Referenzen (strukturierte Überprüfung)

    Rufen Sie zwei Referenzen an: eine:n ehemalige:n Tech Lead oder direkte:n Vorgesetzte:n und eine:n ehemalige:n Engineering-Kolleg:in (Dev oder DevOps). Stellen Sie beiden dieselben 4 Fragen: Worin ist sie:er am stärksten? Worin würden Sie eine ergänzende Person einstellen? Würden Sie sie:ihn morgen wieder einstellen, warum? Ein Beispiel einer schwierigen technischen Entscheidung oder eines komplexen Incidents in Eigenverantwortung? Die 4. Frage liefert das eigentliche Autonomie- und Incident-Response-Signal.

Strukturierte Interviewfragen

  1. Verhaltensbezogen Automatisierungs-Mindset

    Beschreiben Sie eine CI/CD-Pipeline, die Sie entworfen und in Produktion gebracht haben. Welche Entscheidungen haben Sie zu Build-Reproduzierbarkeit, Test-Stufen und Deployment-Strategie getroffen?

    Worauf eine starke Antwort hinweist

    Bewusste Entscheidungen statt Default-Übernahme: deterministische Builds (Lockfiles, Container-Digests, keine latest-Tags), explizite Test-Stufen (Unit, Integration, Smoke, E2E) mit Begründung der Reihenfolge, Deployment-Strategie passend zum Risiko (Rolling, Blue-Green, Canary, Feature-Flag). Bonus: die:der Kandidat:in nennt Entscheidungen, die sie:er heute anders treffen würde. Wer ohne Reflexion alles in Jenkins-Skripten mit shell scripts beschreibt, hat selten ernsthaft abgewogen.

  2. Verhaltensbezogen Incident-Response

    Erzählen Sie mir von einem Production-Incident, den Sie federführend gelöst haben. Was war das Symptom, wie haben Sie diagnostiziert und wie lange hat es gedauert?

    Worauf eine starke Antwort hinweist

    Strukturierte Debug-Methode: Reproduktion, Logs, Metriken, durch Experiment validierte Hypothesen. Ehrlichkeit zur Dauer (ein echter Production-Incident mit Wirkung ist selten in unter 30 Min. geschlossen). Bonus: die:der Kandidat:in nennt die Grundursache und den systemischen Fix (Post-mortem, Runbook, neuer Alarm, Architektur-Anpassung), nicht nur den Hotfix. Antworten wie Ich habe den Cluster neugestartet ohne Diagnose deuten auf schwache Investigationsfähigkeit.

  3. Verhaltensbezogen Systemdenken

    Beschreiben Sie eine Migration einer kritischen Komponente, die Sie verantwortet haben (Beispiel: On-Prem zu Cloud, VMs zu Kubernetes, eine Datenbank-Engine-Migration). Wie haben Sie Downtime, Rollback und Daten- oder Trafficsteuerung behandelt?

    Worauf eine starke Antwort hinweist

    Schrittweises Vorgehen: parallele Systeme mit Traffic-Shifting (1 %, 10 %, 50 %, 100 %), expliziter Rollback-Plan zu jedem Schritt, Validierung auf Daten- oder Funktions-Konsistenz vor jedem Cut-over. Bonus: die:der Kandidat:in nennt einen Fall, in dem die Migration länger gedauert hat als geplant, und was sie:er daraus gelernt hat. Wer eine Big-Bang-Migration ohne Rollback beschreibt, zeigt Risikoblindheit.

Woran Sie eine:n exzellente:n Sales Manager:in erkennen

Kompetenz Unter Anforderung Auf Niveau Über Anforderung
Cloud-Infrastruktur Stolpert über Fundamente (IAM, Netzwerk-Topologie, VPC, Container-Runtime, Kubernetes-Workload-Typen). Sucht Lösungen durch Versuch und Irrtum ohne klares mentales Modell. Schwer auf neue Cloud zu setzen. Beherrscht den aktuellen Cloud-Stack eigenständig (AWS, GCP oder Azure, mindestens IAM, Compute, Netzwerk, Storage, Kubernetes oder vergleichbare Orchestrierung). Kann eine zweite Cloud in 2 bis 4 Wochen lernen. Versteht die Fundamente gut genug, um bei Bedarf tief zu debuggen. Referenzperson für die Cloud-Plattform im Team und in der Lage, innerhalb weniger Wochen auf eine andere Cloud umzusteigen. Antizipiert klassische Fallen (IAM-Drift, NAT-Gateway-Kosten, EBS-Burst-Credits, kubelet-Speicher-Pressure, Connection-Limits an Load Balancern). Baut nützliche, nicht verfrühte Abstraktionen (wieder verwendbare Terraform-Module mit klaren Verträgen).
Systemdenken Springt ohne Klärung der Bedingungen in die Lösung. Überarchitekturiert (Service Mesh für 3 Services) oder unterarchitekturiert (alles als ein VM-Setup ohne Grenzen). Schwer beim Abwägen zwischen Einfachheit, Konsistenz und Skalierbarkeit. Klärt Bedarf, Last, Konsistenzanforderungen und Compliance vor dem Bauen. Pragmatisch beim Abwägen: keine vorzeitige Architektur für unsichere Zukunft, identifiziert aber Zonen, in denen Struktur sich auszahlt (Idempotenz, Retry-Strategien, klare Service-Grenzen). Kann pivotieren, wenn die Ausgangshypothese nicht hält. Entwirft Systeme, die gut altern: klare Plattform-Verträge zwischen App-Teams und Plattform, gut gewählte Konsistenzgarantien, idempotente und sichere Operationen, minimale Abhängigkeiten. Erkennt eigene Unsicherheitszonen und schlägt gezielte POCs vor. Trainiert das Team in systemischem Denken.
Incident-Response Ohne Logs oder Metriken handlungsunfähig. Reagiert auf Incidents mit Neustart oder Glück. Keine strukturierte Diagnose. Loggt entweder zu wenig oder alles als Rauschen. Vermeidet On-Call. Hat ein klares Vorgehen bei Incidents (Reproduktion, Hypothesen, Validierung, Mitigation, dann Fix). Setzt strukturierte Logs, sinnvolle Metriken und Tracing ein. Schreibt nach einem Incident ein Post-mortem, das Maßnahmen ableitet. Übernimmt On-Call ohne Murren. Referenz im Team für Incident-Response: definiert SLOs, baut Alarm-Hygiene auf (kein Pager-Müll), entwickelt Runbooks. Findet Grundursachen in komplexen verteilten Systemen schnell. Coacht das Team in Debug-Hygiene. Treibt Verbesserungen aus Post-mortems aktiv zur Umsetzung.
Dev/Ops-Kollaboration Behandelt Entwickler:innen als Antragsteller:innen für Tickets. Defensive Haltung in Reviews. Arbeitet im Silo, teilt wenig Kontext. Sicherheits- oder Plattform-Regeln werden ohne Erklärung durchgesetzt. Reibung statt Partnerschaft. Versteht sich als Plattform-Partner:in der Entwicklungs-Teams: erklärt Plattform-Entscheidungen in klarer Sprache, baut Self-Service dort, wo es Sinn macht, nimmt Anforderungen aus den App-Teams ernst. Nimmt Reviews konstruktiv auf. Teilt Kontext in Team-Reviews und 1:1, dokumentiert Architektur-Entscheidungen (ADR). Brücke zwischen Plattform und App-Teams. Moderiert technische Debriefs, macht Abwägungen verständlich, verhandelt Plattform-Roadmap transparent. Aktive Mentorenhaltung gegenüber App-Entwickler:innen zu Observability, sicheren Deploys und Produktionsbetrieb.
Automatisierungs-Mindset Bevorzugt manuelle Eingriffe (per SSH, Klicks in der Cloud-Konsole). Sieht Infrastructure-as-Code als Bürokratie. Wiederkehrende Aufgaben werden wiederholt manuell ausgeführt. ClickOps-Drift als Standardzustand. Schreibt Infrastructure-as-Code als Default (Terraform, Pulumi, CloudFormation). Wiederkehrende Aufgaben werden skriptbasiert oder über die Pipeline automatisiert. Deployment, Provisionierung und Routine-Operationen sind reproduzierbar und versioniert. Drift wird erkannt und behoben. Treibt Automatisierungs-Standards für das ganze Team: wiederverwendbare Module mit Tests, GitOps für Cluster-State, automatisierte Compliance-Checks (Policy-as-Code), Self-Service-Plattform-Workflows für App-Teams. Baut Werkzeuge, die anderen das Leben erleichtern, statt sie sich selbst zu reservieren.
Autonomie und Findigkeit Blockiert sich stundenlang auf einem unbekannten Thema, ohne um Hilfe zu bitten, oder fragt bei jedem Hindernis sofort. Keine strukturierte Debug-Strategie unter Druck. Wartet auf klare Anweisungen statt Initiative zu zeigen. Kann auf bekannten Themen eigenständig diagnostizieren ; fragt nach vorheriger Untersuchung um Hilfe (Zusammenfassung des Problems, Hypothesen, was bereits versucht wurde). Bleibt unter Incident-Druck handlungsfähig. Bringt Initiative für Verbesserungen ein. Hohe Findigkeit auf unbekannten Themen: liest den Quellcode der Tools, instrumentiert die Plattform, isoliert Grundursachen, baut bei Bedarf neue Werkzeuge. Dokumentiert die Erkenntnisse für das Team. Treibt eigenständig Plattform-Verbesserungen vom Konzept bis zur Auslieferung.

30/60/90-Tage-Plan

Bis Tag 30

  • Vollständiger Setup der lokalen Entwicklungsumgebung, Zugriff auf alle Cloud-Konten und Cluster, On-Boarding zu On-Call dokumentiert und ein erster kleiner IaC-Change in Produktion validiert
  • Lesen und Verständnis der Architektur der Plattform: Cloud-Konten-Struktur, Netzwerk-Topologie, Cluster-Setup, CI/CD-Pipelines, Observability-Stack, kritische Runbooks
  • Erstes dokumentiertes 1:1 mit der:dem Tech Lead zu Konventionen, identifizierter technischer Schuld, Eskalations-Pfaden und Prioritäten der nächsten 90 Tage
  • Erster substantieller PR (Pipeline-Verbesserung, Monitoring-Lücke geschlossen, Runbook ergänzt) reviewt und gemerged

Bis Tag 60

  • Lieferung einer vollständigen Plattform-Verbesserung von Anfang bis Ende (Konzept, IaC-Änderung, Pipeline-Integration, Monitoring, Dokumentation) in Eigenverantwortung
  • Erste eigenständige Bereitschaftsphase mit Bearbeitung von mindestens einem Incident und Beitrag zum Post-mortem
  • Erste PR-Review eines Kollegen oder einer Kollegin mit strukturiertem Feedback, nicht nur Approve-Klick ; aktive Mitarbeit an mindestens einer App-Team-Anfrage zur Plattform
  • Dokumentation eines kürzlich bearbeiteten Plattform-Bereichs oder eines Runbooks verfasst oder aktualisiert

Bis Tag 90

  • Regelmäßige Lieferung (1 bis 2 substantielle Changes pro Woche) mit in der Review bestätigter Qualität und sichtbarem Beitrag zu mindestens einer Architektur-Entscheidung
  • Erste technische Entscheidung in Eigenverantwortung zu einem mehrdeutigen Plattform-Thema (Tool-Wahl, Cluster-Topologie, Backup-Strategie, Cost-Optimization)
  • Informelles Mentoring eines Junior- oder neuen Profils, oder einer App-Entwicklerin zu Observability und sicheren Deploys
  • Formales Bilanzgespräch mit der:dem Tech Lead: Ramp-Phase validiert, Entwicklungsplan auf 1 bis 2 Schwerpunkte (Beispiel: SRE-Tiefe, Security-Hardening, Cost-Engineering, Platform-PM-Skills)

Häufige Fehler bei der Besetzung dieser Rolle

DevOps-Rollen werden in deutschen KMU besonders häufig falsch zugeschnitten. Die folgenden Anti-Patterns kosten regelmäßig 6 bis 12 Monate Onboarding und führen zu vorzeitiger Kündigung.

  1. DevOps als reine SysAdmin-Rolle ausschreiben

    Eine Stellenausschreibung mit Linux-Server-Administration, SSH, Backups, Patch-Management als Hauptverantwortlichkeiten filtert moderne DevOps-Profile sofort heraus. Sie ziehen damit Profile an, die in Cloud-nativen Setups nicht autonom arbeiten können, und schrecken Profile mit Kubernetes-, IaC- und Observability-Tiefe ab. Beschreiben Sie stattdessen den realen Aufgabenmix: Plattform-Engineering, Pipeline-Ownership, Observability, Incident-Response, Enablement der App-Teams. Wenn die Rolle tatsächlich überwiegend SysAdmin ist, schreiben Sie sie als System Engineer aus, nicht als DevOps.

  2. Auf Konzern-Pedigree statt auf Produktionsbetrieb einstellen

    Ein:e Top-Absolvent:in einer renommierten Hochschule mit 2 Jahren bei einem DAX-Konzern oder einer Big-Tech-Niederlassung ist nicht automatisch produktiver als ein:e Autodidakt:in mit 5 Jahren On-Call in einem Startup oder KMU. Große Strukturen liefern ihren Plattform-Profilen klare Verträge zwischen Teams, dedizierte SRE-Funktionen und solides internes Tooling ; im KMU fehlt dieses Gerüst meist, und die fehlende Autonomie im Produktionsbetrieb wird zur Belastung. Gewichten Sie das Incident-Walkthrough-Interview und die Referenz-Prüfung zur Autonomie stärker als das Pedigree im Lebenslauf.

  3. Mehrtägige Take-Home-Aufgaben verlangen

    Eine Take-Home-Aufgabe mit 8 oder mehr Stunden nimmt in Wirklichkeit 24 Stunden in Anspruch (mit emotionalem Investment), demotiviert die besten Profile (die parallel andere Optionen haben) und liefert kein besseres Signal als ein gut geführtes Incident-Walkthrough von 45 Min. plus ein 30 Min. Architektur-Gespräch. Wollen Sie die Qualität der Argumentation messen, nicht die Vollständigkeit. Wenn doch eine praktische Übung nötig erscheint, begrenzen Sie sie auf maximal 2 Stunden mit klarem Scoping und akzeptieren Sie unvollständige, aber gut begründete Lösungen.

  4. On-Call-Erwartung erst nach Vertragsunterschrift transparent machen

    Eine produktionsverantwortliche DevOps-Rolle ohne klare Aussage zu On-Call, Bereitschaftsmodell, Vergütung der Bereitschaft, durchschnittlicher Pager-Last und Eskalationspfaden in der Ausschreibung führt zu vorzeitiger Kündigung innerhalb von 6 bis 12 Monaten. Geben Sie das Modell offen an: Bereitschaftsfenster (Beispiel: 1 Woche alle 6 Wochen), Vergütung (Bereitschaftspauschale plus Einsatzstunden), realistische Pager-Frequenz, Eskalationsmöglichkeit. Profile, die On-Call grundsätzlich ablehnen, sind in einer KMU-DevOps-Rolle oft fehl am Platz ; besser jetzt herausfiltern als nach 6 Monaten verlieren.

Häufige Fragen

  • Was verdient ein:e DevOps Engineer:in im KMU in Deutschland?

    Die Referenzspanne für eine:n DevOps Engineer:in auf Mid-Level (3 bis 7 Jahre Berufserfahrung) im deutschen KMU liegt bei 58 bis 92 k€ Bruttofixgehalt pro Jahr (Median um 72 k€). Berlin, München und Hamburg im SaaS- und Scale-up-Umfeld ziehen nach oben (85 bis 105 k€), klassischer Mittelstand und Provinzstandorte tendenziell nach unten. Kubernetes in Produktion, AWS- oder GCP-Erfahrung mit IAM- und Netzwerk-Tiefe sowie Terraform-Modul-Ownership ziehen nach oben ; Compliance-lastige Umfelder (BaFin, KRITIS, Versicherung, Health) ziehen erkennbar nach oben. Engineering-Rollen haben in Deutschland in der Regel keinen variablen Vergütungsanteil ; Scale-ups bieten ergänzend VSOP oder ESOP. On-Call-Vergütung wird oft separat als Bereitschaftspauschale plus Einsatzstunden geregelt.

  • Was ist der Unterschied zwischen DevOps-, SRE- und Plattform-Engineer:innen?

    Die Grenzen sind in deutschen KMU oft fließend, aber die Schwerpunkte unterscheiden sich. DevOps Engineer:innen fokussieren auf den Lieferpfad: CI/CD-Pipelines, Deployment-Automatisierung, Tooling für App-Teams, Infrastructure-as-Code. SRE-Profile (Site Reliability Engineering) konzentrieren sich stärker auf Zuverlässigkeit: SLOs, Error Budgets, Incident-Response, Observability, Capacity-Planning. Plattform-Engineer:innen bauen die interne Plattform als Produkt für die Entwicklungs-Teams: Self-Service-Workflows, Templates, golden paths. Im KMU mit weniger als 30 Entwickler:innen übernimmt eine DevOps-Rolle in der Regel Anteile aller drei Profile ; eine reine SRE- oder Plattform-Engineering-Rolle lohnt sich erst ab etwa 30 bis 50 Entwickler:innen.

  • Wie lange dauert die Einstellung eines:einer DevOps Engineer:in in Deutschland?

    Rechnen Sie mit 55 bis 80 Tagen zwischen der Veröffentlichung der Stellenausschreibung und der Vertragsunterzeichnung für ein Mid-Level-DevOps-Profil. Der deutsche Tech-Markt ist 2025-2026 weiterhin angespannt, vor allem für Profile mit moderner Cloud-Stack (AWS oder GCP, Kubernetes, Terraform) und Erfahrung mit Observability und Incident-Response. Die Fristen verlängern sich im Spätsommer und um den Jahreswechsel. Eine Verkürzung unter 55 Tage geht meist auf Kosten der Architektur-Stufe oder der Referenz-Prüfung und reduziert die Einstellungsqualität spürbar.

  • Brauchen DevOps Engineer:innen einen bestimmten Hochschulabschluss?

    Nein. Der deutsche Tech-Markt akzeptiert weitgehend autodidaktische Profile und Quereinsteiger:innen aus klassischen System-Administrations- oder Entwicklungs-Rollen, sobald 3 bis 5 Jahre solide Produktionspraxis vorliegen, idealerweise mit On-Call-Erfahrung. Ein Abschluss (FH-Informatik, Universitätsabschluss Informatik, technische Mathematik) wirkt bei Junior-Profilen beruhigend, verliert nach 5 Jahren Berufserfahrung aber an Bedeutung. Zertifizierungen (AWS Solutions Architect, CKA für Kubernetes, HashiCorp Terraform) können bei der Vorauswahl helfen, ersetzen aber keine Produktionspraxis. Bewerten Sie auf Basis des Incident-Walkthroughs, der Architektur-Diskussion und der Referenz-Prüfung, nicht des akademischen Pedigrees.

  • Welche rechtlichen Vorgaben gelten für DevOps-Stellenausschreibungen in Deutschland?

    Drei zentrale Vorgaben: (1) geschlechtsneutrale Stellenbezeichnung mit (m/w/d) oder Doppelpunkt-Schreibweise (§ 11 AGG), (2) Pflicht zur Gehaltstransparenz in der Anzeige oder vor dem ersten Interview (EU-Entgelttransparenzrichtlinie 2023/970, Umsetzung bis 7. Juni 2026), (3) Transparenz beim Einsatz von KI-Tools zur Vorauswahl und garantierte menschliche Aufsicht (EU AI Act, ab 2. August 2026). Zusätzlich: bei On-Call-Bereitschaft das Arbeitszeitgesetz (ArbZG) beachten ; Rufbereitschaft und Arbeitsbereitschaft unterscheiden sich in der Erfassung und Ruhezeit-Behandlung. Bei Beauftragung über Freelance oder Arbeitnehmerüberlassung saubere Abgrenzung zur Festanstellung, um Scheinselbstständigkeit zu vermeiden.

  • Ist ein technischer Test bei jeder DevOps-Einstellung sinnvoll?

    Ja, kombiniert mit einer Architektur-Diskussion. Für DevOps-Profile ist der Incident-Walkthrough (40 bis 50 Min., realer Fall der:des Kandidat:in) plus eine Architektur-Diskussion zu einem konkreten Plattform-Fall der mit Abstand prädiktivste Schritt: schlechte Entscheidungen zu Cluster-Topologie, Backup-Strategie oder Observability-Setup zeigen sich erst nach Monaten und sind teuer zu reparieren. Eine schriftliche Übung (Beispiel: ein Terraform-Modul für einen typischen Use Case) sollte kurz (maximal 2 Stunden), realistisch und an Ihre Stack angelehnt sein. Vermeiden Sie reine Trivia-Fragen ohne Bezug zum Alltag. Begrenzen Sie die erwartete Zeit explizit und akzeptieren Sie unvollständige, aber gut begründete Lösungen.

Diese Stelle mit Join besetzen Sourcing, Screening und Interviews an einem Ort.
Kostenlos einstellen

Mit Join sprechen