Preguntas de entrevista para DevOps Engineer — Más de 30 preguntas y marcos de respuesta de expertos

El Bureau of Labor Statistics proyecta un crecimiento del 15 % en los puestos de desarrolladores de software (que cada vez más incluyen DevOps) hasta 2034, mientras que los puestos tradicionales de administradores de sistemas disminuyen un 4 % a medida que las organizaciones trasladan la gestión de infraestructura hacia enfoques basados en código y automatizados [1] [2].

Puntos clave

• Las entrevistas de DevOps evalúan una combinación única de habilidades de desarrollo de software y conocimiento de operaciones de infraestructura — tanto los desarrolladores puros como los administradores de sistemas puros presentan lagunas.
• Espera preguntas basadas en escenarios sobre respuesta a incidentes, diseño de pipelines e infrastructure-as-code — los entrevistadores quieren ver cómo piensas bajo presión operativa.
• Orquestación de contenedores (Kubernetes), diseño de pipelines CI/CD y estrategia de observabilidad son los tres dominios técnicos más comúnmente evaluados.
• Las preguntas conductuales se centran fuertemente en post-mortems sin culpa, colaboración entre equipos y cómo manejas incidentes de guardia.
• Demostrar una mentalidad de seguridad primero (DevSecOps) diferencia a los candidatos fuertes de aquellos que tratan la seguridad como algo secundario.

Preguntas conductuales

Las entrevistas conductuales de DevOps evalúan la compostura ante respuesta a incidentes, la colaboración interfuncional y la capacidad de equilibrar fiabilidad con velocidad de desarrollo [3]. El método STAR es esencial aquí — los entrevistadores necesitan respuestas estructuradas que puedan puntuar según rúbricas.

1. Cuéntame sobre un incidente en producción que gestionaste. Guíame desde la alerta hasta la resolución.

Esta es la pregunta conductual definitoria de DevOps. Describe la alerta que se activó (PagerDuty, Datadog, monitoreo personalizado), tus pasos iniciales de triage, cómo comunicaste con las partes interesadas durante el incidente, la causa raíz que identificaste, la solución que desplegaste y las acciones del post-mortem que previnieron la recurrencia. Cuantifica: "Reduje el MTTR de 3 horas a 22 minutos implementando procedimientos automatizados de rollback después de este incidente."

2. Describe una vez que un cambio de infraestructura que realizaste causó una interrupción inesperada.

Los entrevistadores quieren ver responsabilidad y aprendizaje, no perfección. Recorre qué cambiaste, por qué el fallo no se detectó en las pruebas, cómo detectaste y mitigaste el impacto, y qué salvaguardas implementaste después (despliegues canary, feature flags, mejores entornos de staging). Echar la culpa a otros es una señal de alerta inmediata.

3. Cuéntame sobre una situación en la que los equipos de desarrollo y operaciones tenían prioridades en conflicto. ¿Cómo cerraste la brecha?

DevOps existe en la intersección entre entregar rápido y funcionar de forma fiable. Describe el conflicto específico (los desarrolladores querían desplegar diariamente, operaciones quería ventanas de cambio mensuales), cómo facilitaste la conversación, el compromiso que negociaste (quizás puertas de pruebas automatizadas que permitieron despliegues más rápidos y seguros) y el resultado medible.

4. Describe una vez que automatizaste un proceso manual que ahorró tiempo significativo de ingeniería.

La automatización es la propuesta de valor central de DevOps. Detalla el proceso manual (despliegue, aprovisionamiento de entornos, rotación de certificados), la herramienta de automatización que elegiste y por qué (Terraform, Ansible, scripts personalizados), los desafíos de implementación y el ahorro de tiempo. Las respuestas fuertes incluyen: "Automaticé los despliegues de migración de base de datos, reduciendo un proceso manual de 4 horas a una ejecución de pipeline de 12 minutos con rollback integrado."

5. Cuéntame sobre una vez que tuviste que tomar una decisión difícil durante un turno de guardia con información limitada.

La toma de decisiones bajo incertidumbre durante la guardia es una competencia central de DevOps. Describe la situación, la información que tenías y la que faltaba, la decisión que tomaste y tu razonamiento, y el resultado. Discute cómo equilibraste la velocidad de respuesta con el riesgo de empeorar las cosas.

6. Describe cómo has mejorado la observabilidad en un sistema en el que trabajaste.

Recorre tu enfoque: qué métricas, logs y trazas implementaste, qué herramientas utilizaste (Prometheus, Grafana, ELK stack, Datadog), cómo diseñaste las alertas para minimizar el ruido mientras detectabas problemas reales, y cómo la observabilidad mejorada cambió la capacidad del equipo para diagnosticar problemas.

