Questions to Ask in a DevOps Engineer Interview

Interview PrepJobRise Team7 min read

Llegas al final de la entrevista, te dicen "¿tienes alguna pregunta?" y tu mente se queda en blanco. O peor: preguntas algo tan genérico que el entrevistador piensa que preparaste la charla hace diez minutos. En un puesto de DevOps Engineer, ese momento pesa más que en otros roles, porque la gente con la que hablas evalúa cómo piensas sobre sistemas, no solo lo que sabes.

Las preguntas que haces muestran tu nivel de experiencia. Un junior pregunta por las herramientas. Un senior pregunta por las decisiones, las consecuencias y los límites de lo que el equipo ha construido.

Por qué importan tanto en DevOps#

DevOps no es un puesto aislado. Tocas infraestructura, despliegues, seguridad, costes y a otros equipos. Cualquier cosa que preguntes sobre ese entorno revela si entiendes el terreno o si solo has leído la descripción del puesto.

Además, tú también estás evaluando. Un entorno con despliegues manuales, sin ownership claro y con guardias sin compensar puede arruinarte el año. Preguntar bien te da información real antes de aceptar.

Recibe la próxima guía por email

Guías nuevas y empleos recientes en un email corto. Gratis.

Date de baja con un clic.

Las 12 preguntas agrupadas por lo que revelan#

Sobre la realidad del equipo

  1. ¿Cuántas personas hay en el equipo de plataforma o DevOps, y cómo se reparten las guardias? Te dice si es un equipo real o una persona sola sosteniendo todo.

  2. ¿Cuánto tiempo dedica el equipo a trabajo reactivo frente a trabajo planificado? Si la respuesta es "casi todo es urgente", ahí tienes un problema de prioridades, no de personal.

  3. ¿Quién decide qué entra en un sprint de infraestructura: el propio equipo o peticiones externas? Esto distingue un equipo con voz propia de un departamento de soporte con otro nombre.

  4. ¿Cómo se resuelve una decisión técnica donde no hay acuerdo? Escucha si mencionan diseño documents, RFCs o si todo se resuelve en reuniones.

Sobre las prioridades técnicas

  1. ¿Cuál es el mayor dolor técnico del que les gustaría librarse este año? Es la pregunta que más respuestas honestas produce, porque todos tienen uno.

  2. ¿Cómo es el proceso de despliegue hoy, de principio a fin, y cuánto tarda? No preguntes solo "¿usáis Kubernetes?". Pregunta por el flujo real, con tiempos.

  3. ¿Qué está en su lista de "lo haríamos si tuviéramos tiempo"? Aquí aparecen deuda técnica, migraciones pendientes y proyectos cancelados.

  4. ¿Cómo gestionan los costes de nube y quién es responsable de ellos? Si nadie lo sabe, la factura crece sin control. Es más común de lo que parece.

Sobre los criterios de éxito

  1. ¿Cómo saben que un despliegue ha ido bien, y quién lo detecta primero? Revela si tienen observabilidad real o si se enteran por los usuarios.

  2. ¿Qué medirían a los seis meses para saber que la persona contratada ha funcionado? Pide una respuesta concreta. "Integrarte bien en el equipo" no es un criterio.

Sobre los riesgos

  1. ¿Cuándo fue la última incidencia grave, y qué cambió después de ella? Cada equipo tiene incidencias. Lo que importa es si aprendieron o solo apagaron el fuego.

  2. ¿Qué pasa si alguien del equipo se va de vacaciones dos semanas sin conexión? Es una forma educada de preguntar si el conocimiento está documentado o vive en una cabeza.

Cómo leer las respuestas#

No se trata solo de la pregunta. Fíjate en cómo responden, en las pausas y en quién habla.

Una respuesta vaga sobre la guardia suele significar que la guardia es mala. Si al preguntar por la última incidencia cambian de tema o echan la culpa a otro departamento, tenlo en cuenta. Un equipo maduro habla de sus errores sin drama.

También cuenta la coherencia. Si dicen que hacen despliegues automáticos pero luego mencionan aprobaciones manuales en tres niveles, algo no cuadra. No hace falta señalarlo. Guarda el dato.

Un ejemplo de cómo sondear sin sonar a auditoría, si te dicen "hacemos despliegues continuos":

  • Tú: "¿Y cuántos despliegues hacéis al día, más o menos?"
  • Ellos: "Unos diez o doce."
  • Tú: "¿Y si algo falla, cuánto tardáis en volver a la versión anterior?"
  • Ellos: "Cinco o diez minutos, tenemos rollback automático."

