¿Qué evalúan realmente las entrevistas para DevOps?

Con quién hablas realmente

En la mayoría de los puestos DevOps no hablarás con un reclutador generalista en las rondas técnicas. Después de un filtro inicial (a menudo un talent partner verificando periodo de preaviso, salario, permiso de trabajo), quienes hacen las preguntas difíciles suelen ser quienes trabajarían contigo: un líder de plataforma o SRE, un ingeniero DevOps senior, a veces el gerente de ingeniería que gestiona la guardia. En entornos regulados —finanzas, salud, cualquier cosa que toque PCI o SOC 2— un ingeniero de seguridad suele participar en al menos una ronda, porque el control de acceso y las pistas de auditoría son parte del trabajo, no una preocupación secundaria.

Esto importa porque estos entrevistadores normalmente han recibido páginas a las 3am por algo que se esperaría que resolvieras. No están evaluando si puedes definir "CI/CD" o enumerar servicios de AWS. Están evaluando si confiarían en ti con acceso a producción.

La prueba técnica: cómo se ve realmente

La mayoría de los procesos para este rol incluyen uno de tres formatos, a veces dos de ellos:

Un ejercicio para llevar a casa o en vivo con infraestructura rota real. Puedes recibir un repo con un módulo de Terraform que falla al aplicarse, un Dockerfile que construye una imagen de 2GB cuando debería construir 200MB, o un pipeline de GitHub Actions/GitLab CI que pasa localmente pero falla en el runner. Se te pide arreglarlo y explicar tu razonamiento, no solo pegar un diff que funcione. Los entrevistadores prestan atención a si revisas la salida del plan antes de aplicar, si miras los códigos de salida y logs antes de adivinar, y si explicas por qué funciona el arreglo en lugar de que funciona.

Una sesión de depuración en vivo o pair programming. Compartes tu pantalla, te dan un clúster de Kubernetes (a menudo kind o minikube) con un pod atascado en CrashLoopBackOff, o un servicio devolviendo 502s detrás de un balanceador de carga, y hablas en tiempo real sobre tu diagnóstico: kubectl describe pod, revisando límites de recursos, leyendo eventos antes que logs, verificando si es la app o el ingress. El valor está completamente en la narración. Silencio mientras escribes es peor señal que una primera suposición errónea seguida de un siguiente paso sensato.

Una ronda de diseño de sistemas verbal o en pizarra. Diseña un pipeline de despliegue para un servicio con requisito de uptime estricto, o diseña cómo harías una migración de esquema con cero downtime, o diseña monitoreo para un conjunto de microservicios. Estos se juzgan por trade-offs: blue-green versus canary, por qué elegirías una política de autoescalado sobre otra, qué pondrías en un dashboard versus qué alertarías, cómo establecerías un SLO y qué harías cuando se agote el error budget.

Las preguntas que realmente prueban competencia

Algunas preguntas aparecen en casi todas las entrevistas DevOps, y cada una tiene una versión que separa a quienes han hecho el trabajo de quienes han leído sobre él.

"Cuéntame sobre un incidente que hayas gestionado." Una respuesta real nombra el síntoma, los pasos diagnósticos en orden, la causa raíz real, el arreglo inmediato y —crucialmente— qué cambió después: una nueva alerta, un runbook, un cambio en una compuerta de despliegue. También suele incluir algo que salió mal en la respuesta misma, porque los incidentes rara vez van limpiamente. Si la historia no tiene postmortem ni acción de seguimiento, el entrevistador preguntará qué cambió, y necesita haber una respuesta.

"¿Cómo gestionas secretos?" Están escuchando si distingues entre secretos en control de versiones (un fallo), secretos en variables de entorno (respuesta parcial), y secretos extraídos en runtime desde algo como Vault, AWS Secrets Manager, o SSM Parameter Store con roles IAM con scope y rotación. Puntos extra, sin que te pregunten, por mencionar cómo rotarías una credencial ya filtrada, porque esa es la pregunta detrás de la pregunta.