Preguntas técnicas

Las entrevistas técnicas de DevOps evalúan tu profundidad en infraestructura, automatización, containerización y reliability engineering. El salario medio para desarrolladores de software (la categoría del BLS que incluye DevOps) es de 133.080 $ [1], reflejando la amplitud de conocimiento técnico requerido.

1. Diseña una pipeline CI/CD para una aplicación de microservicios. ¿Qué etapas incluirías y por qué?

Recorre cada etapa: trigger de control de versiones (webhook de Git), linting y análisis estático, tests unitarios, construcción de imagen de contenedor, tests de integración contra entornos efímeros, escaneo de seguridad (SAST, escaneo de vulnerabilidades de contenedores), promoción de artefactos a staging, tests de humo automatizados, despliegue canary a producción y criterios automatizados de rollback. Discute estrategias de ramas (trunk-based vs. GitFlow) y cómo afectan al diseño de la pipeline [3].

2. Explica cómo Kubernetes maneja la programación de pods, el escalado y la auto-reparación.

Describe el papel del scheduler (evaluación de recursos de nodos, reglas de afinidad/anti-afinidad, taints y tolerations), el Horizontal Pod Autoscaler (HPA) y sus fuentes de métricas (CPU, memoria, métricas personalizadas), y mecanismos de auto-reparación (liveness probes reiniciando contenedores no saludables, readiness probes eliminando pods del servicio, controladores ReplicaSet manteniendo el conteo deseado de pods). Discute resource requests vs. limits y por qué configurarlos correctamente previene problemas de vecino ruidoso.

3. ¿Cómo implementarías infrastructure-as-code para un entorno cloud? Compara dos herramientas que hayas usado.

Compara Terraform y CloudFormation (o Pulumi, CDK). Discute gestión de estado, detección de drift, reutilización de módulos, soporte multi-cloud y flujo de trabajo del equipo (ciclo plan/apply, revisiones de pull request para cambios de infraestructura). Explica por qué los cambios de infraestructura versionados y revisados por pares reducen el drift de configuración y el riesgo de auditoría [4].

4. Guíame por tu enfoque de estrategia de monitoreo y alertas. ¿Cómo evitas la fatiga de alertas?

Discute el método USE (Utilización, Saturación, Errores) para infraestructura y el método RED (Tasa, Errores, Duración) para servicios. Explica el enrutamiento de alertas (crítico vs. advertencia vs. informativo), políticas de escalación, alertas basadas en SLO (alertar sobre la tasa de consumo del presupuesto de errores en lugar de métricas individuales) e integración con runbooks. Menciona herramientas concretas: Prometheus + Alertmanager, PagerDuty, Grafana.

5. Un servicio experimenta picos intermitentes de latencia. ¿Cómo diagnosticarías esto usando tracing distribuido?

Describe el despliegue de instrumentación de trazas (OpenTelemetry), la correlación de trace spans con histogramas de latencia, la identificación de qué servicio en la cadena de llamadas introduce el retraso, la verificación de contención de recursos (pools de conexiones de base de datos, pools de hilos) y si los picos correlacionan con pausas de recolección de basura, trabajos por lotes o patrones de tráfico. Discute la diferencia entre latencia P50, P95 y P99.

6. ¿Cómo gestionas secretos en una pipeline CI/CD y un entorno de producción?

Discute HashiCorp Vault (o AWS Secrets Manager, Azure Key Vault), secretos dinámicos con rotación automática, inyección de secretos en tiempo de ejecución (no incrustados en imágenes), RBAC para acceso a secretos, registro de auditoría y cómo manejar secretos en entornos de desarrollo (vault local, archivos .env excluidos del control de versiones). Explica por qué las variables de entorno solas son insuficientes para la gestión de secretos en producción.

7. Explica los despliegues blue-green, los despliegues canary y las actualizaciones rolling. ¿Cuándo elegirías cada uno?

Blue-green: cambio instantáneo con rollback completo, pero requiere 2x de infraestructura. Canary: cambio gradual de tráfico (1 %, 5 %, 25 %, 100 %) con promoción o rollback automatizado basado en métricas — mejor para cambios de producción aversos al riesgo. Rolling updates: reemplazo de pods in-place en Kubernetes — más simple pero más difícil de revertir rápidamente. Discute cuándo es apropiada cada estrategia según la tolerancia al riesgo, el costo de infraestructura y la frecuencia de despliegue.

Preguntas situacionales

