Consigna
Cuéntame sobre una ocasión en la que encontraste un riesgo de confiabilidad no cuantificado en un lanzamiento, presionaste para pausarlo o limitar su alcance y, posteriormente, obtuviste la aprobación para reanudarlo con evidencia. El entrevistador busca evaluar tu juicio, comunicación, acciones y resultados, no una lista de términos técnicos.
Escenario y límites
Utiliza un proyecto real con una restricción de tiempo clara, usuarios o servicios afectados, señales disponibles en ese momento y tu nivel de autoridad para la toma de decisiones. Es posible que hayas pausado un despliegue completo, cambiado a un canary pequeño o agregado primero capacidad de rollback. No presentes hechos descubiertos más tarde como evidencia con la que contabas en ese momento.
Qué evalúa esto
La prueba evalúa si conviertes una intuición en un riesgo verificable, transformas el desacuerdo en criterios de decisión compartidos (gates) y proteges la confiabilidad sin abandonar la entrega. La coordinación de lanzamientos de Google SRE enfatiza la confiabilidad y la comunicación interfuncional; las revisiones de incidentes de GitLab enfatizan la comprensión de las decisiones en lugar de asignar culpas personales.
Estructura de respuesta de referencia
Usa STAR-L: Situación (Situation) presenta la ventana de lanzamiento y la señal de riesgo; Tarea (Task) establece el resultado para el usuario y la autoridad que tenías; Acción (Action) explica cómo propusiste una pausa, definiste métricas, organizaste la validación, alineaste a las partes interesadas y preservaste la capacidad de rollback; Resultado (Result) detalla el resultado del lanzamiento, el impacto en el usuario y las mejoras; Aprendizaje (Learning) muestra cómo se incorporó un nuevo gate al proceso.
Detalles críticos
Cuantifica el riesgo con un límite máximo de tasa de errores, latencia en la ruta crítica, muestra del canary, duración del rollback o versión de dependencias. Especifica quién era el responsable de la decisión final, cómo todos tuvieron acceso a los mismos datos y qué condiciones permitieron reanudar el lanzamiento. Incluye las pérdidas evitadas y el costo real de haber realizado la pausa.
Errores comunes
Decir que la gente te escuchó porque tenías razón; describir únicamente la solución técnica; culpar a un colega como la fuente del riesgo; afirmar que el riesgo era cero; reportar el éxito sin mencionar el costo de pausar; o reemplazar un gate concreto por "mejoramos el monitoreo".
Rúbrica de evaluación
Las respuestas sólidas cuentan con un cronograma concreto, acciones personales y resultados verificables. Reconocen la presión del negocio y el riesgo de confiabilidad, explican las decisiones de escalamiento y reanudación, y transforman el aprendizaje en un cambio de proceso. Las respuestas débiles contienen conflictos abstractos, carecen de números o no muestran una contribución personal en la toma de decisiones.
Preguntas de seguimiento
¿Qué pasa si el product lead no estaba de acuerdo con la pausa?
Registra los riesgos, las incógnitas, las opciones reversibles y una fecha límite en un único registro de decisión. Propón el canary más pequeño posible o una validación breve. Si excede tu nivel de autoridad, utiliza la vía de escalamiento acordada, documenta el desacuerdo y establece el riesgo aceptado.
¿Cómo demuestras que la pausa no se convirtió en un bloqueo indefinido?
Asigna un responsable, un método de validación y una fecha límite a cada incógnita, con gates de reanudación explícitos. Actualiza el estado diariamente; avanza cuando se superen los gates y reduce el alcance o reevalúa cuando no sea así.
¿Cómo mantienes la revisión libre de culpas (blameless)?
Describe las condiciones del sistema, las señales faltantes, el contexto de decisión y los cambios de proceso utilizando un cronograma fáctico en lugar de inferir motivos. Menciona tus propias conductas a mejorar y da seguimiento a si las acciones correctivas se cierran efectivamente.