Entrevista conductual: Cuéntame sobre una ocasión en la que lideraste durante un incidente crítico de producción

Pregunta y contexto aplicable

Cuéntame sobre una ocasión en la que lideraste durante un incidente crítico de producción. ¿Cuál fue el impacto en los clientes, qué autoridad tenías, cómo estableciste las prioridades y los roles, qué decisiones y comunicaciones impulsaste personalmente y qué cambió después?

El material actual de entrevistas públicas incluye esta pregunta directamente para la gestión de soporte a producción, mientras que el material profesional más amplio de 2026 continúa utilizando preguntas sobre crisis y situaciones difíciles con el método STAR. Las guías oficiales de contratación también piden a los candidatos que preparen ejemplos conductuales de forma estructurada. Por lo tanto, la pregunta es adecuada para engineering managers, staff engineers, SREs, ingenieros de plataforma y backend, líderes técnicos y roles de soporte a producción. No está vinculada a un empleador específico.

Esta es una pregunta de liderazgo sobre comportamientos pasados. Una pregunta de resolución de problemas indaga cómo localizarías una falla; esta pregunta indaga qué hiciste realmente cuando el impacto, la incertidumbre, las personas y la presión de tiempo coincidieron. Conserva los detalles técnicos únicamente cuando expliquen una decisión de liderazgo. La historia más sólida permite verificar de forma independiente tu autoridad, tus acciones personales, el impacto en el cliente, las compensaciones (trade-offs), el resultado y el mecanismo implementado posteriormente.

Elige un incidente cerrado o un casi incidente (near-miss) de consecuencias relevantes del que puedas hablar de manera segura. Debe involucrar varias necesidades en conflicto —por ejemplo, restablecer el servicio, proteger los datos, coordinar a los encargados de responder y mantener informadas a las partes interesadas— y al menos una decisión que hayas tomado o moldeado personalmente. Si solo observaste la respuesta, elige otra historia o describe tu contribución más acotada con honestidad. Nunca conviertas el incidente de un colega en una afirmación de tu propio liderazgo.

Qué evalúa el entrevistador

La primera señal es la precisión del rol. «Lideré el incidente» puede significar ser el incident commander formal, el líder en funciones según la política de guardias (on-call), el líder de operaciones, el líder de comunicaciones o el ingeniero que coordinó una línea de trabajo específica. Indica cuál de ellos fuiste. Un candidato que distingue la autoridad de decisión de la experiencia técnica es más creíble que aquel que afirma haber comandado, depurado, aprobado, comunicado y reparado todo por su cuenta.

La segunda señal es la prioridad bajo presión. Las respuestas sólidas comienzan con la seguridad de las personas, la seguridad informática, la integridad de los datos y el impacto en los clientes; luego contienen el daño y restablecen el servicio antes de buscar una teoría elaborada sobre la causa raíz. También explican por qué un rollback, un desvío de tráfico, la desactivación de una funcionalidad, una pausa en las escrituras o un modo degradado eran opciones suficientemente seguras. La velocidad sin límites de riesgo es imprudencia, mientras que el análisis sin mitigación deja expuestos a los usuarios.

La tercera señal es la coordinación. La guía de incidentes de Google separa el comando del incidente, las operaciones y las comunicaciones para que una persona pueda mantener el estado general mientras los operadores autorizados modifican el sistema y otro responsable actualiza a las partes interesadas. Los nombres exactos pueden variar. La señal evaluada en la entrevista es si creaste una línea de mando clara, delegaste resultados, evitaste cambios contradictorios en producción y adaptaste la estructura a la magnitud del incidente.

La cuarta señal es la toma de decisiones con información incompleta. Debes separar los hechos confirmados de las hipótesis, establecer un momento límite para tomar decisiones, comparar el daño actual con el riesgo de la mitigación y nombrar la señal que confirmaría o revertiría la acción. «Hubo un despliegue, así que hice un rollback» es más débil que mostrar verificaciones de compatibilidad, verificaciones de capacidad, un responsable asignado, una ventana de observación y una alternativa por si el rollback fallaba.

