Situación (15s): "Como Ingeniero Senior en la Empresa X, nuestra arquitectura de microservicios tenía un 47% de llamadas API fallidas durante el tráfico pico (5PM-7PM PST), afectando a 2.3M de usuarios activos diarios."

Tarea (15s): "Me asignaron reducir la tasa de fallo de API por debajo del 5% en 3 semanas, sin costos adicionales de infraestructura, mientras mentoreaba a 2 ingenieros junior en la solución."

Acción (60s): "Primero, analicé 14 días de logs de CloudWatch e identifiqué que el 83% de los fallos se originaban en un único servicio de perfil de usuario con consultas de base de datos ineficientes (problema N+1). Propuse implementar caché Redis con estrategia de 2 niveles: caché L1 (datos calientes, 5min TTL) y caché L2 (datos tibios, 30min TTL). Creé un plan de implementación detallado con 3 fases: (1) Agregar monitoreo con DataDog APM para rastrear tasas de acierto de caché, (2) Implementar capa de caché con mecanismos de respaldo, (3) Despliegue gradual usando feature flags. Mentoreé a los ingenieros junior haciendo que implementaran la capa de caché L2 mientras yo manejaba la capa crítica L1. Realizamos revisiones de código diarias y les enseñé cómo usar pipelining de Redis para reducir los viajes de red en un 73%. También creé documentación completa incluyendo diagramas de arquitectura, runbooks para escenarios de invalidación de caché y playbooks de guardia para el equipo."

Resultado (30s): "En 2 semanas, la tasa de fallo de API cayó del 47% al 1.2%, superando el objetivo del 5%. La latencia P95 mejoró de 2,300ms a 340ms. Esto aumentó directamente la participación de usuarios en un 23% y previno una pérdida estimada de $1.8M en ingresos anuales. Los ingenieros junior desplegaron exitosamente su primera función de producción, y la arquitectura de caché ahora se usa en otros 12 servicios. Presenté este caso de estudio en nuestra cumbre de ingeniería de toda la empresa (200+ asistentes)."

Puntuación del Entrevistador: 10/10

• ✅ Métricas específicas (47% → 1.2%, 2.3M usuarios, $1.8M impacto)
• ✅ Liderazgo demostrado (mentoría, documentación, compartir conocimiento)
• ✅ Profundidad técnica (Redis, estrategia de caché, feature flags)
• ✅ Impacto comercial claramente articulado
• ✅ Tiempo perfecto de 2 minutos

Situación (15s): "Durante un lanzamiento crítico de producto Q4 en la Empresa Y, nuestro PM quería lanzar un nuevo algoritmo de recomendación que yo creía tenía pruebas A/B insuficientes (solo 2 días, 5,000 usuarios vs. nuestro estándar de 7 días, 50,000 usuarios)."

Tarea (15s): "Necesitaba convencer al PM de extender las pruebas o asegurar salvaguardas adecuadas, mientras mantenía nuestro plazo de lanzamiento en 9 días y la moral del equipo alta."

Acción (60s): "En lugar de oponerme directamente al PM en nuestra reunión de planificación, solicité una reunión 1:1 para entender su perspectiva. Revelaron que existía presión ejecutiva debido al lanzamiento de un competidor. Propuse un compromiso basado en datos: analizaría los resultados de prueba de 2 días en profundidad y crearía una matriz de riesgo. Pasé 6 horas esa noche construyendo un dashboard mostrando: (1) La prueba actual solo tenía 67% de confianza estadística (vs. nuestro estándar del 95%), (2) El algoritmo mostraba un preocupante aumento del 12% en la tasa de rebote para usuarios móviles (43% de nuestro tráfico), (3) Impacto de ingresos proyectado: pérdida mensual potencial de $230K si el problema móvil persistía. Presenté esto al PM con 3 opciones: (A) Extender prueba 5 días más [Recomendado], (B) Lanzar con kill switch solo para móvil, (C) Lanzar solo escritorio primero. Enfaticé que apoyaba el lanzamiento y quería ayudarlos a tener éxito. El PM apreció el enfoque basado en datos y acordamos la Opción B. Implementé el kill switch en 1 día, y lo desplegamos con alertas de monitoreo vinculadas a umbrales de tasa de rebote."

Resultado (30s): "Lanzamos a tiempo. En 3 horas, el kill switch móvil se activó debido al aumento del 15% en tasa de rebote. Deshabilitamos el algoritmo móvil mientras manteníamos escritorio activo (8% aumento en participación). Esto previno la pérdida mensual de $230K. Trabajé con el PM durante la siguiente semana para arreglar el algoritmo móvil (el problema era conflicto de lazy-loading de imágenes). El PM luego me nominó para nuestro premio de valores de empresa, y establecimos una nueva política requiriendo 95% de confianza estadística para cambios de algoritmo. Nuestra relación laboral se volvió mucho más fuerte."

Puntuación del Entrevistador: 10/10