Mock interview de DevOps engineer — práctica con IA

Las entrevistas de DevOps son engañosamente amplias. Los hiring managers buscan un generalista que pueda sostener un módulo de Terraform en una mano y un runbook en la otra — y van a sondear los momentos exactos en los que la infraestructura rompe la realidad. La mayoría de los candidatos no pierden puntos en trivia de herramientas, sino en las preguntas de segundo orden: «el apply ha hecho timeout, ¿cuál es tu siguiente paso?». Esta guía recorre cómo usar mock interviews con IA para ensayar las conversaciones que deciden las ofertas de DevOps.

Rondas típicas de una entrevista de DevOps engineer

Un loop típico de DevOps consta de cuatro o cinco rondas. Screening del recruiter por encaje, luego un screening técnico (45–60 minutos) que cubre CI/CD, infra-as-code, fundamentos de contenedores y un deep-dive de un proveedor cloud. Después llega una ronda de escenario o de incidente — recorre una caída real y cómo la depurarías. Luego una ronda de coding o scripting (Bash, Python o Go — normalmente parsear logs, escribir un pequeño CLI o arreglar un pipeline roto) y una ronda behavioral más de sistemas en la que te entregan una arquitectura medio rota y te piden que la endurezcas.

La ronda de escenario es donde más rinden los mocks con IA. Los entrevistadores reales improvisan — inventan la caída, presionan tu razonamiento y te tientan a conclusiones prematuras. El mock con IA reproduce ese patrón con fidelidad: prompt abierto, follow-ups que escalan, puntuación según cómo acotas las causas. La ronda de coding se sirve mejor con práctica de scripting hands-on, pero los walkthroughs verbales de fallos de pipeline encajan a la perfección dentro de un mock con IA.

Principales temas técnicos

Infrastructure as code

Terraform domina el pool de ofertas. Esté listo para hablar de gestión del state file (remote backends, locking, dividir el state por entorno), diseño de módulos (cuándo componer, cuándo inline), la diferencia entre count y for_each, y cómo refactorizar un root module monolítico sin romper producción. Pulumi y CDK aparecen en un 15–20 % de las ofertas — conozca el tradeoff (lenguaje real vs HCL declarativo) aunque no lo escriba a diario. Las preguntas de Ansible aún aparecen en roles de config-management; espere idempotencia de playbooks e inventario dinámico.

Kubernetes

El listón ha subido. «He usado kubectl» ya no basta. Espere: cómo se programa (schedule) un pod, qué pasa cuando un nodo entra en NotReady, por qué tu service devuelve 502 (pista: el endpoint no está en el objeto Endpoints), la diferencia entre requests y limits y qué provoca el evict de un pod, cuándo usarías un DaemonSet vs un Deployment, cómo interactúan los rolling updates con los PodDisruptionBudgets. Los loops senior añaden operators, custom controllers y admission webhooks. Si puedes dibujar el control plane en una servilleta y explicar qué guarda etcd, vas por delante.

Pipelines de CI/CD

GitHub Actions, GitLab CI y Jenkins son los tres más comunes. Espere preguntas sobre estrategias de caching, ejecución de tests en paralelo, gestión de secrets dentro de los pipelines y cómo fallar rápido en un build de 20 minutos. Un escenario favorito: «el job de deploy tiene éxito pero los nuevos pods entran en crashloop — explícame el debugging». Las respuestas fuertes encadenan logs, exit codes, image SHAs y estrategia de rollback sin saltarse pasos.

Observabilidad

Prometheus + Grafana + Loki + un sistema de tracing (Tempo, Jaeger) es el stack open-source canónico. Datadog y New Relic dominan la oferta de pago. Esté listo para definir SLOs, error budgets y cómo debería ser una alerta (síntoma, no causa). Espere: «tu dashboard está en verde pero los clientes se quejan — ¿qué falla?». Las respuestas que mencionan sesgo de muestreo, ventanas de agregación y monitorización synthetic vs real-user puntúan bien.

Profundidad específica de cloud

Elija AWS, GCP o Azure según la oferta. Las preguntas de AWS se agrupan en torno a IAM (la causa más común de «por qué esto no funciona»), routing de VPC, rarezas de EKS y consistencia de S3. Los loops de GCP favorecen IAM y jerarquía de proyectos, GKE y la forma del coste de BigQuery. Azure se centra en AAD, AKS y Azure DevOps Pipelines. Una nube en profundidad es mejor que tres nubes en superficie.

Preguntas de escenario habituales

• «El apply de Terraform acaba de hacer timeout tras 40 minutos. ¿Qué es lo primero que compruebas?» (La respuesta debería mencionar el state lock, los rate limits del provider y los grafos de dependencias.)
• «Los pods de producción reciben OOMKilled cada lunes a las 9 de la mañana. Explícame tu investigación.» (Esperado: patrones de tráfico, memory limits, comportamiento del GC, deploys recientes, correlación con el lag del autoscaling.)
• «Heredas un pipeline de deploy que tarda 45 minutos. ¿Qué cambias primero?» (Capas de caching, sharding de tests en paralelo, jobs condicionales y luego cambios arquitectónicos mayores.)
• «Un equipo quiere gestionar su propio cluster de EKS. Explícame si es buena idea.» (Coste, blast radius, expertise, tradeoff de servicios compartidos vs aislamiento.)
• «La mitad de las alertas en PagerDuty son ruido. ¿Cómo lo arreglas sin perder incidentes reales?» (Alerting basado en síntomas, umbrales guiados por SLO, calidad de los runbooks, correlación de alertas.)

Áreas de enfoque behavioral — qué buscan los hiring managers

Los hiring managers de DevOps buscan tres señales más allá de la profundidad técnica. Primero, ownership del fallo — ¿sabes contar la historia de un incidente sin culpar al equipo de desarrollo, al anterior lead de DevOps o al proveedor cloud? Las historias fuertes siguen timeline → suposición equivocada → descubrimiento → fix → prevención, y asumen el momento de «debería haberlo cazado en el code review» sin pestañear. Segundo, comunicación entre capas organizativas — DevOps se sitúa entre los desarrolladores y la dirección, así que espera prompts sobre explicar el coste de la infraestructura a un CFO o sobre frenar una fecha límite ajustada. Tercero, pragmatismo vs pureza — los entrevistadores quieren a alguien capaz de entregar un fix tosco-pero-monitorizado a las 2 de la madrugada, no a alguien que insiste en la arquitectura perfecta antes de desbloquear al equipo.

Cómo usar la práctica de mock con IA para este rol

Ponga el tipo de entrevista en «Tech Screening» y pegue la oferta real si la tiene. La IA extrae el stack de herramientas (Terraform vs Pulumi, AWS vs GCP) y pondera las preguntas en consecuencia. Sin oferta, use por defecto «AWS + Terraform + Kubernetes, seniority media, 10 preguntas» — ese perfil cubre alrededor del 60 % de las ofertas de DevOps.

Para practicar respuesta a incidentes, cambie al modo «Scenario» y pida a la IA que conduzca una caída que se va desarrollando. La sesión sigue durante 15–20 minutos mientras haces el triage. La puntuación premia cómo acotas el espacio de búsqueda, no si llegas a la causa raíz «correcta» — porque los incidentes reales rara vez tienen una sola.

Un drill infrautilizado: «quiero cinco preguntas seguidas de refactorización de Terraform». La IA generará escenarios donde divides un root module, migras state o eliminas drift. Cinco repeticiones en una sesión y el vocabulario deja de sonar extraño.

Preguntas frecuentes