Was testen DevOps-Interviews wirklich?

Mit wem Sie tatsächlich sprechen

Bei den meisten DevOps-Stellen treffen Sie in den technischen Runden keinen Generalisten aus dem Recruiting. Nach einem ersten Screening (oft prüft ein Talent Partner Kündigungsfrist, Gehalt, Arbeitserlaubnis) sind die Personen, die die harten Fragen stellen, normalerweise diejenigen, mit denen Sie zusammenarbeiten würden: ein Platform- oder SRE-Lead, ein Senior DevOps Engineer, manchmal der Engineering Manager, der die Bereitschaftsliste verantwortet. In regulierten Umgebungen — Finanzwesen, Gesundheitswesen, alles was PCI oder SOC 2 berührt — sitzt oft ein Security Engineer in mindestens einer Runde dabei, weil Zugangskontrolle und Audit-Trails Teil der Arbeit sind, nicht ein Nebenaspekt.

Das ist wichtig, weil diese Interviewer normalerweise um 3 Uhr morgens wegen etwas geweckt wurden, das Sie beheben müssten. Sie testen nicht, ob Sie "CI/CD" definieren oder AWS-Services aufzählen können. Sie testen, ob sie Ihnen Produktionszugang anvertrauen würden.

Der technische Screen: wie er tatsächlich aussieht

Die meisten Prozesse für diese Rolle umfassen eines von drei Formaten, manchmal zwei davon:

Eine Aufgabe zum Mitnehmen oder eine Live-Übung mit echter kaputter Infrastruktur. Sie bekommen möglicherweise ein Repo mit einem Terraform-Modul, das nicht angewendet werden kann, ein Dockerfile, das ein 2GB-Image baut, wenn es 200MB bauen sollte, oder eine GitHub Actions/GitLab CI-Pipeline, die lokal läuft, aber im Runner fehlschlägt. Sie sollen es reparieren und Ihre Überlegungen erklären, nicht nur ein funktionierendes Diff einfügen. Interviewer achten darauf, ob Sie die Plan-Ausgabe prüfen, bevor Sie anwenden, ob Sie Exit-Codes und Logs ansehen, bevor Sie raten, und ob Sie erklären warum die Lösung funktioniert und nicht nur dass sie funktioniert.

Eine Live-Debugging- oder Pairing-Session. Sie teilen Ihren Bildschirm, sie geben Ihnen einen Kubernetes-Cluster (oft kind oder minikube) mit einem Pod in CrashLoopBackOff, oder einen Service, der 502er hinter einem Load Balancer zurückgibt, und Sie sprechen Ihre Diagnose in Echtzeit durch: kubectl describe pod, Prüfung der Ressourcenlimits, Lesen der Events vor den Logs, Prüfung ob es die App oder der Ingress ist. Der Wert liegt komplett in der Erzählung. Schweigen während Sie tippen ist ein schlechteres Signal als eine falsche erste Vermutung gefolgt von einem vernünftigen nächsten Schritt.

Eine Whiteboard- oder verbale System-Design-Runde. Entwerfen Sie eine Deployment-Pipeline für einen Service mit harter Uptime-Anforderung, oder entwerfen Sie, wie Sie eine Schema-Migration ohne Downtime ausrollen würden, oder entwerfen Sie Monitoring für eine Reihe von Microservices. Diese werden nach Trade-offs beurteilt: Blue-Green versus Canary, warum Sie eine Autoscaling-Policy einer anderen vorziehen würden, was Sie in ein Dashboard aufnehmen versus worauf Sie alarmieren würden, wie Sie ein SLO setzen und was Sie tun, wenn das Error-Budget aufgebraucht ist.

Die Fragen, die tatsächlich Kompetenz prüfen

Ein paar Fragen tauchen in fast jedem DevOps-Interview auf, und jede hat eine Version, die Menschen trennt, die die Arbeit gemacht haben, von denen, die darüber gelesen haben.

"Führen Sie mich durch einen Incident, den Sie bearbeitet haben." Eine echte Antwort nennt das Symptom, die Diagnoseschritte in Reihenfolge, die tatsächliche Grundursache, die sofortige Lösung und — entscheidend — was sich danach änderte: ein neuer Alert, ein Runbook, eine Änderung an einem Deploy-Gate. Sie enthält normalerweise auch etwas, das in der Reaktion selbst schiefging, weil Incidents selten sauber ablaufen. Wenn die Geschichte kein Postmortem und keine Folgemaßnahme hat, wird der Interviewer fragen, was sich änderte, und es muss eine Antwort geben.

"Wie verwalten Sie Secrets?" Sie hören darauf, ob Sie zwischen Secrets in der Versionskontrolle (ein Fail), Secrets in Umgebungsvariablen (eine teilweise Antwort) und Secrets unterscheiden, die zur Laufzeit aus etwas wie Vault, AWS Secrets Manager oder SSM Parameter Store mit beschränkten IAM-Rollen und Rotation gezogen werden. Bonuspunkte, unaufgefordert, für die Erwähnung, wie Sie ein bereits geleaktes Credential rotieren würden, weil das die Frage hinter der Frage ist.

