Pregunta y contexto
Cuéntame sobre una ocasión en la que encontraste una dependencia oculta antes de un lanzamiento y cambiaste el plan. ¿Cómo demostraste el riesgo, coordinaste a los equipos, elegiste entre un retraso o un despliegue gradual y revisaste el resultado?
Esto se adapta a roles de ingeniería de software, plataforma, producto y programas técnicos. Evalúa el sentido de propiedad (ownership), el juicio de riesgos, la comunicación entre equipos y el aprendizaje, en lugar de convertir cada retraso en una historia heroica. Amazon describe el sentido de propiedad como asumir la responsabilidad de los problemas que encuentras teniendo en cuenta el valor a largo plazo; Microsoft recomienda preparar experiencias pasadas específicas relacionadas con el rol.
Qué evalúa el entrevistador
- Presentar una dependencia concreta, evidencia del hallazgo, impacto y cronograma.
- Separar hechos, suposiciones y los peores escenarios en lugar de bloquear un lanzamiento por instinto.
- Ofrecer alternativas y puntos de decisión explícitos (decision gates).
- Involucrar al equipo del que se depende y asumir la comunicación del impacto en el negocio.
- Mostrar resultados medidos, controles duraderos y aprendizajes personales.
- Admitir aspectos desconocidos y evitar exagerar la contribución individual durante las preguntas de seguimiento.
Estructura para una respuesta de 30 segundos
“Antes del lanzamiento, encontré evidencia de que la funcionalidad dependía de un lote no documentado o de un cambio de permisos. Utilicé registros, un grafo de llamadas y una prueba con poco tráfico para confirmar el impacto, y luego separé el riesgo bloqueante del aceptable. Le di al equipo dos opciones: retrasar para solucionar la dependencia o deshabilitar la ruta de alto riesgo y realizar un despliegue por fases. Elegimos en función de un criterio de decisión explícito y comuniqué el nuevo cronograma a producto y operaciones. Posteriormente, agregué un registro de dependencias, comprobaciones y monitoreo, para que los lanzamientos futuros fueran más predecibles”.
Análisis detallado paso a paso
Paso 1: Nombrar la dependencia oculta
No te limites a decir que encontraste “un riesgo”. Nombra el objeto, el plan original, el momento del hallazgo y la evidencia: quizás una instantánea (snapshot) de permisos generada por otro equipo o un backfill que cambia el valor predeterminado de un campo nuevo. El cronograma explica por qué no estaba en el plan.
Paso 2: Verificar el impacto en lugar de suponer
Utiliza un grafo de llamadas, registros, configuración, muestras de datos o un ensayo a pequeña escala para confirmar la dependencia. Estima los usuarios afectados, la proporción de solicitudes, la dificultad de reversión (rollback) y la ventana de detección. Anota las incógnitas en lugar de utilizar un único peor escenario no verificado para exigir un retraso indefinido.
Paso 3: Presentar opciones comparables
Ofrece al menos continuar con el lanzamiento, retrasar para corregir, deshabilitar la funcionalidad o realizar un despliegue gradual. Señala el riesgo, costo, tiempo y reversibilidad de cada opción, con un criterio de control (gate) como “la coherencia de permisos pasa la validación y la tasa de rechazo se mantiene normal”. De este modo, la discusión se centra en la evidencia y las opciones en lugar de discusiones acaloradas.
Paso 4: Influir en las partes interesadas
Confirma el estado de entrega con el equipo del que dependes, explica el impacto en los usuarios y el nuevo cronograma a producto y operaciones, e instruye al personal de guardia (on-call) sobre el monitoreo y la reversión. Mantén un registro de decisiones breve con hechos, opciones, responsables, plazos y mecanismos de escalamiento. Comunica tú mismo las malas noticias en lugar de culpar a otro equipo.
Paso 5: Ejecutar un lanzamiento reversible
Para un despliegue por fases, verifica la dependencia, habilita un flag, limita los inquilinos (tenants) o regiones y supervisa errores, denegaciones de permisos, actualización de datos y señales de reversión. Cada fase debe tener condiciones para continuar, pausar o revertir. Si optas por retrasar, conserva el trabajo completado y las nuevas comprobaciones para que el siguiente intento no empiece desde la misma incertidumbre.
Paso 6: Revisar y modificar el sistema
Proporciona cifras: duración del retraso, tráfico cubierto, qué se previno o descubrió y el impacto en los clientes. Genera un registro de dependencias, una lista de verificación de lanzamiento, pruebas de contrato, un responsable o recordatorios. “Tener más cuidado” no cambia el sistema. Explica qué suposición resultó errónea más adelante y cómo la corregiste.
Compensaciones, límites y ganancia de información
El valor de esta pregunta radica en mostrar cómo un riesgo vago se convierte en una decisión compartida. Una respuesta sólida no califica el retraso como un éxito ni el lanzamiento a tiempo como el único objetivo; compara opciones reversibles con evidencia, asume explícitamente el impacto y reduce la dependencia de la memoria individual para la próxima vez.
Modelo de respuesta de alta calidad
“Antes de una migración de permisos, descubrí que el nuevo servicio aún dependía de una instantánea de roles generada diariamente por el sistema anterior, aunque la lista de verificación de lanzamiento no lo mencionaba. Un grafo de llamadas y registros muestreados mostraron que alrededor del 18% de las solicitudes administrativas leían la instantánea, por lo que la migración podría generar denegaciones erróneas. También verifiqué que una reversión del código no podría restaurar las nuevas escrituras de permisos.
Presenté tres opciones: retrasar dos días para la validación de doble escritura (dual-write), deshabilitar las acciones administrativas de alto riesgo y lanzar en modo canary al 5% de los inquilinos, o lanzar por completo. Junto con el equipo de la dependencia, el product owner y el ingeniero de guardia, establecí la consistencia de la instantánea y una tasa de rechazo normal como criterio de control para la expansión. Elegimos la opción canary y publicamos el cronograma revisado.
Las denegaciones se mantuvieron en el nivel de referencia y no hubo incidentes que afectaran a los clientes. Después de completar la validación de doble escritura, ampliamos el despliegue. En la revisión posterior, agregamos un registro de dependencias entre servicios, pruebas de contrato de permisos y muestreo previo al lanzamiento. Mi contribución consistió en encontrar la evidencia, estructurar las opciones e impulsar el registro, sin atribuirme el trabajo de otro equipo”.
Errores comunes
- Decir únicamente “Detuve el lanzamiento” → sin evidencia ni alternativas → explica la validación, los criterios de control y la reversibilidad.
- Culpar al otro equipo por el retraso → falta de sentido de propiedad → confirmen los hechos juntos y asume la comunicación del cronograma.
- Utilizar el peor escenario para inflar el impacto → las opciones no se pueden comparar → cuantifica la probabilidad, el alcance y el costo de la reversión.
- Hablar únicamente de entregar a tiempo → los incidentes posteriores quedan ocultos → muestra resultados y el impacto en el cliente.
- Concluir la revisión con “comunicarnos mejor” → el sistema sigue igual → agrega un contrato, una lista de verificación, monitoreo o un responsable.
- Afirmar haber hecho todo el trabajo → los hechos intergrupales pierden credibilidad → declara tu juicio, colaboración y límites.
Preguntas de seguimiento y respuestas
¿Qué pasa si el product owner insiste en la fecha de lanzamiento original?
Explica el alcance, la probabilidad, el costo de reversión y la observabilidad; luego ofrece un despliegue canary mínimo y reversible con un criterio de detención. Si la decisión sigue siendo lanzar, registra al responsable, el monitoreo y el plan de reversión en lugar de discutir indefinidamente.
¿Cómo demuestras que la dependencia estaba oculta?
Muestra el plan original, la documentación actual, la evidencia de llamadas o datos y la entrega que no se le había solicitado al equipo del que se dependía. Si existía una pista y no la viste, enfócate en corregir el proceso de descubrimiento.
¿Qué pasa si tu evaluación de riesgos fue incorrecta?
Nombra la suposición que la nueva evidencia refutó, el retraso o costo que causó y el paso de validación que modificaste. Corregir un juicio demuestra más madurez que defenderlo.
¿Cómo evitas que el próximo lanzamiento dependa de la memoria?
Incluye la dependencia en un contrato o registro legible por máquina, agrega pruebas de contrato, una lista de verificación con responsables asignados, recordatorios de expiración y métricas en tiempo de ejecución; luego ensaya que cualquier falla bloquee o revierta el despliegue.