Saltar al contenido
Aethel

Entrevista con IA para ingenieros de DevOps y SRE

Actualizado en noviembre de 2026

Las entrevistas de DevOps y SRE giran en torno a los incidentes. Una entrevista con IA le va a pedir que recorra una caída minuto a minuto, que defienda un proceso de despliegue, que explique cómo fijó metas de confiabilidad y que diga qué automatizó. Aquí están las preguntas que puede esperar, dos ejemplos resueltos, los errores que debilitan las respuestas de operaciones y práctica gratuita en su nivel.

Practicar preguntas de DevOps y SRE gratis

Esta guía y la práctica para su rol están en español. La inscripción y la página de resultados de Aethel están en inglés, y la entrevista la puede hacer en español: lo elige justo antes de empezar.

Qué preguntan las entrevistas con IA a ingenieros de DevOps y SRE

  1. Un incidente de la alerta a la solución

    “Cuénteme del último incidente serio que atendió. ¿Qué revisó primero?”

    Lo que se escucha: Una línea de tiempo, cómo acotó el problema, mitigar antes de buscar la causa raíz y qué cambió después.

  2. Despliegues y reversiones

    “¿Cómo llevaba su equipo los cambios a producción, y cómo hizo que revertir fuera seguro?”

    Lo que se escucha: El pipeline paso a paso, canarios o despliegues graduales, y una vez en que revertir importó.

  3. Metas de confiabilidad

    “¿Cómo decidió qué tan confiable tenía que ser un servicio?”

    Lo que se escucha: Un SLO atado a lo que sienten los usuarios, un presupuesto de errores y una decisión que ese presupuesto cambió.

  4. Infraestructura como código

    “Cuénteme de infraestructura que usted pasó a código. ¿Qué salió mal?”

    Lo que se escucha: La herramienta y por qué, problemas de estado o de desvío, y cómo se revisaban los cambios.

  5. La carga de las guardias

    “Las guardias recibían demasiadas alertas. ¿Qué hizo?”

    Lo que se escucha: Alertas contadas antes y después, cuáles eliminó o cambió, y cómo se puso de acuerdo el equipo.

  6. Costos

    “Describa una vez que bajó el costo de la infraestructura sin perjudicar la confiabilidad.”

    Lo que se escucha: En qué se iba el dinero, el cambio y los números de ambos lados.

  7. Accesos y secretos

    “¿Cómo manejó los secretos y el acceso a producción?”

    Lo que se escucha: Un control concreto, por qué lo eligió y la fricción que generó.

Ejemplo resuelto: un disco lleno el día de pago de sueldos

Cada ejemplo muestra una respuesta débil y una fuerte a la misma pregunta. Las líneas “Con las reglas de Aethel” aplican las reglas de calificación publicadas de Aethel, un ejemplo concreto de cómo una entrevista con IA puede evaluar una respuesta.

Ejemplo inventadoEscrito por Aethel para mostrar la diferencia. No es una persona real y la IA no lo calificó.

Pregunta: “Cuénteme del último incidente serio que atendió. ¿Qué revisó primero?”

Respuesta débil

“Una vez tuvimos una caída grande y el sistema dejó de responder. Yo estaba de guardia, entré, miré los dashboards y los logs, y encontré que el problema era la base de datos. Lo solucionamos y después hicimos un postmortem. Trabajo muy bien bajo presión y me gusta resolver incidentes.”

Por qué es débil: No hay línea de tiempo, ni síntoma, ni causa más allá de "la base de datos", ni un cambio después. La última oración habla de usted, algo que el entrevistador no puede comprobar. Una repregunta como "¿qué mostraban los dashboards?" no tiene de dónde agarrarse.

Con las reglas de Aethel: Situación 1, razonamiento 0, resultado 0: 1 de 8 puntos, y sin un caso específico el área llega como máximo a 60 en la escala de Aethel.

Respuesta fuerte