Las preguntas situacionales evalúan tu juicio operativo y toma de decisiones en escenarios realistas de DevOps.

1. El clúster Kubernetes de tu equipo está al 85 % de capacidad de CPU durante las horas pico, y un lanzamiento importante de producto es en dos semanas. ¿Qué haces?

Discute acciones inmediatas (dimensionamiento correcto de pods sobreaprovisionados, identificación y corrección de fugas de recursos), soluciones a medio plazo (autoescalado horizontal del clúster, pools de nodos con tipos de instancia apropiados) y planificación de contingencia (pre-escalado antes del lanzamiento, establecimiento de circuit breakers, preparación de procedimientos de rollback). Aborda las implicaciones de costo del sobreaprovisionamiento vs. el riesgo del subaprovisionamiento durante un lanzamiento.

2. Un desarrollador accidentalmente sube credenciales de AWS a un repositorio público de GitHub. ¿Cuál es tu respuesta al incidente?

Inmediato: rotar las credenciales comprometidas en minutos, no horas. Investigar: revisar los logs de CloudTrail para cualquier acceso no autorizado durante la ventana de exposición. Remediar: implementar hooks de pre-commit (git-secrets, detect-secrets) para prevenir futuras fugas, migrar a credenciales de corta duración vía roles IAM y revisar las prácticas de gestión de secretos del equipo. Comunicar: notificar al equipo de seguridad, documentar el incidente, realizar un post-mortem sin culpa.

3. Tu pipeline CI/CD tarda 45 minutos en completarse. El equipo de ingeniería está frustrado con los ciclos de retroalimentación lentos. ¿Cómo lo mejoras?

Perfila la pipeline para identificar cuellos de botella: suites de tests lentas (paralelizar, identificar tests inestables), construcciones de imagen Docker grandes (builds multi-stage, caching de capas), etapas secuenciales que podrían ejecutarse en paralelo, reconstrucciones completas innecesarias (builds incrementales, selección de tests basada en cambios). Establece un objetivo (menos de 15 minutos) y mide el impacto de cada optimización. Considera separar el feedback rápido (lint, tests unitarios) de la validación completa (integración, escaneos de seguridad).

4. Un microservicio que no es de tu equipo está causando fallos en cascada en toda la plataforma. ¿Qué haces?

Implementa patrones de circuit breaker (Hystrix, Resilience4j) para aislar el servicio fallido, configura políticas de timeout y reintentos para prevenir el agotamiento de pools de hilos, comunica con el equipo propietario y establece patrones bulkhead para prevenir la propagación en cascada. Discute capacidades de service mesh (Istio, Linkerd) para gestión centralizada de tráfico y observabilidad.

5. La dirección quiere migrar de infraestructura on-premise a AWS. ¿Cómo abordas la planificación de la migración?

Evalúa el inventario de infraestructura actual, categoriza las cargas de trabajo (lift-and-shift vs. re-arquitectura vs. retirar), identifica dependencias y orden de migración, planifica la operación híbrida durante la transición, establece la seguridad de la zona de aterrizaje (diseño de VPC, estructura IAM, logging), ejecuta entornos paralelos durante la validación y define criterios de éxito para cada fase de migración. Enfatiza que las migraciones son cambios organizacionales, no solo técnicos.

Preguntas para hacerle al entrevistador

Las preguntas de entrevista de DevOps revelan tu madurez operativa y en qué tipo de cultura de ingeniería prosperas.

1. "¿Cómo es su rotación de guardia? ¿Cuál es el número promedio de alertas por semana?" — La carga de guardia es el factor de calidad de vida más importante en los puestos de DevOps. Un alto volumen de alertas señala problemas de fiabilidad o mala higiene de alertas.

2. "¿Cuál es su frecuencia de despliegue y cuál es la tasa de fallos de cambios?" — Estas son dos de las cuatro métricas DORA [5]. Los equipos que despliegan diariamente con baja tasa de fallos tienen prácticas DevOps maduras.

3. "¿Cómo manejan los post-mortems? ¿Son sin culpa?" — La cultura de post-mortem sin culpa es la base de las operaciones fiables. Las organizaciones que castigan los fallos crean entornos donde los ingenieros ocultan los problemas.

4. "¿Qué porcentaje de su infraestructura se gestiona como código?" — Esto revela la madurez de la infraestructura. Si la respuesta es "estamos trabajando en ello", espera trabajo significativo de migración.

5. "¿Cuál es el mayor desafío de fiabilidad que enfrenta el equipo actualmente?" — Esto te da una vista previa realista de los problemas en los que trabajarías desde el primer día.