"Was ist der Unterschied zwischen Ihrem Monitoring und Ihrem Alerting?" Dies testet, ob Sie in SLIs und SLOs denken oder nur in Dashboards. Eine starke Antwort trennt, was Sie während einer Untersuchung ansehen würden (Metriken, Traces, Logs — idealerweise benannt: Prometheus/Grafana, Datadog, der ELK- oder Loki-Stack) von dem, was tatsächlich jemanden wecken sollte, und erklärt, warum Alert-Fatigue ein Design-Fehler ist, keine Unvermeidlichkeit.

"Wie würden Sie das zurückrollen?" Gefragt bei fast jedem Deployment-Szenario. Die Antwort braucht einen konkreten Mechanismus — ein vorheriges Image-Tag, eine Helm-Revision, eine Datenbankmigration, die reversibel oder zumindest vorwärtskompatibel ist — nicht "wir würden einfach die alte Version neu deployen", was annimmt, dass die alte Version noch buildbar ist und dass das Rollback selbst nichts anderes kaputt macht.

"Warum Terraform/Ansible/Puppet über die Alternative?" Weniger über das Tool und mehr darüber, ob Sie deklaratives versus imperatives State-Management verstehen, was Drift ist und wie Sie es erkennen und abgleichen. Wenn Ihr Team GitOps verwendet (ArgoCD, Flux), erwarten Sie eine Frage dazu, was passiert, wenn jemand etwas direkt im Cluster ändert statt über Git, weil das die tatsächliche tägliche Reibung des Modells ist.

Wie eine oberflächliche Antwort klingt

Für jemanden, der diesen Job macht, hat eine oberflächliche Antwort eine spezifische Form. Sie nennt Tools ohne eine Entscheidung zu nennen: "wir haben Kubernetes und Terraform und Jenkins verwendet" sagt dem Interviewer nichts darüber, was Sie tatsächlich gewählt haben oder warum. Sie überspringt den Fehlermodus: einen Deployment-Prozess zu beschreiben ohne Erwähnung dessen, was passiert, wenn er fehlschlägt, oder ein Monitoring-Setup ohne Erwähnung dessen, was Sie aktuell nicht beobachten. Sie behandelt "Ich würde es neustarten" als Diagnose statt als Notlösung — einen Pod neu zu starten könnte ein Symptom beseitigen, aber wenn Sie nicht sagen können, was den Crash verursacht hat, weiß der Interviewer, dass Sie um 3 Uhr morgens wieder dasselbe tun würden. Und sie beantwortet System-Design-Fragen mit einer einzelnen Architektur und keinen erwogenen Alternativen, was sich liest, als hätten Sie ein Diagramm auswendig gelernt statt Trade-offs auf einem echten System mit echten Beschränkungen abgewogen — Kosten, Teamgröße, vorhandenes Tooling.

Das Gegenteil ist auch wahr und wissenswert: jedes Akronym überzuerklären oder eine Lehrbuchdefinition von Blue-Green-Deployment aufzusagen, wenn gefragt wird, wie Sie einen spezifischen Service deployen würden, liest sich genauso. Der Interviewer will Ihre Überlegung auf ihr Szenario angewandt, keine allgemeine Vorlesung.

Was vor dem Interview zu tun ist

Gehen Sie Ihre letzten zwei oder drei echten Incidents, Migrationen oder Infrastrukturänderungen durch und schreiben Sie in Reihenfolge auf: Symptom, Diagnoseschritte, Lösung und was sich danach änderte. Wenn Sie den letzten Teil nicht ausfüllen können, ist das erwähnenswert vor dem Interview, nicht währenddessen.

Wenn die Stellenanzeige spezifische Tools erwähnt — Terraform über Pulumi, EKS über selbstverwaltetes Kubernetes, Datadog über Open-Source-Prometheus — prüfen Sie Ihre eigene Erfahrung ehrlich gegen diesen Stack. Wo Sie das Äquivalent, aber nicht das exakte Tool verwendet haben, sagen Sie es und erklären Sie die Zuordnung; Interviewer respektieren im Allgemeinen "Ich habe Chef verwendet, nicht Puppet, aber das Modell ist dasselbe" weit mehr als eine vage Behauptung von Vertrautheit, die bei einer Folgefrage auseinanderfällt.

Und wenn Sie eine hohe Anzahl von Bewerbungen versenden und nichts hören, lohnt es sich zu prüfen, ob die spezifischen Anforderungen der Anzeige früh genug in Ihrem CV auftauchen, um Sie überhaupt in diese Phase zu bringen — das Interview testet nur, was Sie bereits wissen; es kann keinen CV reparieren, der die Kubernetes- und Terraform-Erfahrung, die die Anzeige verlangte, auf Seite zwei vergräbt.