“En una empresa de remuneraciones en Chile, que paga los sueldos de unas 1.500 empresas clientes, yo lideraba la guardia el último día hábil del mes cuando la cola de transferencias bancarias dejó de avanzar: a las 9:40 había 38.000 pagos pendientes y seguían creciendo. Lo primero que revisé fue qué había cambiado, pero ese día no hubo despliegues, así que pasé a los recursos de los procesos de la cola y vi que el disco de dos de ellos estaba al 100 por ciento. Un cambio de la semana anterior había subido el nivel de logs a depuración, y con el tráfico normal nadie lo había notado. Consideré sumar más procesos, pero sin espacio en disco iban a fallar igual. Primero restauré el servicio: liberé espacio, bajé el nivel de logs con una variable de configuración y reinicié los procesos uno por uno, y la cola se vació en 50 minutos, antes del corte del banco a las 14:00. Después agregamos una alerta con el disco al 80 por ciento, rotación de logs con límite de tamaño y revisión obligatoria para cualquier cambio de nivel de logs en producción. En los cinco cierres de mes siguientes no se repitió.”

Por qué es fuerte: Da el síntoma con números y el plazo que importaba (el corte del banco), explica qué revisó primero y por qué pasó a lo siguiente, y restaura el servicio antes de buscar la causa de fondo. La causa es precisa, los cambios posteriores corrigen el proceso en lugar de culpar a una persona, y el resultado se comprueba en los cierres siguientes.

Con las reglas de Aethel: Situación 2, razonamiento 2, resultado 3: 7 de 8 puntos, que en la escala fija de Aethel son 91. Un puntaje real puede ser distinto.

Lo que viene después: Repregunta probable: ¿por qué un cambio de nivel de logs no pasaba por la misma revisión que el código? Contar cómo buscó otras configuraciones con el mismo vacío fortalece la respuesta.

Ejemplo resuelto: una factura de nube que había que bajar un 30 por ciento

Ejemplo inventadoEscrito por Aethel para mostrar la diferencia. No es una persona real y la IA no lo calificó.

Pregunta: “Describa una vez que bajó el costo de la infraestructura sin perjudicar la confiabilidad.”

Respuesta débil

“La factura de la nube estaba muy alta, así que optimicé los recursos. Apagué servidores que no se usaban, cambié algunas instancias por otras más chicas y configuré autoescalado. Ahorramos bastante plata y todo siguió funcionando bien.”

Por qué es débil: Nombra técnicas, pero no dice cuánto se gastaba, en qué, ni cómo decidió qué apagar sin riesgo. "Bastante plata" y "siguió funcionando bien" no se pueden comprobar, y achicar instancias sin medir la carga invita a la repregunta más obvia.

Con las reglas de Aethel: Situación 0, razonamiento 0, resultado 1: 1 de 8 puntos, y sin un caso específico el área llega como máximo a 60 en la escala de Aethel.

Respuesta fuerte

“En una plataforma de cursos en línea en Perú, con unos 200.000 estudiantes activos, la factura de la nube había llegado a unos 42.000 dólares al mes y la dirección pidió bajarla un 30 por ciento. Antes de tocar nada, etiqueté cada recurso por servicio y equipo y armé un reporte semanal: el 45 por ciento del gasto era el clúster que procesa los videos, dimensionado para el pico del inicio de clases y casi vacío el resto del mes. Pasé el procesamiento a una cola con instancias interrumpibles, que cuestan una fracción, con reintentos automáticos si una instancia se interrumpía. Evalué reservar capacidad por un año, que daba un descuento seguro, pero nos ataba a un tamaño justo cuando el negocio estaba cambiando. Como límite de confiabilidad usé el tiempo hasta que un video subido queda disponible: tenía que seguir por debajo de 20 minutos en el percentil 95. Tres meses después la factura estaba en unos 27.000 dólares, ese tiempo se mantuvo en 14 minutos y en el inicio de clases siguiente no hubo videos atrasados.”

