Qué preguntan en una entrevista DevOps, cómo responder sobre CI/CD, Kubernetes e incidentes y cómo ensayar la conversación.
Una entrevista DevOps se parece muy poco a un examen de herramientas. Cualquiera que haya leído ofertas de empleo conoce la lista de tecnologías. Lo que se evalúa es otra cosa: cómo construyes el proceso, qué haces cuando todo se ha roto y si sabes elegir una herramienta para la tarea, no por su popularidad.
| Etapa | Qué se evalúa |
|---|---|
| Cribado | experiencia, stack, expectativas económicas |
| Infraestructura | Linux, redes, contenedores, orquestación |
| Práctica | análisis de incidentes, diagnóstico por logs |
| Procesos | CI/CD, lanzamientos, seguridad, trabajo en equipo |
La respuesta «GitLab CI» no es una respuesta. Se espera el recorrido: commit → compilación → pruebas → artefacto → despliegue en el entorno, con reversión y con lo que ocurre si falla en cada paso. Una buena respuesta incluye el tiempo de compilación y la experiencia previa de mejora.
Capas de la imagen y su caché, compilación multi-stage, por qué una imagen de 1 GB es un problema, cómo pasar secretos, la diferencia entre CMD y ENTRYPOINT. A menudo piden explicar por qué el contenedor de la aplicación falla al iniciar.
Pod frente a Deployment, sondas readiness y liveness, reinicios y sus causas, límites de recursos y OOMKill, ConfigMap y Secret, Ingress. Pregunta práctica: «el pod no arranca — por dónde empezaría».
Terraform frente a Ansible, state y bloqueos, plan antes de aplicar, idempotencia. Comprueban si entiende qué hará `apply` antes de ejecutarlo.
Qué ocurre desde el navegador hasta la aplicación: DNS, balanceador de carga, TLS, proxy. Niveles de LAN, problemas con MTU, diferencia entre L4 y L7. Aquí se descarta a quienes «lo hacían todo mediante pipelines listos».
Métricas frente a logs frente a trazas, qué son SLO y budget, por qué «hay monitorización, pero los incidentes no se ven». Caso práctico: los usuarios se quejan y las métricas están dentro de lo normal — qué compruebas.
Orden de actuación cuando cae producción, quién toma decisiones, cómo comunicar, cómo escribir un postmortem sin buscar culpables. Esta es una pregunta favorita de los entrevistadores: muestra experiencia real.
La estructura funciona: síntoma → hipótesis → qué verifico → solución → prevención.
«Los usuarios reportan un 502. Primero reviso el balanceador: si los upstreams están vivos. Si están vivos, reviso los logs de la aplicación y las métricas de latencia. En el proyecto anterior, la causa era el agotamiento del pool de conexiones a la BD: ayudó aumentar el pool y añadir un timeout. La prevención es una alerta sobre la utilización del pool, no sobre los 5xx».
— ejemplo de respuesta de la práctica de análisis de entrevistas
Una semana de 30–40 minutos: repasar siete temas, recordar dos o tres incidentes reales con cifras y pasar una vez un diálogo completo. El caso del incidente es más importante que la teoría: es donde más se suele descartar.
Si aparece en la vacante, sí, al menos a nivel de probes, límites y análisis de un pod que falla. Si la infraestructura está en máquinas virtuales, preguntan sobre systemd, balanceo y despliegue sin orquestador.
Sí: Python, Go o Bash a nivel de scripts de automatización. El live coding completo es menos frecuente, pero pueden pedirte analizar un script ajeno y encontrar el error.
Dilo directamente y muestra el principio: «con esto no he trabajado, pero la tarea se resuelve igual que X, mediante una descripción declarativa y una ejecución idempotente». El entrevistador evalúa la transferibilidad del pensamiento, no el conocimiento de la API.
Con un rango, no con una sola cifra, basado en el mercado. El análisis detallado está en el artículo negociación salarial.
Describa la situación en una frase — «entrevista para ingeniero DevOps, Kubernetes y CI/CD, cuatro años de experiencia» — y complete el diálogo en el simulador. El entrenador hará preguntas sobre su rol y analizará las respuestas después de la conversación.
Recuerde dos de sus incidentes y descríbalos según el esquema: síntoma — hipótesis — qué comprobó — solución — prevención. Luego repase el caso en voz alta: abra HintMeTalk AI, modo «Entrenador», describa la vacante en una sola frase. Después del análisis se ve dónde empieza a corregir sin haber comprobado la hipótesis.
Análisis de otros roles: Java, Python, frontend, analista de sistemas.
Practica esta habilidad en HintMeTalk AI
Abrir la app
HintMeTalk