Scorecard de entrevista para Ingeniero DevOps
Un scorecard estructurado para entrevistar a un Ingeniero DevOps: seis competencias con pesos, qué es realmente un 1 y qué es un 5, y preguntas que sacan evidencia en vez de opiniones. Imprimilo o copialo a tu ATS.
El scorecard para Ingeniero DevOps
| Competencia | Peso | Puntaje 1 — cómo se ve | Puntaje 5 — cómo se ve |
|---|---|---|---|
| Infraestructura como código Mide si la infraestructura está definida, revisada y es reproducible en control de versiones, lo que define si un entorno se puede reconstruir sin quien lo construyó. | 20% | Admite que producción se desvió del código y que los cambios se siguen aplicando a mano; no puede decir cuándo se aplicó la configuración por última vez sin conflictos. | Describe cómo organiza estado y módulos, cómo se revisa un cambio antes de llegar a producción y qué hace cuando un plan muestra drift inesperado. |
| Pipelines e ingeniería de releases Mide si la persona puede volver los deploys frecuentes, reversibles y aburridos, lo que define cuánto riesgo carga cada release para el equipo de producto. | 18% | Describe el deploy como un evento agendado con pasos manuales; el rollback consiste en restaurar un backup y no puede decir cuánto tarda. | Da la frecuencia de deploy y el tiempo de rollback de un sistema que tuvo a cargo, y explica un cambio concreto de pipeline que movió alguno de esos números. |
| Observabilidad y respuesta a incidentes Mide si la persona puede detectar, diagnosticar y cerrar incidentes con evidencia, y convertir cada uno en un cambio que evita la repetición. | 18% | Recuerda los incidentes como caídas que se arreglaron; las alertas son muchas y se ignoran de rutina, y ningún postmortem dejó una acción con seguimiento. | Recorre un incidente de punta a punta — señal, hipótesis, mitigación, causa raíz — y nombra la alerta o el control que se agregó después. |
| Confiabilidad, capacidad y costo Mide si la persona dimensiona y ajusta infraestructura contra demanda medida, lo que decide si la plataforma aguanta un pico y cuánto cuesta en reposo. | 15% | Dimensiona recursos copiando el entorno anterior; considera el costo un tema de finanzas y no puede nombrar la línea más cara de la factura. | Cita un patrón de carga que midió, el cambio de escalado o dimensionamiento que lo justificó y su efecto en el margen disponible y en el gasto mensual. |
| Accesos, secretos y cadena de build Mide si credenciales, permisos e insumos de build están controlados por defecto, porque un rol de plataforma tiene las llaves de todos los entornos a la vez. | 15% | Comparte credenciales de larga vida por chat o en un repositorio; describe las revisiones de acceso como algo que nunca ocurrió en sus sistemas. | Describe haber rotado una credencial sin caída, haber reducido permisos tras una revisión y dónde viven los secretos para que no exista copia humana. |
| Experiencia de desarrollo y adopción de la plataforma Mide si la persona construye caminos que los equipos de producto realmente usan, porque una herramienta sin adopción deja el trabajo manual intacto y agrega mantenimiento. | 14% | Mide el éxito por herramientas entregadas; no puede nombrar un equipo que haya adoptado la plataforma ni una herramienta que quedó abandonada. | Describe haber hablado con los equipos antes de construir, un flujo que se acortó de forma medible y una herramienta que dio de baja porque nadie la usaba. |
Los pesos suman 100. Acordalos antes de la primera entrevista, no después: ajustar pesos cuando ya hay puntajes es la forma en que un panel justifica a su favorito.
Preguntas que sacan evidencia
Cada una pide algo que ya pasó, con suficiente detalle como para verificarlo. Las hipotéticas premian el ensayo, no la trayectoria.
- Cuénteme el último incidente de producción por el que lo llamaron. ¿Cuál fue la primera señal, qué descartó y qué cambió después?
- Describa un entorno que haya reconstruido desde código. ¿Qué seguía siendo manual y cómo descubrió que el código y el sistema real se habían desviado?
- ¿Cuáles eran la frecuencia de deploy y el tiempo de rollback en su último sistema, y qué cambió personalmente para mover alguno de esos números?
- Hábleme de una credencial o un permiso que tuvo que cambiar sobre un sistema en marcha. ¿Cómo secuenció el cambio para que nada se cayera?
- Mencione una herramienta que haya construido y que un equipo de producto adoptó. ¿Cómo supo que la usaban y qué tuvo que cambiar tras su feedback?
Señales de alarma
- Enumera herramientas en el CV pero no puede describir un cambio que haya hecho sobre un sistema en producción.
- Considera normal el acceso manual a producción y no tiene ningún entorno definido en control de versiones.
- Todas sus historias de incidentes terminan en la mitigación, sin causa raíz ni acción de seguimiento.
- Trata a los desarrolladores como usuarios a controlar y no como los equipos a los que la plataforma sirve.
Cómo usar este scorecard
- Acordá los pesos con el panel antes de que alguien entreviste, y dejalos por escrito.
- Cada entrevistador puntúa todas las competencias por separado, con una nota que cite lo que el candidato dijo textualmente.
- Comparen los puntajes antes de discutirlos. Discutir primero ancla al panel en quien habla más fuerte.
Armar un scorecard a medida → · Cadena booleana para buscar Ingeniero DevOps →
Preguntas frecuentes
¿Qué debe cubrir una entrevista de ingeniero DevOps?
Infraestructura como código, pipelines y seguridad de release, observabilidad y respuesta a incidentes, capacidad y costo, accesos y secretos, y cómo usan los equipos de producto lo que construye. Conviene preguntar por sistemas que operó, no por herramientas que conoce de nombre. La señal más fuerte es un incidente concreto que pueda narrar de punta a punta.
¿Cómo diferenciar DevOps, SRE y platform engineering al armar el scorecard?
Los títulos se superponen, así que conviene puntuar el trabajo y no la etiqueta. Si el rol está mayormente de guardia por disponibilidad, pesan más la respuesta a incidentes y la confiabilidad; si se trata de construir caminos para otros equipos, pesan más la infraestructura como código y la experiencia de desarrollo. Los pesos se definen antes de entrevistar para que la vara no se mueva entre candidatos.
¿Cómo verificar que un candidato DevOps tiene experiencia real en producción?
Pedir números que debería saber: frecuencia de deploy, tiempo de rollback, la línea más cara de la factura de nube, cuánto tardó en detectarse el último incidente. Quien operó el sistema los tiene; quien solo lo miró, no. Registrar cada respuesta con la evidencia citada al lado del puntaje permite comparar candidatos después sin depender de la memoria.
Cuando lo que está en juego es una contratación real, usá evidencia
Estas herramientas son heurísticas rápidas. Verdict lee el CV contra tu descripción de puesto y puntúa seis dimensiones con citas textuales como evidencia — un documento de contratación que podés defender.