Por qué es fuerte: Mide antes de cortar (etiquetas y un reporte por servicio), encuentra dónde se iba el dinero y por qué, y elige un cambio con su mecanismo de seguridad. Descarta una alternativa con una razón de negocio, define de antemano qué no podía empeorar y el resultado muestra los dos lados: el costo y la confiabilidad, también en el pico siguiente.

Con las reglas de Aethel: Situación 2, razonamiento 2, resultado 3: 7 de 8 puntos, que en la escala fija de Aethel son 91. Un puntaje real puede ser distinto.

Lo que viene después: Repregunta probable: ¿qué pasaba con un video si se interrumpían varias instancias seguidas? Nombre el límite de reintentos y la alerta que avisaba.

Errores comunes en las respuestas de DevOps y SRE

  • Primero la causa raíz, después los usuarios. En la historia de un incidente, diga cuándo volvió el servicio antes de explicar por qué se rompió. El entrevistador escucha si mitigó primero.
  • Culpar a una persona. "Alguien subió una configuración mala" cierra la historia. Diga qué del proceso la dejó pasar y qué cambió usted.
  • Recitar herramientas. Kubernetes, Terraform y un proveedor de monitoreo no son decisiones. Diga qué problema le resolvió cada uno y cuánto le costó.
  • SLO que nunca cambiaron nada. Si el presupuesto de errores nunca cambió una decisión, el SLO era decorativo. Dé un caso en que frenó lanzamientos o justificó trabajo.
  • Automatizar sin un antes y un después. Diga cuánto tardaba la tarea manual, cada cuánto se hacía y cuánto cuesta ahora.
  • Hablar de costos sin hablar de confiabilidad. Un ahorro que no dice qué métrica protegió suena a riesgo. Nombre lo que no podía empeorar y muestre que no empeoró.

Números que conviene tener a mano

Un entrevistador ubica un caso por sus números. Búsquelos para cada uno de sus casos antes de la entrevista; redondeados sirven:

  • Alertas por semana, y el tiempo hasta detectar y hasta recuperar en un incidente
  • Disponibilidad o tasa de errores frente al SLO que usted fijó
  • Despliegues por día o por semana, y cada cuánto un despliegue causó un problema
  • Servicios, clústeres o cuentas de nube que tenía a cargo
  • Costo mensual de infraestructura antes y después de un cambio
  • Cuánto tardaba una tarea manual antes de automatizarla, y cada cuánto se hacía

Practique gratis

Elija un nivel, escriba una respuesta a cada pregunta y lea la revisión rápida después de cada una. Es gratis, no necesita cuenta, no se guarda nada y no es un puntaje.

Preguntas de ingenieros de DevOps y SRE

¿Una entrevista con IA me va a pedir que arregle un sistema en vivo?

Algunas herramientas le dan un sistema roto o un log para leer, así que pregunte antes. La entrevista de Aethel le pide que cuente incidentes que atendió, y puede darle un escenario realista para razonar en voz alta.

¿Y si yo no lideraba el incidente?

Cuéntelo desde su lugar: qué vio, qué revisó, qué escribió en el canal del incidente. Un relato claro de su propia parte vale más que uno prestado de toda la respuesta del equipo.

Vengo de soporte técnico o de administración de sistemas. ¿Qué casos uso?

Casos en que reemplazó trabajo manual por algo repetible: un script que se volvió pipeline, un servidor que se volvió código, una lista de pasos que se volvió alerta. Diga cuánto costaba antes y cuánto después.

¿Cómo describo infraestructura que no puedo compartir?

Por su forma: cantidad de servicios, regiones, tráfico aproximado y tamaño del equipo. Deje fuera nombres de servidores, identificadores de cuentas y todo lo que un equipo de seguridad borraría de un postmortem.

Más guías

In English: AI interview prep for DevOps engineers and SREs