So bewerten Sie die Fähigkeiten von DevOps-Ingenieuren: Methodik und Bewertungskriterien
Der DevOps-Bewertungsfehler
Die meisten Teams bewerten DevOps-Kandidaten auf die gleiche Weise wie Softwareingenieure: durch Programmieraufgaben. Aber DevOps geht nicht in erster Linie um das Programmieren. Es geht um Systemdenken, Urteilsvermögen bei Trade-offs und operative Widerstandsfähigkeit.
Ein Kandidat kann wunderschönes Terraform schreiben und völlig scheitern, wenn um Mitternacht die Datenbank ausfällt. Umgekehrt kann ein Kandidat mit fehlerhaftem Code ein System entwerfen, das einen kompletten Zonenausfall ohne manuelle Eingriffe übersteht.
Sie benötigen einen anderen Ansatz.
Welche DevOps-Fähigkeiten die Jobperformance tatsächlich vorhersagen
1. Systemdenken und Analyse von Fehlermöglichkeiten
Können sie Fehlermöglichkeiten benennen? Können sie proaktiv dafür entwerfen?
Was zu bewerten ist: Geben Sie ihnen eine einfache Architektur (eine Web-App, die mit RDS spricht) und fragen Sie: „Was kann hier schiefgehen? Wie groß ist der Auswirkungsbereich? Wie mindern Sie das Risiko?" Bitten Sie sie nicht, Netflix zu entwerfen. Bitten Sie sie, ein einfaches Setup zu härten.
Eine gute Antwort: „RDS ist ein Single Point of Failure. Ich würde Read Replicas für das Failover und einen Connection Pool hinzufügen, um Connection-Erschöpfung zu verhindern. Die App selbst sollte zustandslos und lastverteilt sein. Ich würde einen Circuit Breaker für die Datenbank hinzufügen."
Eine schwache Antwort: „Verwenden Sie Kubernetes."
2. Operative Pragmatik
Wählen sie die einfachste Lösung, die wirklich funktioniert? Oder greifen sie nach dem fancysten Tool?
Was zu bewerten ist: „Sie müssen einen täglichen Backup-Job ausführen. Sie haben zwei Optionen: Kubernetes CronJob oder Lambda. Ihr Team hat kein bestehendes Kubernetes. Erörtern Sie die Trade-offs."
Gute Antwort: „Lambda ist einfacher zu bedienen, wenn Sie nicht bereits Kubernetes ausführen. Weniger bewegliche Teile, einfacher zu debuggen, CloudWatch-Integration ist eingebaut. Der Trade-off ist ein 15-Minuten-Timeout und Cold-Start-Latenz, was bei einem Backup keine Rolle spielt. Ich würde Lambda verwenden."
Schwache Antwort: „Verwenden Sie immer Kubernetes, weil es portabler ist."
3. Observability und Debugging
Können sie Überwachung entwerfen? Können sie ein Problem von der Warnung bis zur Grundursache nachverfolgten?
Was zu bewerten ist: Live-Coding-Interviews gelten hier nicht. Geben Sie ihnen stattdessen eine Production-Warnung: „CPU ist bei 80 % auf Ihrer Postgres-Instanz. Sieht zufällig aus. Diagnose?" Bitten Sie sie, zu kommentieren: Welche Query-Tools würden sie verwenden, was würden sie überprüfen, in welcher Reihenfolge?
Gute Antwort: „Zuerst würde ich pg_stat_statements nach den langsamsten Abfragen überprüfen, dann überprüfen, ob es mit einem bestimmten Anwendungs-Endpoint korreliert, dann Index-Statistiken ansehen, um zu sehen, ob ein Index fehlt oder aufgebläht ist."
4. Automatisierungsurteil
Wann sollte etwas automatisiert werden und wann manuell?
Was zu bewerten ist: „Sie stellen 20 Mal pro Tag bereit, aber Datenbankmigrationen finden nur einmal pro Woche statt. Sollten Sie Migrationen auf die gleiche Weise automatisieren wie Bereitstellungen?"
Gute Antwort: „Nein. Automatisierung reduziert die kognitive Belastung, wenn die Operation häufig und risikoarm ist. Migrationen sind selten und hochriskant — Sie möchten, dass ein Mensch vor dem Ausführen überprüft und genehmigt, und Sie möchten zuerst einen Trockenlauf."
Schwache Antwort: „Automatisieren Sie alles."
5. Cloud-Architektur-Trade-offs
AWS vs. Azure vs. GCP geht nicht um Features — es geht um Operations und Kosten.
Was zu bewerten ist: Präsentieren Sie ein Szenario und fordern Sie eine Kosten-Nutzen-Analyse an. „Sie bauen eine Mikroservices-Plattform. Sollten Sie verwaltetes Kubernetes (EKS/AKS/GKE) oder selbst verwaltetes verwenden?"
Idealerweise sagen sie: „Verwaltete Systeme sind besser für kleine bis mittlere Teams. Sie kümmern sich um die Kontrollebene, Updates und Netzwerke für Sie. Der Trade-off ist weniger Kontrolle und etwas höhere Kosten. Selbst verwaltete Systeme sind besser, wenn Sie ein dediziertes Team und spezifische Netzwerkanforderungen haben."
Bewertungsstruktur
Teil 1: Take-Home-Szenario (2 Stunden)
Geben Sie ein Architektur-Diagramm oder eine Terraform-Codebasis mit absichtlichen Lücken oder Sicherheitsproblemen an. Fragen Sie:
- Identifizieren Sie Probleme
- Schlagen Sie Fixes mit Trade-off-Analyse vor
- Skizzieren Sie eine Überwachungsstrategie für dieses System
Dies ist asynchron-freundlich und testet Wissen im großen Maßstab.
Teil 2: Live-Troubleshooting (45 Minuten)
Szenario: Production-Latenz-Spike. Führen Sie mich durch, wie Sie das debuggen würden.
Der Kandidat spricht; Sie hören zu. Sie testen:
- Systematischer Ansatz (kein Raten)
- Kenntnisse von Observability-Tools
- Priorisierung (wo man zuerst schauen sollte)
- Kommunikation (können sie ihr Denken erklären)
Teil 3: Architektur-Gespräch (30 Minuten)
Präsentieren Sie eine Einschränkung oder Anforderung. „Wir müssen 50 TB Daten in eine neue Datenbank mit null Ausfallzeiten migrieren. Wie ist Ihr Ansatz?"
Dies testet Urteilsvermögen und Pragmatik. Es gibt keine richtige Antwort — Sie hören auf das Denken über Auswirkungsbereich, Rollback-Pläne und operative Komplexität.
Rubrik: Bewertungs-Framework
| Fähigkeit | Stufe 1 (Unter) | Stufe 2 (Erfüllt) | Stufe 3 (Übertrifft) |
|---|---|---|---|
| Analyse von Fehlermöglichkeiten | Benennt nur offensichtliche Probleme | Denkt 2–3 Schichten tief (primärer Fehler und Kaskadeneffekt) | Antizipiert Grenzfälle und Auswirkungsbereich |
| Automatisierungsurteil | Automatisiert unkritisch | Wählt das richtige Tool für Häufigkeit/Risiko | Entwerft Automatisierung mit explizitem Rollback und Sicherheitstoren |
| Observability | Kennt grundlegende Metriken; denkt, Logs seien zum Debuggen | Instrumentalisiert sowohl für Überwachung als auch Debugging; versteht Kardinalität | Entwirft Observability für On-Call-Erfahrung; korreliert Signale |
| Kostenorientierung | Ignoriert Kosten; bevorzugt „stärkere" Optionen | Balanciert Performance vs. Kosten innerhalb von Einschränkungen | Schlägt Kostenoptimierungen vor, ohne Zuverlässigkeit zu beeinträchtigen |
| Systemdesign | Single Point of Failure; kein Backup-Plan | Fügt Redundanz dort hinzu, wo nötig; versteht RPO/RTO | Entwirft Multi-Region oder Multi-Cloud mit klarem Failover |
Was zu vermeiden ist
Nicht:
- Bitten Sie DevOps-Kandidaten, LeetCode-Aufgaben zu lösen. (Sie werden gut abschneiden, aber das sagt nichts über die Job-Performance voraus.)
- Behandeln Sie DevOps als „Softwareentwicklung Light". (Es ist ein anderer Fähigkeitssatz.)
- Konzentrieren Sie sich auf Tool-Breite. (Kubernetes-Kenntnisse sagen nicht voraus, ob sie etwas anderes betreiben können.)
- Ignorieren Sie Live-Interviews. (Über ein Problem zu sprechen zeigt ihr Denken.)
Tun Sie:
- Präsentieren Sie realistische Einschränkungen. (Budgetgrenzen, Zeit bis zur Markteinführung, Teamgröße.)
- Testen Sie das Urteilsvermögen, nicht Fakten. (Können sie erklären, warum sie Terraform über CloudFormation gewählt haben?)
- Zeichnen Sie ihre Erklärungen auf. (Asynchrone Troubleshooting-Übungen zeigen keine Begründung; Live tut es.)
DevOps-Einstellung in großem Maßstab
Wenn Sie 5 oder mehr DevOps-Ingenieure einstellen, verwenden Sie einen strukturierten Bewertungsprozess mit dieser Rubrik. Erstellen Sie Szenarien einmal als Template, verwenden Sie sie erneut und vergleichen Sie Ergebnisse über Kandidaten hinweg. Die Konsistenz verbessert das Signal. Oder überspringen Sie das Setup komplett: ClarityHires fertiges DevOps-Assessment-Template enthält K8s-, Terraform- und CI/CD-Szenarien plus eine gewichtete Bewertungsrubrik.
Für tiefere fachspezifische Bewertungen erkunden Sie AWS vs Azure vs GCP Test-Frameworks, um Cloud-spezifische Lücken zu identifizieren.