Come Valutare le Competenze dei DevOps Engineer: Metodologia e Rubrica
L'errore nella valutazione dei DevOps
La maggior parte dei team valuta i candidati DevOps come valutano gli ingegneri software: esercizi di coding. Ma DevOps non riguarda principalmente il coding. Si tratta di pensiero sistemico, capacità di giudizio sugli trade-off e resilienza operativa.
Un candidato potrebbe scrivere un bellissimo Terraform e fallire in modo catastrofico quando il database viene sottoposto a paging a mezzanotte. Al contrario, un candidato con codice scarso potrebbe progettare un sistema che sopravvive al fallimento di un'intera zona senza alcun intervento manuale.
Hai bisogno di un framework diverso.
Quali competenze DevOps predicono effettivamente le prestazioni lavorative
1. Pensiero sistemico e ragionamento sulle modalità di guasto
Riescono a identificare le modalità di guasto? Riescono a progettare per loro in modo proattivo?
Cosa valutare: Fornisci loro un'architettura semplice (un'app web che comunica con RDS) e chiedi: "Cosa si rompe qui? Qual è il raggio di esplosione? Come lo mitighi?" Non chiedere loro di progettare Netflix. Chiedi loro di rafforzare un setup di base.
Una buona risposta: "RDS è un singolo punto di guasto. Aggiungerei repliche di lettura per il failover e un pool di connessioni per prevenire l'esaurimento delle connessioni. L'app stessa dovrebbe essere stateless e con load balancing. Aggiungerei un circuit breaker per il database."
Una risposta debole: "Usa Kubernetes."
2. Pragmatismo operativo
Scelgono la soluzione più semplice che funziona? O raggiungono lo strumento più sofisticato?
Cosa valutare: "Hai bisogno di eseguire un job di backup giornaliero. Hai due opzioni: Kubernetes CronJob o Lambda. Il tuo team non ha Kubernetes esistente. Parla dei trade-off."
Buona risposta: "Lambda è più semplice da gestire se non stai già eseguendo Kubernetes. Meno parti in movimento, più facile da debuggare, integrazione CloudWatch integrata. Il trade-off è il timeout di 15 minuti e la latenza di cold start, che non importa per un backup. Userei Lambda."
Risposta debole: "Usa sempre Kubernetes perché è più portabile."
3. Osservabilità e debugging
Riescono a progettare il monitoraggio? Riescono a tracciare un problema dall'avviso alla causa radice?
Cosa valutare: I live coding interview non si applicano qui. Invece, dai loro un avviso di produzione: "La CPU è all'80% sulla tua istanza Postgres. Sembra casuale. Diagnostica?" Chiedi loro di narrare: quali strumenti di query userebbero, cosa controllerebbero, in quale ordine?
Buona risposta: "Prima, controllerei pg_stat_statements per le query più lente, poi controllerei se corrisponde a un endpoint dell'applicazione specifico, poi guarderei le statistiche dell'indice per vedere se un indice manca o è gonfio."
4. Giudizio sull'automazione
Quando qualcosa dovrebbe essere automatizzato rispetto a manuale?
Cosa valutare: "Distribuisci 20 volte al giorno, ma le migrazioni del database avvengono solo una volta a settimana. Dovresti automatizzare le migrazioni allo stesso modo delle distribuzioni?"
Buona risposta: "No. L'automazione riduce il carico cognitivo quando l'operazione è frequente e a basso rischio. Le migrazioni sono infrequenti e ad alto rischio — vuoi che un umano riveda e approvi prima di eseguire, e vuoi un dry-run prima."
Risposta debole: "Automatizza tutto."
5. Trade-off dell'architettura cloud
AWS vs. Azure vs. GCP non riguarda le funzionalità — riguarda le operazioni e il costo.
Cosa valutare: Presenta uno scenario e chiedi una scomposizione costi-benefici. "Stai costruendo una piattaforma di microservizi. Dovresti usare Kubernetes gestito (EKS/AKS/GKE) o auto-gestito?"
Idealmente, diranno: "Gestito è meglio per team piccoli e medi. Gestisce il piano di controllo, gli aggiornamenti e il networking per te. Il trade-off è meno controllo e un costo leggermente più elevato. Auto-gestito è meglio se hai un team dedicato e requisiti di rete specifici."
Struttura della valutazione
Parte 1: Scenario take-home (2 ore)
Fornisci un diagramma architetturale o una base di codice Terraform con lacune intenzionali o problemi di sicurezza. Chiedi:
- Identificare i problemi
- Proporre correzioni con analisi dei trade-off
- Tracciare una strategia di monitoraggio per questo sistema
Questo è async-friendly e testa la conoscenza su larga scala.
Parte 2: Troubleshooting in diretta (45 minuti)
Scenario: Spike di latenza in produzione. Spiegami come la debuggheresti.
Il candidato parla; tu ascolti. Stai testando:
- Approccio sistematico (non indovinare)
- Conoscenza degli strumenti di osservabilità
- Prioritizzazione (dove guardare per primo)
- Comunicazione (riescono a spiegare il loro ragionamento)
Parte 3: Conversazione sull'architettura (30 minuti)
Presenta un vincolo o un requisito. "Abbiamo bisogno di migrare 50TB di dati in un nuovo database con zero downtime. Qual è il tuo approccio?"
Questo testa il giudizio e il pragmatismo. Non c'è una risposta giusta — stai ascoltando il ragionamento sul raggio di esplosione, i piani di rollback e la complessità operativa.
Rubrica: Framework di valutazione
| Competenza | Livello 1 (Al di sotto) | Livello 2 (Soddisfa) | Livello 3 (Supera) |
|---|---|---|---|
| Ragionamento sulle modalità di guasto | Identifica solo i problemi evidenti | Pensa 2-3 livelli in profondità (guasto primario e a cascata) | Anticipa i casi limite e il raggio di esplosione |
| Giudizio sull'automazione | Automatizza indiscriminatamente | Sceglie lo strumento giusto per frequenza/rischio | Progetta l'automazione con rollback esplicito e gate di sicurezza |
| Osservabilità | Conosce le metriche di base; pensa che i log siano per il debugging | Strumenta sia il monitoraggio che il debugging; comprende la cardinalità | Progetta l'osservabilità per l'esperienza on-call; correla i segnali |
| Consapevolezza dei costi | Ignora il costo; preferisce "più potente" | Bilancia le prestazioni rispetto al costo entro i vincoli | Propone ottimizzazioni dei costi senza sacrificare l'affidabilità |
| Progettazione del sistema | Singolo punto di guasto; nessun piano di backup | Aggiunge ridondanza dove necessario; comprende RPO/RTO | Progetta multi-regione o multi-cloud con failover chiaro |
Cosa evitare
Non:
- Chiedi ai candidati DevOps di risolvere problemi LeetCode. (Otterranno un buon punteggio ma non prevedranno le prestazioni sul lavoro.)
- Tratta DevOps come "ingegneria del software leggera." (È un set di competenze diverso.)
- Concentrati sulla larghezza degli strumenti. (La conoscenza di Kubernetes non predice se possono operare qualcos'altro.)
- Ignora i live interview. (Parlare di un problema rivela il loro ragionamento.)
Fai:
- Presenta vincoli realistici. (Limiti di budget, time to market, dimensione del team.)
- Testa il giudizio, non i fatti. (Riescono a spiegare perché hanno scelto Terraform rispetto a CloudFormation?)
- Registra le loro spiegazioni. (Gli esercizi di troubleshooting asincrono non emergono il ragionamento; il live lo fa.)
Hiring DevOps su larga scala
Se stai assumendo 5+ ingegneri DevOps, usa un processo di valutazione strutturato con questa rubrica. Modella gli scenari una volta, riutilizzali e confronta i risultati tra i candidati. La coerenza migliora il segnale. Oppure salta del tutto la configurazione: il template di assessment DevOps pronto all'uso di ClarityHire include scenari K8s, Terraform e CI/CD più una rubrica di valutazione ponderata.
Per valutazioni più profonde specifiche delle competenze, esplora AWS vs Azure vs GCP test framework per emergere le lacune specifiche del cloud.