Was in einem DevOps-Interview gefragt wird, wie man auf Fragen zu CI/CD, Kubernetes und Vorfällen antwortet und wie man das Gespräch probt.
Ein DevOps-Vorstellungsgespräch ähnelt am wenigsten einer Prüfung über Tools. Die Technologieliste kennt jeder, der Stellenanzeigen gelesen hat. Geprüft wird etwas anderes: wie Sie den Prozess aufbauen, was Sie tun, wenn alles ausgefallen ist, und ob Sie ein Tool passend zur Aufgabe und nicht nach Trends auswählen können.
| Phase | Was geprüft wird |
|---|---|
| Screening | Erfahrung, Tech-Stack, Gehaltserwartungen |
| Infrastruktur | Linux, Netzwerke, Container, Orchestrierung |
| Praxis | Incident-Analyse, Diagnose anhand von Logs |
| Prozesse | CI/CD, Releases, Sicherheit, Teamarbeit |
Die Antwort «GitLab CI» ist keine Antwort. Erwartet wird der Weg: Commit → Build → Tests → Artefakt → Deployment in die Umgebung, mit Rollback und damit, was bei einem Fehlschlag in jedem Schritt passiert. Eine gute Antwort enthält die Build-Dauer und frühere Erfahrung mit Verbesserungen.
Image-Schichten und ihr Caching, Multi-Stage-Build, warum ein Image mit 1 GB ein Problem ist, wie man Secrets übergibt, der Unterschied zwischen CMD und ENTRYPOINT. Häufig wird darum gebeten zu erklären, warum ein Anwendungscontainer beim Start abstürzt.
Pod versus Deployment, Readiness- und Liveness-Probes, Neustarts und ihre Ursachen, Ressourcenlimits und OOMKill, ConfigMap und Secret, Ingress. Eine praktische Frage: «Der Pod kommt nicht hoch – womit fangen Sie an».
Terraform versus Ansible, State und Locking, Plan vor dem Anwenden, Idempotenz. Es wird geprüft, ob Sie verstehen, was `apply` vor seiner Ausführung bewirkt.
Was vom Browser bis zur Anwendung passiert: DNS, Load Balancer, TLS, Proxy. LAN-Ebenen, MTU-Probleme, der Unterschied zwischen L4 und L7. Hier werden diejenigen aussortiert, die „alles über fertige Pipelines gemacht haben“.
Metriken versus Logs versus Tracing, was SLO und Budget sind, warum „Monitoring vorhanden ist, aber Vorfälle nicht sichtbar sind“. Praxisbeispiel: Nutzer beschweren sich, aber die Metriken sind im Normalbereich – was prüfen Sie?
Vorgehen bei einem Produktionsausfall, wer Entscheidungen trifft, wie kommuniziert wird, wie man ein Postmortem ohne Schuldzuweisungen schreibt. Das ist die Lieblingsfrage der Interviewer: Sie zeigt echte Erfahrung.
Die Struktur funktioniert: Symptom → Hypothesen → was ich prüfe → Lösung → Prävention.
„Nutzer melden 502. Zuerst schaue ich auf den Load Balancer: Sind die Upstreams lebendig? Wenn ja, prüfe ich Anwendungslogs und Latenzmetriken. Im vorherigen Projekt lag die Ursache in der Erschöpfung des DB-Verbindungspools: Geholfen hat die Vergrößerung des Pools und das Hinzufügen eines Timeouts. Prävention – ein Alert auf die Pool-Auslastung, nicht auf 5xx.“
— ein Beispiel für eine Antwort aus der Praxis der Interviewauswertung
Eine Woche mit 30–40 Minuten: sieben Themen durchgehen, zwei bis drei echte Vorfälle mit Zahlen in Erinnerung rufen und einmal einen vollständigen Dialog durchlaufen. Der Fall zum Vorfall ist wichtiger als die Theorie – daran werden am häufigsten Kandidaten aussortiert.
Wenn es in der Stellenausschreibung steht — ja, zumindest auf der Ebene von Probes, Limits und der Analyse eines abstürzenden Pods. Wenn die Infrastruktur auf virtuellen Maschinen läuft, fragt man nach systemd, Lastverteilung und Deployment ohne Orchestrator.
Ja — Python, Go oder Bash auf der Ebene von Automatisierungsskripten. Vollwertiges Live Coding kommt seltener vor, aber man kann gebeten werden, ein fremdes Skript zu analysieren und einen Fehler darin zu finden.
Sagen Sie es direkt und zeigen Sie das Prinzip: „Damit habe ich nicht gearbeitet, aber die Aufgabe wird genauso gelöst wie X – durch deklarative Beschreibung und idempotenten Lauf“. Der Interviewer prüft die Übertragbarkeit des Denkens, nicht die API-Kenntnisse.
Mit einer Spanne, nicht mit einer einzelnen Zahl, und mit Bezug auf den Markt. Eine ausführliche Analyse finden Sie im Artikel Gehaltsverhandlungen.
Beschreiben Sie die Situation in einem Satz – „Vorstellungsgespräch DevOps-Ingenieur, Kubernetes und CI/CD, vier Jahre Erfahrung“ – und führen Sie das Gespräch im Trainer. Der Trainer stellt Fragen zu Ihrer Rolle und analysiert die Antworten nach dem Gespräch.
Denken Sie an zwei eigene Vorfälle zurück und beschreiben Sie sie nach dem Schema: Symptom — Hypothesen — was geprüft wurde — Lösung — Prävention. Spielen Sie den Fall dann laut durch: öffnen Sie HintMeTalk AI, Modus „Trainer“, beschreiben Sie die Stelle in einem Satz. Nach der Auswertung ist sichtbar, wo Sie anfangen zu reparieren, ohne die Hypothese geprüft zu haben.
Auswertungen für andere Rollen: Java, Python, Frontend, Systemanalytiker.
Trainiere diese Fähigkeit in HintMeTalk AI
App öffnen