Consigna
Cuéntame sobre una ocasión en la que guiaste a un compañero de equipo en su primer cambio en producción. Explica cómo identificaste los objetivos de aprendizaje, desglosaste el riesgo, organizaste la revisión, delegaste progresivamente y mediste tanto la entrega como el desarrollo de capacidades.
Escenario y límites
Utiliza un servicio real, el alcance del cambio, la experiencia faltante y la ventana de lanzamiento. Es posible que hayas sido un mentor formal, un revisor o un compañero temporal, pero completar el trabajo en lugar de la otra persona no es un resultado de mentoría.
Qué evalúa esto
La prueba consiste en transformar la ayuda, pasando de dar respuestas a desarrollar capacidades. La guía de revisión de código de Google trata la enseñanza como una función de revisión importante; la mentoría en GitLab enfatiza la programación en parejas (pairing), los objetivos y la retroalimentación continua. Las respuestas sólidas protegen la producción mientras preservan el espacio de decisión del aprendiz.
Estructura de respuesta de referencia
Usa STAR-L: Situación (Situation) detalla el contexto del cambio y del aprendizaje; Tarea (Task) establece el resultado del servicio y el límite de la mentoría; Acción (Action) cubre la descomposición compartida, la preparación de rollbacks, los pasos de revisión pequeños, la observación y la propiedad progresiva; Resultado (Result) ofrece evidencia sobre el lanzamiento, incidentes, tiempos de entrega y capacidades; Aprendizaje (Learning) explica cómo cambió tu forma de hacer coaching.
Detalles críticos
Menciona medidas de protección como validaciones previas a producción, aprobación por dos personas, tamaño del canary, monitoreo y simulacros de rollback. Especifica qué decisiones tomó el compañero de equipo. Mide los cambios independientes, la reducción de ciclos de revisión, la confianza durante la guardia (on-call) o mentorías posteriores, en lugar de decir únicamente que la relación mejoró.
Errores comunes
Escribir el código en lugar del compañero de equipo; centrarse únicamente en sus debilidades; omitir las medidas de protección bajo presión; atribuirte el éxito como propio; omitir cómo la retroalimentación cambió el comportamiento; o retratar la mentoría como órdenes unidireccionales.
Rúbrica de evaluación
Las respuestas sólidas incluyen objetivos de aprendizaje, delegación progresiva, medidas de protección y resultados verificables. Explican cuándo interviniste, cuándo diste un paso atrás y cómo el conocimiento se integró en la documentación o en la práctica del equipo. Las respuestas débiles describen una sola sesión de pairing sin desarrollo de capacidades.
Preguntas de seguimiento
¿Qué pasa si el compañero de equipo insiste en un diseño que consideras riesgoso?
Escriban juntos los supuestos, los riesgos y la validación, y ejecuten el experimento reversible más pequeño posible. Si excede la autoridad o el presupuesto de riesgo, utiliza la vía de revisión del equipo en lugar de reemplazar el diseño silenciosamente.
¿Cómo sabes cuándo es el momento de dar un paso atrás?
Observa si el compañero de equipo puede explicar el diseño, elegir métricas, ejecutar un rollback y responder a anomalías. Permítele liderar varios pasos de bajo riesgo y luego reduce tus aprobaciones y recordatorios.
¿Cómo afectó la mentoría al equipo?
Convierte las preguntas recurrentes en un runbook, lista de verificación o plantilla de revisión, invita al compañero a mejorarla y haz un seguimiento de si los cambios posteriores son más rápidos, más seguros o requieren menos ayuda repetitiva.