La quinta señal es la disciplina en la comunicación. Las partes interesadas necesitan conocer el impacto, los hechos conocidos, las incógnitas, la acción actual y la hora de la próxima actualización. No necesitan una causa raíz no verificada ni cada línea del log. Los encargados de la respuesta necesitan una única cronología activa y decisiones explícitas. Una buena comunicación reduce las interrupciones y permite una revisión posterior; es trabajo operativo, no un simple pulido de presentación.

Finalmente, el entrevistador evalúa el cierre y el aprendizaje. La recuperación requiere evidencia de la integridad y del resultado para el usuario, no solo un gráfico de infraestructura en verde. El seguimiento requiere una revisión sin culpas (blameless review), un conjunto reducido de acciones con responsables asignados y pruebas de que las alertas, los controles de despliegue, los runbooks o los simulacros cambiaron. Un rescate heroico sin cambios duraderos es una historia de liderazgo incompleta.

Preguntas para clarificar antes de responder

• ¿Qué significa «liderar» en esta entrevista? Si el entrevistador busca gestión formal de personas, elige una historia en la que hayas dirigido a un equipo. Si el liderazgo técnico es aceptable, define con precisión tu rol operativo y tus facultades de decisión.
• ¿Fue un incidente real o un escenario hipotético? Usa el método STAR para preguntas sobre comportamientos pasados. No respondas con «yo haría» a menos que el entrevistador cambie explícitamente a una pregunta de escenario.
• ¿Qué tan grave debe ser el incidente? No tiene que ser una interrupción global del servicio. Un evento acotado puede funcionar si el impacto en los clientes o en el negocio fue significativo, la coordinación fue real y tus decisiones tuvieron consecuencias.
• ¿Qué información se puede divulgar? Omite nombres de clientes, credenciales, detalles de seguridad, umbrales internos exactos y cifras comercialmente sensibles. Conserva la lógica causal y utiliza rangos aprobados donde sea necesario.
• ¿Tenías autoridad sobre producción? Si otra persona aprobaba los cambios, menciónalo. Muestra cómo estructuraste las opciones, la evidencia y la urgencia para quien tomaba las decisiones en lugar de atribuirte su autoridad.
• ¿La historia ha llegado a su cierre? Prefiere un incidente con una recuperación verificada y al menos una acción de seguimiento completada. Un evento de seguridad, legal o de integridad de datos no resuelto suele ser un mal ejemplo para una entrevista.
• ¿De cuánto tiempo se dispone? Una respuesta de 2 minutos debe incluir el impacto, el rol, las acciones decisivas, el resultado y el aprendizaje. Agrega el registro de hipótesis, los desacuerdos y la validación posterior cuando el entrevistador profundice con más preguntas.

Estructura de respuesta de 30 segundos

«En [momento y contexto del negocio], [resultado para el cliente] se degradó de [línea base] a [impacto real]. Yo era el [rol preciso durante el incidente], autorizado para [límite de decisión]; [otro responsable] conservaba la autoridad para [decisión reservada]. Declaré o me uní al incidente, establecí [prioridades de seguridad y del cliente], asigné la responsabilidad de operaciones y comunicaciones, y congelé los cambios en conflicto. Con base en [evidencia confirmada], elegí [medida de mitigación reversible] en lugar de [alternativa], con [señal de recuperación] y [plan de contingencia]. Mantuve alineados a los encargados de la respuesta y a las partes interesadas mediante [frecuencia y registro de decisiones]. El servicio se recuperó a las [resultado verificable], reconciliamos [impacto en la integridad/el cliente] y, posteriormente, impulsé [mecanismo], verificado más adelante mediante [simulacro o hecho comparable]».

Esta apertura proporciona al entrevistador cinco puntos de anclaje: impacto, autoridad, organización, decisión y resultado. La respuesta más detallada debe mostrar cómo llegaste a la decisión y qué cambiaste personalmente después del incidente.

Respuesta detallada paso a paso

Paso 1: Seleccionar una historia con evidencia de liderazgo

Elabora un breve inventario a partir de revisiones reales de incidentes, actualizaciones de estado, registros de decisiones, tickets y tareas de seguimiento. Una historia adecuada tiene una consecuencia visible para el usuario o el negocio, más de una parte interesada, un rol específico que desempeñaste, una decisión que puedes defender, una recuperación verificada y un aprendizaje completado. Prefiere un caso en el que personas razonables hayan estado en desacuerdo o en el que faltara información crítica; eso demuestra criterio mucho mejor que la simple ejecución rutinaria de un runbook.

