Planteamiento y contexto
Cuéntame sobre una ocasión en la que descubriste un error tuyo o de tu equipo, lo reportaste y limitaste el impacto antes de que se convirtiera en un incidente. Explica cómo evaluaste la gravedad, a quién notificaste, qué hiciste y cómo evitaste que volviera a ocurrir.
El material oficial de preparación para entrevistas de Amazon recomienda STAR para las respuestas conductuales: describe la situación específica, la tarea, la acción y el resultado, incluyendo datos cuando corresponda. Sus Leadership Principles enfatizan Ownership, Customer Obsession, Are Right, A Lot y Learn and Be Curious. Esta pregunta evalúa el control responsable del riesgo respaldado con evidencia; no premia fingir que nunca has cometido un error.
Qué evalúa el entrevistador
El entrevistador busca que el error, el momento del descubrimiento y el límite del impacto sean explícitos; que los usuarios y los sistemas queden protegidos antes de debatir culpas; una escalación oportuna basada en hechos; una brecha de proceso clara sin buscar chivos expiatorios; y números junto con un mecanismo de seguimiento que demuestren el aprendizaje.
Preguntas para clarificar
Límite del incidente
Identifica si el error ocurrió en el código, la configuración, los datos, la comunicación o una decisión; qué sucedió realmente frente a lo que solo era una posibilidad; y si hubo datos de clientes, seguridad, cumplimiento normativo o pagos involucrados.
Tu responsabilidad
Indica si tú causaste el error, si lo encontraste en una revisión, si respondiste durante una guardia (on-call) o si eras el responsable del proyecto. No te atribuyas el resultado de todo el equipo como propio ni ocultes tu responsabilidad personal detrás del uso de "nosotros".
Evidencia divulgable
Prepara la cronología, el volumen afectado, la señal de detección, la acción de contención, los destinatarios notificados y las métricas posteriores a la corrección, omitiendo secretos comerciales y datos personales.
Respuesta de 30 segundos
"Durante una verificación previa al lanzamiento, detecté que mi cambio de configuración enviaría aproximadamente el X% de las solicitudes por una ruta incorrecta. Mi tarea era proteger a los usuarios y restaurar el comportamiento correcto. Pausé el lanzamiento, realicé un rollback, confirmé el alcance en los registros y reporté los hechos, el impacto y las incógnitas al líder de guardia y al contacto de producto. Luego agregué una validación previa (preflight check) y un flag escalonado, y observé cómo la tasa de errores se redujo de A a B durante dos semanas. El punto clave es la escalación temprana y un control medible, no calificar el error como algo fortuito".
Solución paso a paso
Paso 1: Describe el error con hechos
Proporciona la hora del incidente, el comportamiento esperado, el comportamiento real y el método de detección. Comienza con una señal reproducible, como una prueba fallida, una anomalía en las métricas o un hallazgo en la revisión de código, no con emociones ni culpas.
Paso 2: Evalúa la gravedad
Clasifica el impacto en los usuarios, el riesgo para los datos, la reversibilidad y la velocidad de propagación. Si se desconoce el impacto, señala la incógnita y aplica medidas de contención conservadoras en lugar de esperar a tener información perfecta antes de escalar.
Paso 3: Contén antes de investigar
Pausa el lanzamiento, realiza un rollback, deshabilita un flag, aísla una cola o limita el tráfico mediante la acción reversible más pequeña posible. Registra la hora y el responsable para que las correcciones en paralelo no borren la evidencia.
Paso 4: Escala y comunícate directamente
Informa a las personas que pueden mitigar el riesgo: hechos actuales, impacto conocido, impacto desconocido, acciones tomadas y la hora de la próxima actualización. Con clientes o equipos asociados, evita hacer afirmaciones excesivas mientras comunicas el impacto confirmado.
Paso 5: Corrige y verifica
Confirma la corrección mediante pruebas de reproducción o de regresión y luego restaura el tráfico gradualmente. Compara la tasa de errores, la latencia, la conversión o las métricas de integridad de datos y proporciona una línea base, el resultado y la ventana de observación.
Paso 6: Corrige el proceso, no solo el código
Transforma la causa raíz en un control ejecutable: validación previa (preflight validation), regla estática, revisión por dos personas, lanzamiento escalonado, rollback automático o una alerta. Asigna un responsable y una fecha límite; "tener más cuidado" no es un plan de acción.
Paso 7: Reflexiona delimitando responsabilidades
Indica qué decisiones mantendrías, qué comportamiento cambiarías y qué información no puede divulgarse. Asumir la responsabilidad no significa aceptar consecuencias fuera de tu rol ni culpar a un colega sin evidencia.
Respuesta modelo
Antes de un lanzamiento, descubrí que mi configuración de rutas omitiría la caché para aproximadamente el 8% de las solicitudes. Como aún no había quejas, pausé el lanzamiento, hice un rollback, confirmé el alcance en los registros de acceso y envié los hechos, las incógnitas y la hora de la próxima actualización al líder de guardia y al contacto de producto. Añadí validaciones previas de configuración, un flag escalonado del 5% al 25% y un umbral de rollback automático. A lo largo de dos semanas, la tasa de aciertos de caché (cache hit rate) se recuperó y los errores relacionados cayeron del 1.6% al 0.2%. La revisión posterior mostró que los datos de prueba omitían la ruta heredada; añadí cobertura de pruebas y un elemento a la lista de verificación previa al despliegue. Esto demuestra Ownership: reportar a tiempo, proteger a los usuarios y reducir la recurrencia mediante un control medible.
Errores comunes
- Error: Calificarlo como "el problema del equipo". → Por qué falla: El entrevistador no puede ver tu responsabilidad ni tu intervención. → Solución: Declara tu decisión, la evidencia y el límite de tu responsabilidad.
- Error: Esperar a notificar hasta conocer la causa raíz exacta. → Por qué falla: El impacto puede propagarse durante la espera. → Solución: Reporta primero los hechos y la incertidumbre; luego investiga en paralelo.
- Error: Describir el rollback sin números. → Por qué falla: No se demuestra la efectividad de la contención. → Solución: Proporciona el volumen afectado, la métrica de recuperación y la ventana de observación.
- Error: Concluir con "tener más cuidado". → Por qué falla: No existe una medida de prevención comprobable. → Solución: Agrega una validación previa, un despliegue escalonado, una alerta o un rollback automático.
Preguntas de seguimiento y respuestas
¿Por qué no lo detectaste antes?
Indica la señal faltante o la falta de cobertura, describe lo que añadiste y muestra su resultado en lanzamientos posteriores. No culpes al equipo de pruebas ni a una etiqueta de proceso abstracta.
¿Qué hubieras hecho si el responsable no quería escalar?
Utiliza el nivel de gravedad y las reglas de guardia (on-call) para escalar. Comunica los hechos, el riesgo y una propuesta de acción sin convertir el desacuerdo en un conflicto personal; utiliza un canal formal si se trata de temas de seguridad o cumplimiento normativo.
¿Cómo demostraste que la corrección no generó un nuevo problema?
Ejecuta pruebas de regresión y verificaciones con tráfico reducido, compara las métricas de errores, latencia y de negocio, define umbrales de detención y rollback, y mantén una ventana de observación.
¿Qué cambió a raíz de esta experiencia?
Menciona un control concreto, como una regla de validación previa, un despliegue escalonado, un umbral de alerta o un seguimiento de revisión, con un responsable, una fecha límite y una métrica. "Aprendí a comunicarme mejor" no es suficiente.