6. "¿Cómo equilibra el equipo el trabajo de infraestructura para nuevas funcionalidades con la fiabilidad y la deuda técnica?" — Los equipos que solo construyen cosas nuevas acumulan deuda operativa; los equipos que solo mantienen se estancan.

7. "¿Cómo es el camino hacia Staff o Principal DevOps Engineer aquí?" — El crecimiento profesional en DevOps debe incluir tanto la profundidad técnica como las vías de impacto organizacional.

Formato de entrevista y qué esperar

Las entrevistas de DevOps normalmente abarcan de tres a cinco rondas. La preselección del reclutador (20-30 minutos) cubre antecedentes, salario y expectativas del puesto. La preselección técnica (45-60 minutos) generalmente implica resolución de problemas de infraestructura, scripting (Bash/Python) o preguntas de diseño de sistemas.

El circuito presencial (o equivalente virtual) típicamente incluye tres a cuatro sesiones: una ronda de diseño de sistemas (diseñar una pipeline de despliegue, diseñar una arquitectura de monitoreo), una inmersión técnica profunda (Kubernetes, Terraform, servicios cloud — dependiendo del stack del equipo), una ronda de scripting o codificación (automatización de tareas de infraestructura, escritura de scripts de despliegue) y una ronda conductual centrada en respuesta a incidentes y colaboración [3].

Algunas empresas incluyen un ejercicio práctico donde configuras un pequeño entorno, depuras un despliegue roto o revisas código de infraestructura. Todo el proceso desde el primer contacto hasta la oferta normalmente toma de dos a cuatro semanas — a menudo más rápido que los ciclos de contratación de ingeniería de software porque los puestos de DevOps son más difíciles de cubrir.

Cómo prepararse

La preparación para entrevistas de DevOps debe abarcar conocimiento de infraestructura, habilidad de codificación y pensamiento operativo.

Para conocimiento de infraestructura, revisa los fundamentos de redes (TCP/IP, DNS, balanceo de carga, CDN), administración de sistemas Linux (gestión de procesos, sistema de archivos, permisos, systemd), servicios cloud (compute, almacenamiento, redes, IAM para al menos un proveedor cloud importante) y containerización (internos de Docker, arquitectura de Kubernetes). La práctica práctica importa más que la lectura — construye un proyecto pequeño en tu plataforma cloud preferida usando infrastructure-as-code [4].

Para codificación, practica scripting en Bash y automatización en Python. Debes sentirte cómodo parseando archivos de log, haciendo llamadas a APIs, manipulando configuración YAML/JSON y escribiendo scripts idempotentes. Las preguntas de codificación de DevOps son menos sobre complejidad algorítmica y más sobre automatización práctica.

Para diseño de sistemas, practica diseñar pipelines CI/CD, arquitecturas de monitoreo y estrategias de despliegue en una pizarra (o equivalente virtual). Estudia las métricas DORA (frecuencia de despliegue, lead time, tasa de fallos de cambios, MTTR) y prepárate para discutir cómo las medirías y mejorarías [5]. Lee blogs de ingeniería de empresas conocidas por su excelencia operativa: Netflix, Google (libro SRE) y Etsy.

Para la preparación conductual, construye historias STAR alrededor de respuesta a incidentes, logros de automatización, colaboración entre equipos y situaciones donde mejoraste la fiabilidad. Las preguntas conductuales de DevOps se centran de forma única en cómo te desempeñas bajo presión operativa.

Errores comunes en entrevistas

1. Centrarse en herramientas en lugar de principios. Nombrar cada herramienta en el paisaje CNCF no demuestra competencia. Explica por qué elegirías una herramienta para un problema específico, no solo qué hace.

2. Describir la lucha contra incendios manual como una fortaleza. Ser el héroe que arregla producción a las 3 de la mañana no es DevOps — construir sistemas que no se rompan a las 3 de la mañana sí lo es. Enfatiza la prevención sobre la reacción.

3. Ignorar la seguridad en el diseño de pipelines. Si tu diseño de pipeline CI/CD no incluye SAST, escaneo de dependencias o gestión de secretos, has pasado por alto una dimensión crítica. DevSecOps es la expectativa, no un extra.

4. No cuantificar el impacto de la automatización. "Automaticé despliegues" es débil. "Reduje el tiempo de despliegue de 4 horas a 12 minutos y eliminé 3 categorías de errores manuales" demuestra impacto real.

5. Tratar infrastructure-as-code como opcional. Si describes la configuración manual de servidores a través de una consola cloud, los entrevistadores cuestionarán tus fundamentos de DevOps. Todo debe estar definido como código, versionado y revisado por pares.

