DevOps-Engineer-Test: Beispielfragen & Bewertungs-Vorlage

Warum generische Infrastruktur-Fragen scheitern

Die meisten DevOps-Bewertungen stellen Lehrbuch-Fragen: "Was ist ein Container?" oder "Definiere CICD." Diese Fragen messen Trivia-Recall, nicht ob jemand ein resilientes System unter Druck designen oder einen Production-Incident um 2 Uhr nachts debuggen kann.

Ein echter DevOps-Test sollte Urteil messen, keine Fakten. Er sollte testen, ob jemand Trade-offs zwischen Automation und Operability versteht, weiß wann horizontal vs. vertikal zu skalieren ist, und über Failure-Modes räsonieren kann.

Hier ist, wie eine signal-tragende DevOps-Bewertung aussieht.

Kategorie 1: Infrastruktur-Design unter Constraints

Szenario-basierte Frage:

"Du hast eine Anwendung auf einer einzelnen EC2-Instanz. Sie handhabt 1000 RPS, nutzt 70% CPU und hat 4GB RAM bei 60% Auslastung. Dein SLA ist 99,9% Uptime. Die Anwendung ist stateless. Welche Änderungen würdest du machen, in welcher Reihenfolge? Welche Trade-offs gehst du ein?"

Das testet:

• Verständnis von Skalierbarkeit vs. Redundanz (beide nötig für 99,9%)
• Cost-Bewusstsein (springen sie zu teuren Lösungen?)
• Sequenzierungs-Wissen (Failover vor Optimierung)
• Trade-off-Artikulation (EBS gp3 vs. lokales NVMe, zum Beispiel)

Eine Kandidatin, die sagt "Add a Load Balancer and spin up two more instances in another AZ" denkt klar. Eine, die sagt "Switch to Kubernetes" könnte Pattern-Matching ohne das Constraint zu verstehen.

Kategorie 2: Incident-Response und Troubleshooting

Szenario-basierte Frage:

"Deine CI/CD-Pipeline scheitert auf zufälligen Builds. Der Fehler ist 'connection timeout to Docker registry.' Das Problem passiert ungefähr einmal pro 20 Builds. Was prüfst du zuerst, und welche Instrumentierung würdest du hinzufügen?"

Das testet:

• Systematische Debugging-Methodologie
• Verständnis von Netzwerk-Isolation und Authentifizierung
• Observability-Denken
• Priorisierung

Eine Kandidatin, die mit "check the Docker registry status page" beginnt, ist weniger thoughtful als eine, die sagt "first: is it retry-able and did we add rate limiting? second: check if the registry token is expiring mid-build or if our network config changed."

Kategorie 3: Code- und Config-Review

Live-Übung:

Stelle einen 30-zeiligen Terraform-Snippet oder eine Docker-Compose-Config mit absichtlichen Issues. Bitte die Kandidatin, Probleme zu identifizieren und den Fix zu erklären.

Beispiel-Terraform-Issues:

• Security Group erlaubt 0.0.0.0/0 auf einen DB-Port
• Fehlende Backup-Retention-Policy auf RDS
• Hardcoded DB-Passwort in Variables
• Keine Tags für Cost-Allocation

Beispiel-Compose-Issues:

• Privilegierte Container ohne Begründung
• Fehlende Health-Checks
• Logging auf Stdout ohne Limits (Disk-Fill-Risk)
• Keine Resource-Constraints (CPU/Memory)

Das testet, ob sie Production-Systems geshippt haben und gelernt haben, was bricht. Lehrbuch-Engineers fangen diese nicht; erfahrene Operatoren tun es.

Kategorie 4: Architektur und Tool-Auswahl

Gespräch:

"Wir müssen Jobs über 50 Microservices koordinieren. Jeder Job dauert 2-30 Minuten. Wir wollen starke Ordering-Garantien. Was würdest du nutzen? Geh durch die Trade-offs."

Valide Antworten:

• Temporal (Workflow-Orchestrierung, starkes Ordering, komplex zu betreiben)
• Step Functions (managed, auf AWS limitiert, weniger flexibel)
• Pub/Sub + Consumer-App (low Coupling, schwaches Ordering, operativ einfacher)
• Kubernetes Jobs + Custom Controller (flexibel, mehr Operations-Overhead)

Der Interviewer sollte zurückdrücken: "Step Functions klingt simpler." Die Kandidatin sollte verteidigen: "Bis du einen Job retryen musst, der bereits teilweise gelaufen ist, oder bis du einen 2-Minuten-Job in einer 10-Minuten-SLA hast, dann brauchst du die Workflow-State-Machine."

Das testet Urteil und Erfahrung, kein Wissen.

Kategorie 5: Observability und Monitoring

Kurzes Szenario:

"Du hast eine Änderung deployed und deine Error-Rate ging von 0,1% auf 0,5%. Latenz p99 ist gleich. Die Änderung berührte Logging und Tracing, nicht Request-Handling. Wo schaust du?"

Eine schwache Antwort: "Check the logs." Eine starke Antwort: "Erst würde ich prüfen, ob Tracing-Instrumentierung oder Logging-Level sich änderte — das könnte Error-Sichtbarkeit erhöhen, ohne tatsächliche Errors zu erhöhen. Dann würde ich auf Log-Cardinality schauen. Dann würde ich prüfen, ob wir neue Error-Cases loggen, die vorher nicht gefangen wurden."

Das trennt Operatoren von Engineers, die nur Kubernetes-Docs gelesen haben.

Wie die Bewertung strukturieren

1. 30-Minuten-Take-Home: Infrastruktur-Design-Szenario + Config-Review. Bitte sie, ihre Entscheidungen zu erklären.
2. 30-Minuten-synchrones Interview: Live-Troubleshooting-Konversation + Architektur-Diskussion. Zeichne ihr Reasoning auf.
3. Paare die Bewertung mit Keystroke-Integritätssignalen. DevOps-Kandidatinnen, die ganze Lösungen aus ChatGPT oder StackOverflow kopieren, zeigen ungewöhnliche Edit-Patterns. ClarityHire erfasst das standardmäßig.

Der ehrliche Counter-Point

Nicht jede Rolle braucht diese Tiefe. Junior-DevOps- oder SRE-Rollen profitieren von einfacherem Filtering: können sie Terraform lesen, eine App deployen, ein Netzwerk-Diagramm verstehen? Für Senior+-Hiring gilt diese Rubric. Für Mid-Level, drehe die Komplexität herunter, aber behalte die Szenario-basierte Struktur.

Nächste Schritte

Bereit, deine DevOps-Kandidatinnen mit echten Tests zu bewerten? Schau dir unseren DevOps und Cloud Engineering Bewertungs-Hub an für Vorlagen und Anleitung zu wie man DevOps-Engineers' Skills bewertet.