Come valutare le skill degli engineer DevOps: metodologia e rubrica
L'errore della valutazione DevOps
La maggior parte dei team valuta candidate DevOps come valuta software engineer: esercizi di coding. Ma DevOps non riguarda primariamente il coding. Riguarda il systems thinking, il giudizio sui trade-off e la resilienza operativa.
Ti serve un framework diverso.
Quali skill DevOps predicono davvero la performance lavorativa
1. Systems thinking e ragionamento sui failure mode
Possono nominare i failure mode? Possono progettare proattivamente per essi?
Cosa valutare: dai loro un'architettura semplice e chiedi: "Cosa si rompe? Qual è il blast radius? Come mitighi?"
Buona risposta: "RDS è un single point of failure. Aggiungerei read replica per il failover e un connection pool. L'app dovrebbe essere stateless e loadbalanced."
2. Pragmatismo operativo
Scelgono la soluzione più semplice che funziona? O raggiungono lo strumento più fancy?
3. Observability e debugging
Possono progettare il monitoring? Possono tracciare un problema dall'alert alla root cause?
4. Giudizio sull'automazione
Quando qualcosa dovrebbe essere automatizzato vs manuale?
5. Trade-off di architettura cloud
AWS vs Azure vs GCP non riguarda le feature — riguarda operations e costi.
Struttura della valutazione
Parte 1: scenario take-home (2 ore)
Parte 2: troubleshooting live (45 minuti)
Parte 3: conversazione architetturale (30 minuti)
Rubrica
| Skill | Livello 1 | Livello 2 | Livello 3 |
|---|---|---|---|
| Ragionamento failure mode | Solo problemi evidenti | 2-3 livelli in profondità | Anticipa edge case |
| Giudizio automazione | Automatizza indiscriminatamente | Sceglie strumento giusto | Progetta con rollback e safety gate |
| Observability | Conosce metriche base | Instrumenta per monitoring e debugging | Progetta per esperienza on-call |
| Consapevolezza costi | Ignora i costi | Bilancia performance vs costi | Propone ottimizzazioni senza sacrificare affidabilità |
| System design | SPOF, niente backup plan | Aggiunge ridondanza | Progetta multi-region con failover chiaro |
Cosa evitare
Non: chiedere LeetCode, trattare DevOps come "software lite," focalizzarsi sull'ampiezza degli strumenti, ignorare i colloqui live.
Sì: presentare vincoli realistici, testare il giudizio non i fatti, registrare le spiegazioni.
Hiring DevOps a scala
Se assumi 5+ engineer DevOps, usa un processo di valutazione strutturato con questa rubrica.