6. Carecer de opiniones sobre observabilidad. Los ingenieros DevOps necesitan perspectivas sólidas sobre logging, métricas, tracing y alertas. "Usamos Datadog" es insuficiente — explica tu filosofía de alertas, estrategia de SLO y cómo redujiste el tiempo medio de detección.

7. Descuidar el lado humano de la respuesta a incidentes. El diagnóstico técnico es solo la mitad de la gestión de incidentes. La comunicación durante interrupciones, las actualizaciones a las partes interesadas y la facilitación de post-mortems sin culpa son igualmente importantes.

Puntos clave

Las entrevistas de DevOps evalúan una combinación poco común: habilidad de desarrollo de software, experiencia en infraestructura, juicio operativo y comunicación colaborativa. El campo se sitúa en la intersección de desarrollo y operaciones, y los entrevistadores evalúan específicamente si puedes tender puentes entre ambos mundos. Prepárate construyendo infraestructura real (no solo leyendo sobre ella), practicando escenarios de respuesta a incidentes y desarrollando historias STAR que demuestren tanto profundidad técnica como liderazgo entre equipos. Con un crecimiento del 15 % en los puestos de desarrolladores de software hasta 2034 [1] y compensaciones premium para especialistas en DevOps, una preparación exhaustiva para este proceso de entrevista multifacético es una inversión que define tu carrera.

Crea tu currículum de DevOps Engineer optimizado para ATS con Resume Geni — es gratis para empezar.

Preguntas frecuentes

¿Qué certificaciones ayudan para entrevistas de DevOps? AWS Solutions Architect, Certified Kubernetes Administrator (CKA) y HashiCorp Terraform Associate son las más reconocidas. Las certificaciones demuestran conocimiento fundamental pero no reemplazan la experiencia práctica — los entrevistadores profundizarán más allá de lo que cualquier certificación cubre.

¿Las entrevistas de DevOps incluyen preguntas de codificación? Sí, pero se centran en automatización práctica (Bash, Python) en lugar de desafíos algorítmicos. Espera escribir scripts que parseen logs, interactúen con APIs, gestionen archivos de configuración o automaticen tareas de infraestructura [3].

¿Cuán importante es el conocimiento específico de cloud? Muy importante, pero transferible. La mayoría de los equipos usan AWS, GCP o Azure. Conocimiento profundo de una plataforma cloud más comprensión conceptual de las demás es la base esperada. Concentra tu preparación en la plataforma cloud indicada en la descripción del puesto.

¿Debo prepararme para diseño de sistemas como un ingeniero de software? El diseño de sistemas de DevOps difiere del diseño de sistemas de ingeniería de software. Diseñarás arquitecturas de infraestructura (pipelines de despliegue, sistemas de monitoreo, planes de recuperación ante desastres) en lugar de arquitecturas de aplicación. Concéntrate en fiabilidad, escalabilidad y preocupaciones operativas.

¿Qué métricas DORA debo conocer? Las cuatro métricas DORA clave son frecuencia de despliegue, lead time for changes, tasa de fallos de cambios y tiempo medio de recuperación (MTTR) [5]. Comprender estas métricas y cómo mejorarlas demuestra madurez en DevOps.

¿Cómo demuestro experiencia en DevOps si vengo de un background puramente de desarrollo u operaciones? Destaca cualquier trabajo interfuncional: escribir scripts de despliegue, configurar monitoreo, contribuir a revisiones de código de infraestructura o participar en respuesta a incidentes. Los proyectos personales que usen CI/CD, contenedores y servicios cloud también demuestran conocimiento práctico.

¿Es SRE (Site Reliability Engineering) lo mismo que DevOps? SRE es la implementación de Google de los principios DevOps, con mayor énfasis en presupuestos de errores, SLOs y tratar las operaciones como un problema de software. Muchas empresas usan los términos indistintamente, pero los puestos de SRE tienden a enfocarse más en la medición de fiabilidad y automatización a escala.

Citas

[1] U.S. Bureau of Labor Statistics, "Software Developers, Quality Assurance Analysts, and Testers," Occupational Outlook Handbook, 2024. [2] U.S. Bureau of Labor Statistics, "Network and Computer Systems Administrators," Occupational Outlook Handbook, 2024. [3] Tech Interview Handbook, "Software Engineering Interview Guide," 2025. [4] HashiCorp, "Infrastructure as Code in Practice," 2025. [5] DORA Team, "Accelerate State of DevOps Report," Google Cloud, 2024.