Ese intercambio te dice más que veinte diapositivas sobre su stack.

Cuándo hacerlas#

No lances las doce seguidas. Elige tres o cuatro según la conversación que hayas tenido, y deja que se genere un diálogo. Si han hablado mucho de Kubernetes, pregunta por la deuda técnica. Si han mencionado guardias, ve a por la de tiempos de reacción.

También puedes prepararlas leyendo bien la oferta antes. Un buen análisis del anuncio te muestra qué prioridades tienen y qué preguntas encajan mejor.

Qué preguntas evitar#

Algunas preguntas restan en lugar de sumar, sobre todo en entrevistas técnicas.

  • ¿Qué hace exactamente la empresa? Investígalo antes. Es tu trabajo.
  • ¿Cuántos días de vacaciones hay? Es legítimo, pero pregúntalo a RR. HH. en otra fase, no al ingeniero que evalúa tu nivel.
  • ¿Hacéis pair programming, Scrum, TDD, Kubernetes, Terraform...? Una lista de siglas suena a que estás marcando casillas, no a que entiendes para qué sirve cada cosa.
  • ¿Es un buen lugar para trabajar? Es demasiado vaga para que puedan responderte con sinceridad.

Tampoco preguntes por el salario en la primera entrevista técnica si no lo han mencionado. Hay un momento para eso. Y si quieres contrastar condiciones reales del mercado, en los portales de ofertas puedes ver rangos publicados para puestos similares, aunque varían mucho según país, experiencia y modalidad de trabajo.

Cómo preparar tus preguntas#

Un día antes de la entrevista, dedica veinte minutos a esto. Es la parte más barata de preparar y la que más diferencia marca.

  • Relee la oferta y anota tres palabras que se repiten. Son sus prioridades declaradas.
  • Busca al equipo en la web de la empresa o en su blog técnico si tienen, para no preguntar algo publicado.
  • Elige cuatro preguntas de las doce: dos de prioridades técnicas, una de equipo y una de riesgos.
  • Prepara una pregunta de seguimiento para cada una, por si la respuesta es corta.
  • Anota lo que quieras saber de verdad. Si te preocupa la estabilidad del puesto, pregunta por la rotación del último año. Directo y sin rodeos.

Si quieres, puedes pasar la descripción del puesto por un decodificador de ofertas para entender qué esconden términos como "ambiente dinámico" o "multitarea". A veces las mejores preguntas salen de ahí.

Si eres tú quien entrevista#

Este artículo está pensado para quien busca trabajo, pero sirve al revés. Si estás contratando para tu equipo, esas mismas doce preguntas son las que un buen candidato te hará. Si tu respuesta honesta te incomoda, el problema no es la pregunta.

Y si estás preparando varias entrevistas a la vez, mantener el control de a qué empresa has enviado qué y en qué fase estás te ahorra disgustos. En la sección de empleo puedes seguir procesos abiertos y comparar requisitos entre ofertas similares. También tenemos más guías sobre procesos de selección técnica en nuestro blog.

Herramientas gratis#

Preguntas frecuentes#

¿Cuántas preguntas debo hacer en una entrevista técnica?

Entre tres y cuatro. Suficiente para demostrar interés y criterio, sin convertir la entrevista en un interrogatorio. Mejor pocas y bien elegidas que una lista larga sin seguimiento.

¿Es buena idea preguntar por la tecnología que usan?

Sí, pero con contexto. En vez de "¿usáis Terraform?", prueba "¿cómo gestionáis la infraestructura como código y qué os ha dado más problemas?". La respuesta te da información útil en lugar de un sí o un no.

¿Qué hago si me dicen que no pueden responder por confidencialidad?

Es normal en algunas empresas, sobre todo en banca o proyectos con clientes sensibles. Acepta la respuesta y pregunta si pueden describir el proceso sin entrar en detalles concretos.

¿Debo preguntar por el salario en la entrevista con el equipo técnico?

Mejor no. Es un tema legítimo, pero encaja en la conversación con reclutamiento o con quien lleva el proceso de contratación. En la técnica, céntrate en el trabajo y en el entorno.

¿Sirven estas preguntas si tengo poca experiencia en DevOps?

Sí, y te ayudan a sonar más preparado de lo que crees. No necesitas diez años para preguntar cómo se despliega o quién atiende la guardia. Son preguntas de sentido común, y eso se nota.

Envíaselo a quien tenga la entrevista esta semana.