Cómo evaluar skills de DevOps engineers: metodología y rúbrica
El error de evaluación DevOps
La mayoría evalúa candidatas DevOps como evalúan ingenieras de software: ejercicios de coding. Pero DevOps no es primariamente sobre coding. Es sobre pensamiento de sistemas, juicio de trade-offs y resiliencia operacional.
Necesitas un framework distinto.
Qué skills DevOps realmente predicen desempeño
1. Pensamiento de sistemas y razonamiento sobre modos de fallo
¿Pueden nombrar modos de fallo? ¿Diseñar para ellos proactivamente?
Qué evaluar: dales una arquitectura simple (web app hablando con RDS) y pregunta: "¿Qué se rompe? ¿Cuál es el blast radius? ¿Cómo lo mitigas?"
Buena respuesta: "RDS es punto único de fallo. Añadiría read replicas para failover y un connection pool. La app debería ser stateless y loadbalanced. Añadiría un circuit breaker."
Respuesta débil: "Usa Kubernetes."
2. Pragmatismo operacional
¿Eligen la solución más simple que funciona? ¿O recurren a la herramienta más fancy?
Qué evaluar: "Necesitas correr un job de backup diario. Tienes dos opciones: Kubernetes CronJob o Lambda. Tu equipo no tiene Kubernetes. Recórreme los trade-offs."
Buena respuesta: "Lambda es más simple si no estás corriendo Kubernetes ya. Menos partes móviles, más fácil de debuggear."
3. Observabilidad y debugging
¿Pueden diseñar monitoring? ¿Trazar problema desde alerta hasta causa raíz?
Qué evaluar: dales una alerta de producción: "CPU al 80% en tu instancia Postgres. Parece random. ¿Diagnósticos?"
4. Juicio de automatización
¿Cuándo automatizar vs manual?
Qué evaluar: "Despliegas 20 veces al día, pero migraciones de BD una vez por semana. ¿Deberías automatizarlas igual?"
Buena respuesta: "No. Automatización reduce carga cognitiva cuando la operación es frecuente y bajo riesgo. Las migraciones son infrecuentes y alto riesgo."
5. Trade-offs de arquitectura cloud
AWS vs Azure vs GCP no es sobre features — es sobre operaciones y costes.
Estructura de evaluación
Parte 1: escenario take-home (2 horas)
Provee diagrama de arquitectura o codebase Terraform con gaps intencionales o issues de seguridad. Pide identificar problemas, proponer fixes con análisis de trade-off, sketchear estrategia de monitoring.
Parte 2: troubleshooting en vivo (45 minutos)
Escenario: spike de latencia en producción. Recórreme cómo debuggearías.
Estás testeando: enfoque sistemático, conocimiento de tools de observabilidad, priorización, comunicación.
Parte 3: conversación de arquitectura (30 minutos)
"Necesitamos migrar 50TB de datos a una BD nueva con cero downtime. ¿Tu enfoque?"
Esto testea juicio y pragmatismo. No hay respuesta correcta — escuchas razonamiento sobre blast radius, planes de rollback, complejidad operacional.
Rúbrica
| Skill | Nivel 1 | Nivel 2 | Nivel 3 |
|---|---|---|---|
| Modos de fallo | Solo issues obvios | Piensa 2-3 capas profundo | Anticipa edge cases y blast radius |
| Juicio automatización | Automatiza indiscriminadamente | Elige tool correcto para frecuencia/riesgo | Diseña con rollback y safety gates |
| Observabilidad | Conoce métricas básicas | Instrumenta para monitoring y debugging | Diseña para experiencia on-call |
| Conciencia de coste | Ignora coste | Balancea performance vs coste | Propone optimizaciones sin sacrificar fiabilidad |
| Diseño de sistemas | SPOF, sin backup plan | Añade redundancia, entiende RPO/RTO | Diseña multi-region con failover claro |
Qué evitar
No: pidas resolver LeetCode, trates DevOps como "software lite," foques en breadth de tools, ignores entrevistas en vivo.
Sí: presenta restricciones realistas, testea juicio no hechos, graba sus explicaciones.
DevOps hiring a escala
Si contratas 5+ ingenieras DevOps, usa proceso estructurado con esta rúbrica. Templatea escenarios una vez, reutiliza, compara across candidatas.