Test DevOps engineer: domande di esempio e template di valutazione
Perché le domande generiche di infrastruttura falliscono
La maggior parte delle valutazioni DevOps fa domande da manuale: "Cos'è un container?" o "Definisci CICD." Queste domande misurano recall di trivia, non se qualcuno può progettare un sistema resiliente sotto pressione o debuggare un incident di produzione alle 2 di notte.
Un vero test DevOps dovrebbe misurare il giudizio, non i fatti. Dovrebbe testare se qualcuno capisce trade-off tra automazione e operabilità, sa quando scalare orizzontalmente vs verticalmente, e può ragionare sui modi di failure.
Ecco come si presenta una valutazione DevOps con segnale.
Categoria 1: design infrastrutturale sotto vincoli
Domanda basata su scenario:
"Hai un'applicazione che gira su una singola istanza EC2. Gestisce 1000 RPS, usa 70% CPU e ha 4GB di RAM con 60% di utilizzo. Il tuo SLA è 99,9% uptime. L'applicazione è stateless. Che cambiamenti faresti, e in che ordine? Che trade-off stai facendo?"
Questo testa:
- Comprensione di scalabilità vs ridondanza (entrambe necessarie per 99,9%)
- Consapevolezza dei costi
- Conoscenza di sequencing (failover prima dell'ottimizzazione)
- Articolazione dei trade-off
Una candidata che dice "aggiungi un load balancer e tira su due istanze in più in un'altra AZ" sta pensando chiaramente. Una candidata che dice "passa a Kubernetes" potrebbe fare pattern-matching senza capire il vincolo.
Categoria 2: response agli incident e troubleshooting
Domanda basata su scenario:
"La tua pipeline CI/CD fallisce su build casuali. L'errore è 'connection timeout to Docker registry.' Il problema accade circa una volta ogni 20 build. Cosa controlli per primo, e che instrumentation aggiungeresti?"
Questo testa:
- Metodologia sistematica di debugging
- Comprensione di isolamento di rete e autenticazione
- Pensiero di observability
- Prioritizzazione
Una candidata che inizia con "controlla la pagina di status del Docker registry" è meno riflessiva di una che dice "primo: è retry-able e abbiamo aggiunto rate limiting? secondo: controlla se il token del registry sta scadendo a metà build o se la nostra config di rete è cambiata."
Categoria 3: review di codice e configurazione
Esercizio live:
Fornisci uno snippet Terraform di 30 righe o una config Docker Compose con problemi intenzionali. Chiedi alla candidata di identificare i problemi e spiegare il fix.
Esempi di problemi Terraform:
- Security group che permette 0.0.0.0/0 a una porta DB
- Policy di retention backup mancante su RDS
- Password DB hardcoded in variabili
- Niente tag per allocazione costi
Esempi di problemi Compose:
- Container privilegiati senza giustificazione
- Health check mancanti
- Logging su stdout senza limiti (rischio disk fill)
- Niente resource constraint
Questo testa se hanno spedito sistemi in produzione e imparato cosa si rompe.
Categoria 4: architettura e selezione strumenti
Conversazione:
"Dobbiamo coordinare job su 50 microservizi. Ogni job dura 2-30 minuti. Vogliamo garanzie forti di ordering. Cosa useresti? Portami attraverso i trade-off."
Risposte valide:
- Temporal (orchestrazione workflow, strong ordering, complesso da operare)
- Step Functions (managed, limitato a AWS, meno flessibile)
- Pub/Sub + app consumatrice (basso accoppiamento, ordering debole, operativamente più semplice)
- Kubernetes Jobs + controller custom (flessibile, più overhead operativo)
L'intervistatrice dovrebbe spingere indietro: "Step Functions sembra più semplice." La candidata dovrebbe difendere: "Finché devi rifare un job che è già parzialmente succeduto, o finché hai un job di 2 minuti che gira su SLA di 10 minuti, allora ti serve la state machine di workflow."
Questo testa giudizio ed esperienza, non conoscenza.
Categoria 5: observability e monitoring
Breve scenario:
"Hai deployato un cambiamento e il tuo error rate è andato dal 0,1% al 0,5%. La latenza p99 è la stessa. Il cambiamento ha toccato logging e tracing, non gestione delle request. Dove guardi?"
Risposta debole: "Controlla i log." Risposta forte: "Prima, controllerei se l'instrumentation di tracing o il livello di logging è cambiato — potrebbe aumentare la visibilità degli errori senza aumentare gli errori effettivi. Poi guarderei la cardinalità dei log. Poi controllerei se stiamo loggando nuovi casi di errore che prima non venivano catturati."
Come strutturare la valutazione
- Take-home di 30 minuti: Scenario design infrastruttura + review configurazione. Chiedi loro di spiegare le decisioni.
- Colloquio sincrono di 30 minuti: Conversazione di troubleshooting live + discussione architettura. Registra il loro ragionamento.
- Abbina la valutazione con segnali di integrità di digitazione. Le candidate DevOps che copiano soluzioni intere da ChatGPT o StackOverflow mostreranno pattern di edit insoliti. ClarityHire cattura questo di default.
Il contrappunto onesto
Non ogni ruolo ha bisogno di questa profondità. I ruoli DevOps o SRE junior beneficiano di filtraggio più semplice. Per hiring senior+, questa rubrica si applica. Per mid-level, abbassa la complessità ma mantieni la struttura basata su scenario.
Prossimi passi
Pronto a valutare le tue candidate DevOps con test reali? Dai un'occhiata al nostro hub di valutazione DevOps e Cloud Engineering per template e guida su come valutare le skill di DevOps engineer.