"¿Cuál es la diferencia entre tu monitoreo y tu alertado?" Esto prueba si piensas en SLIs y SLOs o solo en dashboards. Una respuesta sólida separa lo que mirarías durante una investigación (métricas, traces, logs —idealmente nombrados: Prometheus/Grafana, Datadog, el stack ELK o Loki) de lo que realmente debería despertar a alguien, y explica por qué la fatiga de alertas es un fallo de diseño, no una inevitabilidad.

"¿Cómo harías rollback de esto?" Preguntado sobre casi cualquier escenario de despliegue. La respuesta necesita un mecanismo concreto —un tag de imagen anterior, una revisión de Helm, una migración de base de datos que sea reversible o al menos forward-compatible— no "simplemente redesplegaríamos la versión antigua," que asume que la versión antigua aún es construible y que el rollback mismo no romperá otra cosa.

"¿Por qué Terraform/Ansible/Puppet sobre la alternativa?" Menos sobre la herramienta y más sobre si entiendes gestión de estado declarativa versus imperativa, qué es drift, y cómo lo detectas y reconcilias. Si tu equipo usa GitOps (ArgoCD, Flux), espera una pregunta sobre qué pasa cuando alguien cambia algo directamente en el clúster en lugar de a través de Git, porque esa es la fricción diaria real del modelo.

Cómo suena una respuesta superficial

Para alguien que hace este trabajo, una respuesta superficial tiene una forma específica. Nombra herramientas sin nombrar una decisión: "usamos Kubernetes y Terraform y Jenkins" no dice nada al entrevistador sobre lo que realmente elegiste o por qué. Omite el modo de fallo: describir un proceso de despliegue sin mencionar qué pasa cuando falla, o una configuración de monitoreo sin mencionar qué no estás observando actualmente. Trata "lo reiniciaría" como un diagnóstico en lugar de una medida temporal —reiniciar un pod puede limpiar un síntoma, pero si no puedes decir qué causó el crash, el entrevistador sabe que estarías de vuelta a las 3am haciéndolo de nuevo. Y responde preguntas de diseño de sistemas con una sola arquitectura y sin alternativas consideradas, lo que se lee como haber memorizado un diagrama en lugar de haber sopesado trade-offs en un sistema real con restricciones reales —costo, tamaño del equipo, herramientas existentes.

Lo inverso también es cierto y vale la pena saberlo: sobre-explicar cada acrónimo, o recitar una definición de libro de texto de despliegue blue-green cuando te preguntan cómo desplegarías un servicio específico, se lee de la misma manera. El entrevistador quiere tu razonamiento aplicado a su escenario, no una conferencia general.

Qué hacer antes de la entrevista

Revisa tus últimos dos o tres incidentes reales, migraciones o cambios de infraestructura y escribe, en orden: síntoma, pasos de diagnóstico, arreglo, y qué cambió después. Si no puedes llenar la última parte, vale la pena notarlo antes de la entrevista, no durante ella.

Si el anuncio del rol menciona herramientas específicas —Terraform sobre Pulumi, EKS sobre Kubernetes autogestionado, Datadog sobre Prometheus de código abierto— verifica tu propia experiencia contra ese stack honestamente. Donde hayas usado el equivalente pero no la herramienta exacta, dilo y explica el mapeo; los entrevistadores generalmente respetan "He usado Chef, no Puppet, pero el modelo es el mismo" mucho más que una afirmación vaga de familiaridad que se cae con una pregunta de seguimiento.

Y si estás enviando un alto volumen de aplicaciones sin recibir respuesta, vale la pena verificar si los requisitos específicos del anuncio aparecen lo suficientemente temprano en tu CV para llegar a esta etapa —la entrevista solo prueba lo que ya sabes; no puede arreglar un CV que entierra la experiencia en Kubernetes y Terraform que el anuncio pedía en la página dos.