Descarta historias que requieran divulgar una vulnerabilidad activa, culpar a un colega identificable o fingir que asumiste una decisión que correspondía a otra persona. Descarta también historias cuyo único resultado sea «al final lo arreglamos». Necesitas evidencia de la recuperación del servicio, del cierre para los clientes o los datos, y de un mecanismo modificado.

Paso 2: Establecer la autoridad antes de describir las acciones

Indica cómo asumiste el rol y qué te permitía hacer. Por ejemplo: «La política de guardias me convirtió en incident commander en funciones hasta que el reliability manager asumió el control. Yo podía declarar la gravedad, asignar encargados de respuesta, congelar despliegues y recomendar mitigaciones; el propietario de la base de datos aprobaba cualquier pausa en las escrituras». Esa frase evita dos brechas comunes de credibilidad: usar un título de trabajo como prueba de mando y exagerar los derechos de aprobación.

Nombra los roles que fueron relevantes. Un incidente grande puede requerir un incident commander, un líder de operaciones, un líder de comunicaciones, un documentador (scribe) y varios expertos en la materia. Un incidente más pequeño puede combinar roles, pero el responsable de la combinación debe saber qué responsabilidad está cumpliendo en cada momento. El liderazgo consiste en diseñar la estructura adecuada para el alcance actual, no en rellenar un organigrama por el simple hecho de hacerlo.

Paso 3: Estructurar el incidente en torno al impacto y la seguridad

Utiliza un esquema compacto: comportamiento esperado, comportamiento real, hora de inicio, grupo afectado, consecuencia para el cliente o el negocio y cualquier preocupación de seguridad o integridad de datos. Luego, indica el orden inicial de prioridades. Una secuencia útil es:

1. proteger a las personas, las credenciales, el dinero y los datos;
2. detener la expansión del impacto;
3. restablecer una ruta segura para los clientes;
4. conservar suficiente evidencia para el diagnóstico;
5. reconciliar los resultados afectados y prevenir la recurrencia.

Esto no significa que el diagnóstico se posponga hasta la recuperación. Significa que el diagnóstico está al servicio de la mitigación mientras el impacto siga activo. Si el evento puede generar cobros duplicados o corromper registros, pausar una ruta de escritura puede tener mayor prioridad que la disponibilidad. Si la integridad está a salvo y un mecanismo de respaldo (fallback) probado cuenta con capacidad, la restauración puede tener prioridad.

Paso 4: Crear una única línea de mando y delegar resultados

Indica quién mantenía el estado del incidente, quién podía modificar producción, quién era el responsable de las actualizaciones para las partes interesadas y dónde residía la cronología en vivo. Congela los cambios no relacionados y exige que las acciones propuestas incluyan un responsable, la señal esperada, el riesgo y la ruta de reversión. Delega resultados —«compara las regiones en buen estado y las afectadas, e informa cuál es el factor de diferenciación más claro»— en lugar de emitir tareas vagas como «revisen los logs».

Mantén tu rol fuera de la ruta crítica siempre que sea posible. Un incident commander que se sumerge en una terminal puede perder de vista el aumento del impacto, cambios contradictorios o preguntas sin responder de las partes interesadas. Si el equipo es demasiado pequeño para separar los roles, reconoce el compromiso asumido y describe cómo redujiste su riesgo, como el uso de un segundo aprobador y una lista de acciones por escrito.

Paso 5: Separar hechos, hipótesis y decisiones

Mantén tres listas. Los hechos confirmados describen el impacto observable y las acciones completadas. Las hipótesis establecen qué evidencia se esperaría encontrar si fueran ciertas. Las decisiones registran por qué el equipo eligió una acción, quién la aprobó, cuándo se evaluará y qué causaría una reversión. No permitas que un despliegue reciente, una parte interesada insistente o un modo de falla conocido se conviertan en una causa raíz no verificada.

Una actualización concisa puede utilizar los mismos campos cada vez:

Impact:
Known:
Unknown:
Current action:
Decision owner:
Recovery signal:
Next update:

