Preguntas de entrevista para DevOps Engineer: respuestas que funcionan

La primera entrevista técnica para un puesto de DevOps Engineer puede sentirse como un examen sorpresa. Te preguntas si repasarán redes, Docker, Terraform o si te pondrán a diseñar un sistema de cero en una pizarra. Esa incertidumbre es el mayor enemigo. La buena noticia es que la mayoría de las empresas siguen un guion bastante predecible. Sabiendo qué esperar y cómo estructurar tus respuestas, puedes dejar de adivinar y empezar a demostrar tu valía con confianza.

El filtro inicial: lo básico que no puedes fallar#

Las primeras preguntas no buscan creatividad. Buscan confirmar que tienes los cimientos. Un fallo aquí te descarta rápido. Son preguntas cortas, directas, que verifican si entiendes los conceptos que usarás a diario.

• ¿Qué es IaC y qué problema resuelve?: Aquí evalúan si entiendes el cambio de mentalidad. No basta con decir "scripting". La respuesta clave es consistencia y repetibilidad.
• Explica la diferencia entre un contenedor y una máquina virtual.: Quieren ver si conoces el aislamiento a nivel de sistema operativo vs. a nivel de kernel, y las implicaciones de rendimiento y tamaño.
• ¿Qué es CI/CD? Diferencia Continuous Delivery de Continuous Deployment.: Una pregunta clásica. La diferencia está en la intervención humana para el paso a producción. Es un matiz que muchos pasan por alto.
• ¿Qué es la orquestación de contenedores?: No solo es "usar Kubernetes". Es sobre gestionar el ciclo de vida, el escalado y el networking de muchos contenedores como si fueran una sola aplicación.

Preguntas técnicas: donde se pone serio#

Aquí el entrevistador quiere ver cómo piensas y resuelves problemas. No buscan una definición de manual, sino tu proceso. A menudo, la forma en que llegas a la respuesta es más importante que la respuesta misma.

El clásico: cuéntame un problema que resolviste

Esta es una de las preguntas más reveladoras. Te permite demostrar experiencia real.

Qué evalúa el entrevistador: Tu capacidad para diagnosticar, comunicar y aplicar una solución técnica. No quiere oír "arreglé el servidor". Quiere el contexto, el impacto y el resultado.

Respuesta modelo (usa el método STAR):

• Situación: "En mi puesto anterior, el tiempo de despliegue a producción pasó de 10 minutos a casi 45. Los desarrolladores estaban frustrados y el negocio perdía agilidad."
• Tarea: "Mi objetivo fue reducir ese tiempo a menos de 15 minutos sin sacrificar la estabilidad."
• Acción: "Analicé el pipeline y descubrí dos cuellos de botella: una etapa de pruebas de integración que se ejecutaba de forma secuencial y un proceso de construcción de la imagen Docker que descargaba dependencias cada vez. Paralelicé las pruebas y añadí un sistema de caché para las dependencias en el registro de imágenes."
• Resultado: "El tiempo de despliegue bajó a 8 minutos. La tasa de fallos en producción no aumentó. El equipo de desarrollo pudo iterar mucho más rápido."

Preguntas sobre herramientas y conceptos avanzados

Estas preguntas van más allá de la definición. Quieren saber cómo las aplicarías.

• ¿Cómo manejarías secretos (contraseñas, API keys) en un pipeline de CI/CD?: Una mala respuesta es "los pongo en una variable de entorno en el script". Una buena respuesta habla de soluciones como HashiCorp Vault, AWS Secrets Manager o soluciones nativas de la plataforma CI (como GitHub Actions secrets), y de por qué es importante no hardcodearlos.
• Explica el concepto de "blue-green deployment". ¿Cuál es su principal ventaja y desventaja?: Evalúan si entiendes las estrategias de despliegue con cero downtime. La ventaja es el rollback instantáneo. La desventaja es el coste, ya que necesitas duplicar la infraestructura, al menos temporalmente.
• Imagina que una aplicación en producción tiene una fuga de memoria que hace que el contenedor se reinicie cada hora. ¿Cómo lo investigarías?: Aquí buscan tu proceso de debugging. Una buena respuesta incluiría: revisar los logs del contenedor y de la aplicación, usar herramientas de monitoreo para ver la tendencia del uso de memoria, y si es posible, entrar en un contenedor en ejecución para analizar los procesos (docker stats, kubectl top pods, profilers específicos del lenguaje).

Preguntas de comportamiento: el ajuste cultural#

No todo es código. Necesitan saber si puedes trabajar en equipo, comunicar problemas y manejar la presión. Estas preguntas suelen empezar con "Cuéntame una vez que..." o "¿Cómo manejarías...?".

