Evaluación de competencias
Evaluación de competencias de Ingeniero DevOps
Un ingeniero DevOps débil raramente falla de forma ruidosa el primer día. Falla silenciosamente a lo largo de meses, a medida que se acumulan pipelines frágiles, infraestructura indocumentada y correcciones manuales heroicas, hasta que una incidencia lo expone todo de golpe. Por eso los filtros habituales son engañosos aquí. Todos los candidatos listan las mismas herramientas, así que un currículum con Terraform y Kubernetes no dice prácticamente nada sobre si alguien puede razonar bajo presión, y las rondas de algoritmos en pizarra evalúan una habilidad que el puesto apenas utiliza.
El objetivo del puesto es hacer que los despliegues sean seguros, rápidos y aburridos, por lo que la señal que se busca al contratar es el criterio sobre el riesgo y qué automatizar, no la extensión de la lista de herramientas. Una buena evaluación da a los candidatos el trabajo real —un pipeline roto, un cambio de infraestructura arriesgado, una incidencia parcial que razonar— y observa cómo diagnostican y deciden. H-Evaluate genera esa tarea a partir de tu descripción de puesto, con generación por puesto, de modo que el ejercicio refleja los problemas de despliegue reales de tu equipo en lugar de un escenario genérico que el candidato pueda ensayar.
Qué evaluar
Las competencias que predicen el desempeño en este puesto, asignadas a los cinco pilares de contratación.
Trabajo en pipeline e incidencias
Depurar un pipeline de CI/CD fallido o razonar a través de una incidencia parcial en un entorno en vivo, observando cómo aíslan la causa, no si memorizaron la solución.
Fluidez en infraestructura como código
Pensar en sistemas reproducibles, revisables y versionados: leer un diff de IaC para detectar el cambio que silenciosamente amplía un permiso IAM o arriesga la pérdida de datos al aplicarlo.
Instinto de automatización
Ver trabajo repetitivo y buscar una solución duradera, sabiendo cuándo un script es excesivo: razonar sobre qué automatizar frente a qué mantener con supervisión humana.
Criterio ante incidencias y radio de impacto
Cómo gestiona un candidato un pipeline en rojo a las 2 de la madrugada o una decisión de rollback: diagnóstico antes de acción, conteniendo el radio de impacto antes de buscar la causa raíz.
Empatía con el desarrollador y comunicación
Tratar la plataforma como un producto con usuarios: escribir postmortems sin culpas, documentación clara y mensajes de error que alguien pueda seguir realmente.
Fluidez en IA
Delegar las subtareas correctas a la IA cerca de producción, detectando una corrección convincente pero incorrecta y verificando antes de que nada toque un sistema en vivo.
Cómo estructurar la evaluación
- 1Usa una tarea realista que refleje un mal martes: un pipeline roto, un diff de IaC arriesgado o una incidencia que razonar, no un cuestionario de definiciones.
- 2Observa qué comprueban primero: registros y una hipótesis declarada antes de tocar nada, y si mencionan el radio de impacto.
- 3Dales herramientas de IA en la tarea y observa si detectan una corrección de infraestructura convincente pero incorrecta antes de que se despliegue.
- 4Mantén una única muestra de trabajo de 45 a 60 minutos; lo que observas importa más que la duración, y las tareas largas perjudican a quienes tienen responsabilidades de cuidado.
- 5Califica con una rúbrica escrita antes de que el candidato empiece, para que dos evaluadores califiquen la misma sesión de la misma manera.
Señales que predicen el éxito
- +Consulta los registros y formula una hipótesis antes de cambiar nada
- +Habla en términos de radio de impacto: qué se rompe si me equivoco y cómo lo limito
- +Automatiza el trabajo repetitivo pero nombra los casos que mantendría deliberadamente en manos humanas
- +Verifica el resultado de IA antes de que se acerque siquiera a producción
Señales de alerta
- –Salta directamente a modificar producción sin entender el fallo
- –Confiado, rápido e incorrecto, sin ningún instinto de verificar
- –Automatiza las decisiones que deberían permanecer en manos humanas, incluidos los juicios de valor
- –Pega el resultado de IA tal cual y no puede explicar por qué es correcto
Evaluación frente a entrevista
Una entrevista DevOps premia un recorrido fluido por herramientas y sistemas pasados; no puede mostrar cómo se comporta alguien cuando el pipeline está en rojo y una corrección está a un apply de distancia de una incidencia. Una evaluación estructurada hace exactamente eso: orden de diagnóstico, qué verifican antes de tocar producción, si detectan la sugerencia convincente pero incorrecta de la IA. Úsala para evidenciar criterio bajo presión y luego deja que la entrevista profundice en los trade-offs y las historias de incidencias que el trabajo reveló.
Evaluación de competencias
Configura esta evaluación por puesto y seniority
Observa cómo cambia el énfasis en tiempo real al cambiar el puesto y el nivel — sin registro.
Lecturas relacionadas
Cómo contratar a un ingeniero DevOps: guía 2026
Una guía práctica sobre cómo contratar a un ingeniero DevOps: qué evaluar, la muestra de trabajo que predice el éxito, preguntas de entrevista, y señales positivas y negativas.
El Marco 4D para la fluidez con la IA: de la Delegación a la Diligencia
La 'fluidez con la IA' es demasiado vaga para contratar en base a ella. El Marco 4D la divide en Delegación (Delegation), Descripción (Description), Discernimiento (Discernment) y Diligencia (Diligence): cuatro habilidades que puedes evaluar.
Los cinco pilares de la contratación: qué miden las evaluaciones
Los cinco pilares de la contratación — cognitivo, situacional, conductual, dominio y AI Fluency — predicen quién puede hacer el trabajo. Por qué una única puntuación oculta el panorama.
Preguntas frecuentes
¿Cómo se evalúa a un ingeniero DevOps?
Dales el trabajo real, no trivialidades. La señal más sólida proviene de una muestra de trabajo —depurar un pipeline de CI/CD roto, razonar a través de una incidencia o revisar un cambio de infraestructura como código en busca de riesgos— observada en vivo para ver cómo diagnostican, priorizan y deciden qué verificar antes de tocar producción. Las listas de herramientas y certificaciones cloud se correlacionan poco con quien realmente mantiene la producción aburrida y segura.
¿Qué habilidades debe cubrir una evaluación de ingeniero DevOps?
Instinto de automatización, criterio de respuesta a incidencias, fluidez en infraestructura como código, conciencia de seguridad y radio de impacto, y criterio de delegación para saber qué mantener con supervisión humana. La familiaridad con herramientas —un sistema CI concreto, un proveedor cloud— importa mucho menos que el razonamiento subyacente, porque las herramientas rotan cada pocos años mientras ese criterio se acumula durante una década.
¿Debe una evaluación DevOps permitir que los candidatos usen herramientas de IA?
Sí, y debe medir cómo las usan. Un ingeniero DevOps que confía ciegamente en el resultado de IA es peligroso cerca de producción. Evalúalo directamente: ¿el candidato delega las subtareas correctas, detecta una corrección convincente pero incorrecta y verifica antes de desplegar? La velocidad sin ese discernimiento es un riesgo, así que califica el momento en que detectan el error, no el momento en que terminan.
¿Cuánto tiempo debe durar una muestra de trabajo DevOps?
Una tarea realista —un pipeline roto o un cambio de infraestructura arriesgado— suele dar una señal sólida en 45 a 60 minutos. Cualquier cosa más larga arriesga sesgar en contra de personas con responsabilidades de cuidado y perjudica la experiencia del candidato. Lo que observas importa más que la duración: observa cómo diagnostican, priorizan y deciden qué verificar antes de tocar producción.