Esta plantilla es útil en una entrevista porque demuestra control sin necesidad de recitar una herramienta específica de un proveedor. En tu historia, proporciona un ejemplo real de cómo una actualización o decisión cambió el rumbo del equipo.

Paso 6: Tomar una decisión de mitigación reversible y con un tiempo límite

Explica las opciones que consideraste y el criterio que permitió distinguirlas. Para un rollback, verifica la compatibilidad de estado y protocolo, la capacidad del entorno de destino, la duración del rollback y las consecuencias de una falla. Para un desvío de tráfico, verifica el margen de capacidad (headroom) de la región saludable y la residencia de los datos. Para desactivar una funcionalidad, identifica los estados parciales y la recuperación de los clientes. Para pausar las escrituras, define quién puede reabrirlas y qué conciliación debe completarse primero.

Luego, registra una ventana de observación y un plan de respaldo. «Si la tasa de compras exitosas no se recupera y la antigüedad de la cola no comienza a descender dentro de la ventana acordada, detendremos el rollback y aislaremos la dependencia downstream» es lógica de decisión. «Intentamos un rollback y esperamos a ver qué pasaba» es simple cronología.

Paso 7: Comunicar la incertidumbre sin generar ruido

Utiliza una frecuencia fija de comunicación, con actualizaciones más rápidas si el impacto o el riesgo cambian de forma sustancial. Los mensajes internos y externos pueden diferir en detalle, pero deben coincidir en el impacto confirmado y el estado. Di «la ruta de pago es la hipótesis principal; la verificación está en curso» en lugar de anunciar una causa antes de contar con evidencia. Proporciona a los equipos de soporte una explicación aprobada para los clientes y una ruta de escalamiento para casos especiales.

Muestra también cómo gestionaste los desacuerdos. Pide a cada experto una predicción, una verificación de bajo riesgo y el costo que implica esperar. El incident commander decide o escala a través de la autoridad reservada. Una vez tomada la decisión, el equipo ejecuta una única ruta y observa las señales establecidas; el desacuerdo queda documentado en el registro de decisiones en lugar de convertirse en cambios paralelos en producción.

Paso 8: Demostrar la recuperación e implementar el aprendizaje

La recuperación combina evidencia técnica y de negocio: errores, latencia, saturación, acumulación de tareas (backlog), acciones exitosas de los usuarios, conciliación de datos, casos de soporte y monitoreo durante una ventana de tiempo acordada. Si el servicio se recuperó pero algunos clientes permanecen en un estado incierto, el incidente está mitigado, pero la remediación para los clientes sigue abierta. Indica quién se hizo responsable de ese tramo final.

Después, separa el factor desencadenante, las condiciones que contribuyeron y las deficiencias en la respuesta. Utiliza un lenguaje sin culpas manteniendo al mismo tiempo la responsabilidad sobre las decisiones. Elige un número reducido de acciones con responsables, plazos y evidencia de aceptación: una salvaguarda de canary, un rollback probado, un simulacro de roles, una plantilla de actualización de incidentes, una consulta de integridad o un mecanismo de respaldo ante fallas de dependencias. Cierra el resultado STAR con un simulacro posterior o un despliegue comparable que demuestre que el mecanismo se utilizó. Si no existe un evento posterior, informa únicamente el estado implementado y probado; no inventes un éxito de prevención inexistente.

Ejemplo de respuesta de alta calidad

Todo el escenario a continuación es material de práctica ficticio. Las horas, tasas, recuentos, roles y resultados son marcadores de posición y deben sustituirse con evidencia verídica. No lo presentes como experiencia personal.

«A las 10:08, durante una promoción, la tasa de fallas en el checkout aumentó desde una línea base del 0.4% hasta el 18%. Alrededor de 1,200 intentos entraron en estados fallidos o inciertos en los primeros 12 minutos. Yo era el incident commander en funciones según nuestra política de guardias. Podía declarar la gravedad, congelar despliegues, asignar roles y aprobar el rollback de aplicaciones o configuraciones; el responsable de pagos conservaba la autoridad para pausar las escrituras de liquidación.

Declaré el incidente, establecí el daño al cliente y la integridad de los pagos como las primeras prioridades, y asigné un líder de operaciones, un líder de comunicaciones y un documentador. No ejecuté comandos en producción por mí mismo. Le pedí al equipo de operaciones que comparara la versión, la región y la ruta de pago, mientras el responsable de datos verificaba cobros duplicados y cobros sin orden asociada. Congelamos los cambios no relacionados y establecimos una frecuencia de actualización de 15 minutos para las partes interesadas.