• Un desarrollador te dice que su código funciona en su máquina pero falla en producción. ¿Qué haces?: Aquí buscan colaboración, no culpas. Una buena respuesta empieza por pedir más detalles, revisar los logs juntos y buscar diferencias de entorno. La frase "vamos a verlo juntos" vale oro.
• Necesitas implementar un cambio que afectará a todos los equipos de desarrollo. ¿Cómo comunicas el cambio y gestionas la transición?: Evalúan tus habilidades de comunicación y empatía. La respuesta debería incluir: documentar el cambio, crear un entorno de prueba, organizar una demostración o taller, y ofrecer un período de soporte.
• ¿Qué haces cuando no sabes cómo resolver un problema técnico?: Esta es una prueba de humildad y proactividad. Una respuesta honesta es mejor que un invento. Hablar de consultar la documentación oficial, buscar en foros de confianza, preguntar a un compañero con más experiencia o descomponer el problema en partes más pequeñas son señales de un buen ingeniero.

Los errores que te pueden costar la oferta#

Muchos candidatos se descartan solos. Evita estos fallos comunes.

• Respuestas genéricas: Decir "me gusta la automatización" no dice nada. Siempre apoya tus afirmaciones con un ejemplo concreto de tu experiencia.
• No preguntar nada: Una entrevista es una calle de dos sentidos. No preguntar sobre el equipo, los retos o la tecnología muestra falta de interés. Prepara al menos tres preguntas inteligentes.
• Mentir sobre una tecnología: Si no has usado algo, dilo, pero muestra tu capacidad de aprendizaje. "No he trabajado con Terraform, pero he usado Ansible para IaC y entiendo los principios de estado y proveedores. He empezado un tutorial para familiarizarme con su sintaxis".
• Ignorar el lado humano: Hablar solo de tecnología sin mostrar cómo colaboras o comunicas es una bandera roja. DevOps es cultura, no solo herramientas.

Checklist de preparación final#

Antes de tu entrevista, asegúrate de tener esto cubierto.

• Revisa la descripción del puesto al revés y al derecho. ¿Qué herramientas y conceptos mencionan? Investiga los que no conozcas.
• Prepara 3-4 historias usando el método STAR (Situación, Tarea, Acción, Resultado) sobre tus éxitos y fracasos.
• Practica en voz alta. Explicar un concepto técnico complejo de forma simple es una habilidad que se entrena.
• Investiga la empresa. ¿Usan AWS, GCP o Azure? ¿Qué productos tienen? ¿Algún artículo de su blog de ingeniería que puedas leer?
• Prepara tus preguntas para el entrevistador sobre el día a día del equipo, los mayores desafíos técnicos actuales y la cultura de aprendizaje.

Para asegurarte de que tu perfil encaja con lo que buscan, puedes usar un decodificador de ofertas de empleo gratuito para analizar la descripción del puesto. Y si quieres ver cómo se vería tu currículum para un sistema automatizado, prueba nuestro verificador de compatibilidad con ATS.

Herramientas gratis#

• jobrise.io/es/free-ats-checker/
• jobrise.io/es/free-jd-decoder/
• jobrise.io/es/jobs/
• jobrise.io/es/blog/

Preguntas frecuentes#

¿Cuánto tiempo debo dedicar a preparar una entrevista de DevOps?

Depende de tu experiencia, pero un mínimo de 5 a 8 horas repartidas en varios días es realista. Dedica tiempo a repasar conceptos, preparar tus historias STAR y a investigar a fondo la empresa. La preparación reduce los nervios y mejora el rendimiento.

¿Es mejor especializarse en un proveedor de nube (AWS, Azure, GCP) o ser generalista?

Para roles de DevOps, tener una base sólida en uno de los principales proveedores es casi obligatorio. AWS sigue siendo el más demandado. Sin embargo, entender los principios fundamentales de la nube (IaaS, PaaS, redes, seguridad) te permite adaptarte a otros. La especialización abre puertas, pero la mentalidad generalista te hace más resiliente a los cambios del mercado.

¿Qué certificaciones de DevOps valen la pena para las entrevistas?

Las certificaciones de AWS (Solutions Architect, DevOps Engineer), Azure (Azure DevOps Engineer Expert) o GCP (Professional Cloud DevOps Engineer) son las más reconocidas. No sustituyen a la experiencia real, pero pueden darte una ventaja, especialmente si estás cambiando de área o tienes poca experiencia demostrable en la nube.

¿Cómo respondo si me preguntan sobre una tecnología que no conozco?

Sé honesto. No finjas. Di algo como: "No tengo experiencia directa con [tecnología X], pero entiendo que se usa para [propósito]. En mi último proyecto usé [tecnología Y] para un fin similar, y estoy seguro de que podría aprenderla rápidamente". Esto muestra autenticidad y capacidad de aprendizaje.

¿Debo mencionar proyectos personales o contribuciones a open source en la entrevista?

Sí, siempre que sean relevantes. Un pequeño proyecto donde automatizaste el despliegue de tu blog con GitHub Actions o un script en Python que te ahorra tiempo es muy valioso. Muestra iniciativa, pasión y habilidades prácticas. Lleva el enlace a tu repositorio listo para compartir si surge la oportunidad. Puedes encontrar más ideas y ofertas de trabajo que valoren estas habilidades en nuestro portal de empleo.