Wie man DevOps-Engineers' Skills bewertet: Methodologie & Rubric
Der DevOps-Bewertungs-Fehler
Die meisten Teams bewerten DevOps-Kandidatinnen wie Software-Engineers: Coding-Übungen. Aber DevOps geht primär nicht ums Coden. Es geht um Systems-Thinking, Trade-off-Urteil und operative Resilienz.
Du brauchst ein anderes Framework.
Welche DevOps-Skills tatsächlich Job-Performance vorhersagen
1. Systems-Thinking und Failure-Mode-Reasoning
Können sie Failure-Modes nennen? Können sie proaktiv dafür designen?
Was zu bewerten: Gib ihnen eine simple Architektur (Web-App, die mit RDS spricht) und frage: "Was bricht? Was ist der Blast-Radius? Wie mitigierst du?"
Gute Antwort: "RDS ist ein Single-Point-of-Failure. Ich würde Read-Replicas für Failover hinzufügen und einen Connection-Pool. Die App sollte stateless und loadbalanced sein. Ich würde einen Circuit-Breaker für die DB hinzufügen."
Schwache Antwort: "Nutze Kubernetes."
2. Operativer Pragmatismus
Wählen sie die einfachste Lösung, die funktioniert? Oder greifen sie zum fancy Tool?
Was zu bewerten: "Du musst einen täglichen Backup-Job laufen lassen. Du hast zwei Optionen: Kubernetes CronJob oder Lambda. Dein Team hat kein existierendes Kubernetes. Geh durch die Trade-offs."
3. Observability und Debugging
Können sie Monitoring designen? Können sie Probleme von Alert zu Root-Cause tracen?
4. Automatisierungs-Urteil
Wann sollte etwas automatisiert vs. manuell sein?
Was zu bewerten: "Du deployst 20-mal am Tag, aber DB-Migrations passieren nur einmal pro Woche. Solltest du Migrations gleich automatisieren wie Deployments?"
Gute Antwort: "Nein. Automation reduziert kognitive Last bei häufigen, low-risk Operationen. Migrations sind selten und high-risk."
5. Cloud-Architektur-Trade-offs
AWS vs. Azure vs. GCP geht nicht um Features — es geht um Operations und Kosten.
Bewertungs-Struktur
Teil 1: Take-Home-Szenario (2 Stunden)
Stelle ein Architektur-Diagramm oder eine Terraform-Codebase mit absichtlichen Lücken oder Security-Issues. Bitte: identifiziere Probleme, schlage Fixes mit Trade-off-Analyse vor, skizziere eine Monitoring-Strategie.
Teil 2: Live-Troubleshooting (45 Minuten)
Szenario: Production-Latency-Spike. Geh durch wie du debuggen würdest.
Teil 3: Architektur-Konversation (30 Minuten)
"Wir müssen 50TB Daten in eine neue DB migrieren mit Zero-Downtime. Was ist dein Ansatz?"
Rubric
| Skill | Level 1 | Level 2 | Level 3 |
|---|---|---|---|
| Failure-Mode-Reasoning | Nur offensichtliche Issues | 2-3 Schichten tief | Antizipiert Edge-Cases |
| Automation-Urteil | Automatisiert wahllos | Wählt richtiges Tool | Designt mit Rollback und Safety-Gates |
| Observability | Kennt basische Metriken | Instrumentiert für Monitoring und Debugging | Designt für On-Call-Erfahrung |
| Cost-Awareness | Ignoriert Kosten | Balanciert Performance vs. Kosten | Schlägt Optimierungen ohne Reliability-Opfer |
| System-Design | SPOF, kein Backup-Plan | Fügt Redundanz hinzu | Designt Multi-Region mit klarem Failover |
Was zu vermeiden
Nicht: bitte LeetCode-Probleme, behandle DevOps als "Software-Engineering-Lite", fokussiere auf Tool-Breadth, ignoriere Live-Interviews.
Tu: präsentiere realistische Constraints, teste Urteil nicht Fakten, zeichne Erklärungen auf.
DevOps-Hiring at Skala
Wenn du 5+ DevOps-Engineers hirest, nutze einen strukturierten Bewertungs-Prozess mit dieser Rubric.