Un despliegue de checkout había terminado poco antes de la alerta, pero la misma versión funcionaba correctamente en otra región, mientras que las versiones nueva y anterior fallaban por igual en una ruta de pago específica. Esa evidencia debilitó la hipótesis del código y reforzó la de un cambio de configuración en el enrutamiento regional. Consideramos revertir la aplicación, revertir la ruta o desactivar el método de pago afectado. El cambio de ruta era reversible de forma independiente, su destino anterior tenía capacidad confirmada y evitaba alterar el estado de los pedidos. Aprobé esa reversión a las 10:24, tomando el éxito del checkout y la antigüedad de la cola como señales de recuperación, y la desactivación del método de pago como plan de respaldo.

Durante la respuesta, informé sobre el impacto confirmado, la hipótesis principal pero aún no probada, la acción en curso y la hora de la próxima actualización. Cuando un ingeniero quiso reiniciar todas las instancias simultáneamente, lo rechacé porque habría alterado la evidencia sin abordar el contraste regional; en su lugar, solicité una comparación acotada.

Para las 10:31, las fallas en el checkout habían regresado al 0.6% y la cola se estaba vaciando. Mantuvimos el incidente abierto mientras reconciliábamos los 1,200 intentos. Identificamos 37 pedidos que requerían seguimiento con el cliente y 0 cobros duplicados tras la auditoría. Soporte contactó a los clientes afectados y el incidente se cerró únicamente después de haber registrado a dichos responsables y sus fechas límite.

La revisión posterior concluyó que el cambio de ruta fue el desencadenante, mientras que la falta de verificaciones de canary y la poca claridad sobre la responsabilidad de las comunicaciones amplificaron el impacto. Impulsé la creación de un canary de enrutamiento con salvaguardas para el checkout y la integridad de pagos, agregué la plantilla de estado de 7 campos al runbook y programé un simulacro de roles. En un simulacro posterior, otro ingeniero asumió el comando y el equipo generó su primera actualización completa dentro de la frecuencia establecida. Mi principal aprendizaje fue que el liderazgo en incidentes consiste en mantener las prioridades y la calidad de las decisiones; haber sido el depurador más rápido me habría convertido en un cuello de botella».

Al adaptar este ejemplo, preserva la cadena de evidencia: impacto → autoridad → roles → decisión debatida → comunicación → recuperación → cierre con el cliente → mecanismo probado. Reemplaza cada marcador de posición con un hecho que puedas defender, o utiliza una descripción cualitativa honesta si no dispones de datos exactos.

Errores comunes

• Contar una cronología de depuración en lugar de una historia de liderazgo → el entrevistador escucha herramientas y síntomas, pero no puede evaluar la coordinación ni el criterio → conserva únicamente la evidencia técnica que haya cambiado una prioridad o decisión.
• Decir «lideré» sin definir la autoridad → las preguntas de seguimiento exponen decisiones atribuidas incorrectamente → menciona tu rol en el incidente, las acciones permitidas y las aprobaciones reservadas desde el inicio.
• Adjudicarse todos los roles → una historia de héroe solitario hace que la delegación y el control resulten inverosímiles → separa el comando, las operaciones, las comunicaciones y las contribuciones de los especialistas.
• Optimizar únicamente la velocidad → un rollback o un reinicio riesgoso puede incrementar el daño a los clientes o a los datos → compara el riesgo de la mitigación con el daño actual y define una ruta de reversión.
• Tratar la correlación como causa raíz → un despliegue reciente puede desviar la atención de diferencias regionales, de dependencias o de tráfico → plantea hipótesis y la evidencia que respaldó o descartó cada una.
• Reportar una precisión no verificada → inventar tasas y tiempos se desmorona ante preguntas detalladas → recupera las cifras de los registros del incidente o usa un rango aprobado indicando qué mide.
• Culpar a la persona que realizó el cambio → la respuesta proyecta poca confianza e ignora las condiciones sistémicas → describe las decisiones, las condiciones contribuyentes y las mejoras responsables sin acusaciones personales.
• Decir que los paneles estaban en verde y dar por terminada la historia → pueden quedar remediaciones de clientes, backlogs o inconsistencias de datos pendientes → verifica el éxito del usuario, la integridad de los datos y la asignación de responsables para el tramo final de la recuperación.
• Terminar con «mejoramos el monitoreo» → nadie puede verificar ese aprendizaje → indica el cambio en las alertas o en el despliegue, el responsable, la prueba de aceptación y la evidencia posterior.
• Ocultar los desacuerdos → una historia sin fricciones suena ensayada y oculta el criterio utilizado → muestra un conflicto real, cómo se comparó la evidencia y quién tomó la decisión final.

