Cómo evaluar las habilidades de ingenieros DevOps: Metodología y Rúbrica
El error común en la evaluación de DevOps
La mayoría de los equipos evalúan a los candidatos DevOps como si fueran ingenieros de software: ejercicios de codificación. Pero DevOps no trata principalmente de codificación. Se trata de pensamiento sistémico, criterio en la evaluación de compensaciones y resiliencia operacional.
Un candidato podría escribir un código Terraform impecable y fallar catastróficamente cuando la base de datos genera una alerta a medianoche. Por el contrario, un candidato con código deficiente podría diseñar un sistema que sobreviva a una falla completa de zona sin intervención manual.
Necesitas un marco de trabajo diferente.
Qué habilidades DevOps predicen realmente el desempeño en el trabajo
1. Pensamiento sistémico y razonamiento sobre modos de fallo
¿Pueden identificar modos de fallo? ¿Pueden diseñar para ellos de forma proactiva?
Qué evaluar: Proporciónales una arquitectura simple (una aplicación web que se comunica con RDS) y pregunta: "¿Qué se rompe aquí? ¿Cuál es el radio de impacto? ¿Cómo lo mitigan?" No les pidas que diseñen Netflix. Pídeles que endurezcan una configuración básica.
Una buena respuesta: "RDS es un punto único de fallo. Añadiría réplicas de lectura para failover y un pool de conexiones para evitar el agotamiento de conexiones. La aplicación en sí debería ser sin estado y con balanceador de carga. Añadiría un circuit breaker para la base de datos."
Una respuesta débil: "Usa Kubernetes."
2. Pragmatismo operacional
¿Eligen la solución más simple que realmente funciona? ¿O recurren a la herramienta más sofisticada?
Qué evaluar: "Necesitas ejecutar un trabajo de copia de seguridad diaria. Tienes dos opciones: Kubernetes CronJob o Lambda. Tu equipo no tiene Kubernetes existente. Analiza los equilibrios."
Buena respuesta: "Lambda es más simple de operar si no estás ejecutando Kubernetes. Menos piezas móviles, más fácil de depurar, integración CloudWatch incorporada. El equilibrio es un tiempo de espera de 15 minutos y latencia de arranque en frío, que no importa para una copia de seguridad. Usaría Lambda."
Respuesta débil: "Siempre usa Kubernetes porque es más portátil."
3. Observabilidad y depuración
¿Pueden diseñar monitoreo? ¿Pueden rastrear un problema desde una alerta hasta la causa raíz?
Qué evaluar: Las entrevistas de codificación en directo no aplican aquí. En su lugar, proporciona una alerta de producción: "CPU está al 80% en tu instancia Postgres. Parece aleatorio. ¿Diagnósticos?" Pídeles que narren: ¿qué herramientas de consulta usarían, qué verificarían, en qué orden?
Buena respuesta: "Primero, verificaría pg_stat_statements para las consultas más lentas, luego comprobaría si se correlaciona con un endpoint específico de aplicación, luego examinaría estadísticas de índices para ver si falta un índice o está inflado."
4. Criterio en automatización
¿Cuándo algo debe automatizarse en lugar de hacerse manualmente?
Qué evaluar: "Implementas 20 veces al día, pero las migraciones de base de datos ocurren solo una vez por semana. ¿Deberías automatizar las migraciones de la misma manera que los despliegues?"
Buena respuesta: "No. La automatización reduce la carga cognitiva cuando la operación es frecuente y de bajo riesgo. Las migraciones son infrecuentes y de alto riesgo: quieres que un humano revise y apruebe antes de ejecutar, y quieres una ejecución de prueba primero."
Respuesta débil: "Automatiza todo."
5. Equilibrios en arquitectura en la nube
AWS vs. Azure vs. GCP no trata sobre características, trata sobre operaciones y costo.
Qué evaluar: Presenta un escenario y pide un desglose de costo-beneficio. "Estás construyendo una plataforma de microservicios. ¿Deberías usar Kubernetes gestionado (EKS/AKS/GKE) o autogestionado?"
Lo ideal es que digan: "Gestionado es mejor para equipos pequeños a medianos. Maneja el plano de control, actualizaciones y redes por ti. El equilibrio es menos control y un costo ligeramente superior. Autogestionado es mejor si tienes un equipo dedicado y requisitos específicos de redes."
Estructura de la evaluación
Parte 1: Escenario para trabajar en casa (2 horas)
Proporciona un diagrama de arquitectura o una base de código Terraform con lagunas o problemas de seguridad intencionales. Pregunta:
- Identifica problemas
- Propone correcciones con análisis de equilibrio
- Esboza una estrategia de monitoreo para este sistema
Esto es amigable con la asincronía y prueba conocimiento a escala.
Parte 2: Resolución de problemas en directo (45 minutos)
Escenario: Pico de latencia en producción. Cuéntame cómo lo depurarías.
El candidato habla; tú escuchas. Estás evaluando:
- Enfoque sistemático (no adivinanzas)
- Conocimiento de herramientas de observabilidad
- Priorización (dónde mirar primero)
- Comunicación (¿pueden explicar su razonamiento?)
Parte 3: Conversación sobre arquitectura (30 minutos)
Presenta una restricción o requisito. "Necesitamos migrar 50TB de datos a una nueva base de datos sin tiempo de inactividad. ¿Cuál es tu enfoque?"
Esto prueba el criterio y el pragmatismo. No hay una respuesta correcta: estás escuchando razonamientos sobre radio de impacto, planes de reversión y complejidad operacional.
Rúbrica: Marco de puntuación
| Habilidad | Nivel 1 (Insuficiente) | Nivel 2 (Cumple) | Nivel 3 (Supera) |
|---|---|---|---|
| Razonamiento sobre modos de fallo | Identifica solo problemas obvios | Piensa 2-3 capas de profundidad (fallo primario y en cascada) | Anticipa casos extremos y radio de impacto |
| Criterio en automatización | Automatiza indiscriminadamente | Elige la herramienta correcta para frecuencia/riesgo | Diseña automatización con reversión explícita y compuertas de seguridad |
| Observabilidad | Conoce métricas básicas; piensa que los registros son para depuración | Instrumenta tanto para monitoreo como depuración; entiende cardinalidad | Diseña observabilidad para experiencia on-call; correlaciona señales |
| Conciencia de costos | Ignora costos; prefiere "más potente" | Equilibra rendimiento vs. costo dentro de restricciones | Propone optimizaciones de costos sin sacrificar confiabilidad |
| Diseño de sistemas | Punto único de fallo; sin plan de respaldo | Añade redundancia donde sea necesario; entiende RPO/RTO | Diseña multi-región o multi-nube con failover claro |
Qué evitar
No:
- Pidas a candidatos DevOps que resuelvan problemas LeetCode. (Puntuarán bien pero no predicen desempeño en el trabajo.)
- Trates DevOps como "ingeniería de software lite." (Es un conjunto de habilidades diferente.)
- Te enfoques en amplitud de herramientas. (El conocimiento de Kubernetes no predice si pueden operar cualquier otra cosa.)
- Ignores entrevistas en directo. (Hablar sobre un problema revela su razonamiento.)
Sí:
- Presenta restricciones realistas. (Límites presupuestarios, tiempo para comercializar, tamaño del equipo.)
- Prueba el criterio, no los hechos. (¿Pueden explicar por qué eligieron Terraform sobre CloudFormation?)
- Graba sus explicaciones. (Los ejercicios de resolución de problemas asincrónicos no exponen el razonamiento; el directo sí.)
Contratación DevOps a escala
Si contratas 5+ ingenieros DevOps, usa un proceso de evaluación estructurado con esta rúbrica. Elabora plantillas de escenarios una vez, reutilizalas y compara resultados entre candidatos. La consistencia mejora la señal. O sáltate la configuración por completo: la plantilla de evaluación DevOps lista para usar de ClarityHire incluye escenarios de K8s, Terraform y CI/CD más una rúbrica de puntuación ponderada.
Para evaluaciones más específicas de habilidades, explora marcos de pruebas AWS vs Azure vs GCP para exponer brechas específicas de nube.