Preguntas de seguimiento y respuestas

Pregunta de seguimiento 1: ¿Fuiste realmente el incident commander?

Responde con el rol formal o práctico, cómo lo asumiste y qué autoridad conllevaba. Si solo lideraste una línea de trabajo, indícalo y explica cómo reportabas al incident commander. La evidencia de liderazgo se sostiene aun con un título más acotado; una afirmación inflada, no.

Pregunta de seguimiento 2: ¿Qué hiciste tú personalmente y no el equipo?

Utiliza verbos explícitos: declaré, prioricé, asigné, estructuré, aprobé, rechacé, escalé, comuniqué o verifiqué. Luego, atribuye el diagnóstico técnico y la ejecución a sus respectivos responsables. Tu contribución radica en las decisiones y la coordinación que realmente lideraste, no en la cantidad de comandos que escribiste en la terminal.

Pregunta de seguimiento 3: ¿Por qué elegiste esa mitigación?

Reconstruye la decisión con la información disponible en ese momento. Compara al menos una alternativa, el daño actual al cliente, la compatibilidad del estado, la capacidad, el tiempo de impacto, la reversibilidad y la señal de observación. Indica qué evidencia te habría llevado a elegir de otra manera.

Pregunta de seguimiento 4: ¿Cómo gestionaste los desacuerdos entre expertos?

Pide a cada parte una predicción falsable, la verificación de menor riesgo para diferenciar las opciones y el costo de esperar. Confirma quién tiene las facultades de decisión, fija un límite de tiempo para la discusión, registra las discrepancias y ejecuta una única ruta autorizada. La seguridad psicológica permite cuestionar; el control del incidente evita cambios simultáneos y contradictorios.

Pregunta de seguimiento 5: ¿Cómo te comunicaste cuando aún se desconocía la causa raíz?

Separa el impacto confirmado de la hipótesis principal. Informa la acción actual de contención o investigación, qué riesgo se está verificando y la hora de la próxima actualización. Evita tanto el silencio como la falsa certeza. Si un mensaje previo fue erróneo, corrígelo explícitamente e indica qué nueva evidencia cambió la evaluación.

Pregunta de seguimiento 6: ¿Qué hiciste mal durante el incidente?

Elige una deficiencia real en la respuesta: declarar la gravedad tarde, retener demasiados roles, no involucrar a soporte a tiempo, permitir una acción sin una señal clara de recuperación o enviar una actualización ambigua. Explica su efecto y el mecanismo que modificaste a raíz de ello. No inventes un defecto inofensivo solo para aparentar equilibrio en la historia.

Pregunta de seguimiento 7: ¿Qué ocurre si el servicio se recuperó pero la causa raíz aún era incierta?

Explica que el incidente fue mitigado, pero no esclarecido por completo. Preserva la evidencia, delimita el riesgo remanente, decide si se pueden reanudar los cambios habituales y asigna la reproducción o el análisis con un responsable y una fecha límite. Usa expresiones como «lo más probable» hasta que una prueba distinga entre las alternativas; la recuperación de la disponibilidad no autoriza una certeza infundada.

Pregunta de seguimiento 8: ¿Cómo demuestras que el equipo está mejor preparado ahora?

Básate en comportamientos observables: un simulacro completado dentro de la frecuencia objetivo, un canary que detuvo un despliegue defectuoso, otro encargado de respuesta que utilizó con éxito el runbook o elementos de acción que superaron sus pruebas de aceptación. Si solo existe evidencia de la implementación, dilo con honestidad y evita atribuirte una reducción de recurrencia que no hayas medido.