El senior engineer que desarrolla al junior: las sesiones de pair programming, el code review como herramienta de enseñanza y el proceso de dar autonomía progresiva sin soltar demasiado pronto.
Cuándo usarlo: Desarrollar un sistema de mentoring técnico que acelere el crecimiento del developer junior
Herramienta recomendada: Claude
Actúa como un senior engineer con experiencia mentoreando a developers juniors en equipos de product engineering, que ha pensado profundamente en qué hace que un junior se convierta en un mid-level engineer rápidamente y qué lo mantiene estancado. Voy a explorar contigo el tech mentorship como práctica sistemática. Mi contexto: [describe tu situación: eres un senior engineer, tech lead o engineering manager que tiene a su cargo el desarrollo de un junior o de varios; el stack tecnológico y el tipo de trabajo que hace el mentee] Trabaja conmigo en profundidad los siguientes bloques: **1. El diagnóstico del junior: dónde está y adónde va** No todos los juniors tienen las mismas brechas. Explícame cómo hacer el diagnóstico inicial del developer junior: la evaluación técnica (qué conceptos tiene sólidos vs. cuáles son frágiles, dónde aplica patrones memorizados sin entenderlos), la evaluación de los hábitos de trabajo (cómo hace debugging, cómo gestiona la incertidumbre, cuánto tarda en pedir ayuda), y la evaluación de las habilidades blandas (comunicación en el equipo, capacidad de dar y recibir feedback de código). Dame las preguntas técnicas y de proceso que usarías en la primera sesión de diagnóstico con un junior developer. **2. El pair programming como herramienta de enseñanza** El pair programming con el mentor es una de las formas más efectivas de transferir conocimiento. Explícame cómo estructurar las sesiones de pair programming para que sean una herramienta de desarrollo y no solo una forma de que el senior haga el trabajo del junior: cuándo el senior conduce y cuándo el junior conduce (y cómo el senior navega cuando el junior conduce de forma ineficiente), las preguntas que el mentor hace mientras programa para desarrollar el pensamiento del junior, y cómo elegir las tareas correctas para las sesiones de pair. Dame un protocolo para una sesión de pair programming de una hora orientada al desarrollo del junior. **3. El code review como feedback de desarrollo** El code review es una de las herramientas de mentoring más infrautilizadas. Explícame la diferencia entre el code review que solo busca errores y el que desarrolla al junior: cómo dar feedback en el PR que explica el por qué (no solo el qué cambiar), cómo calibrar el nivel del feedback según el momento del junior (no dar 20 comentarios cuando está aprendiendo a estructurar el código), la diferencia entre los comentarios que son obligatorios, los que son sugerencias y los que son aprendizaje para el futuro, y cómo hacer que el junior cierre el ciclo de aprendizaje de cada PR. Dame ejemplos de comentarios de code review: la versión que solo corrige y la versión que enseña. **4. La autonomía progresiva: dar responsabilidad sin soltar demasiado pronto** El mayor reto del mentoring técnico es saber cuándo el junior está listo para trabajar solo. Explícame cómo gestionar la autonomía progresiva: las fases (pair completo → pair con el junior liderando → trabajo autónomo con check-ins → revisión solo al final), los indicadores de que el junior está listo para más autonomía (hace las preguntas correctas, detecta sus propios errores, explica su razonamiento), y las señales de que se le ha dado demasiada autonomía demasiado pronto (patrones de bloqueo silencioso, soluciones que funcionan pero que no son sostenibles). **5. Las conversaciones de desarrollo técnico** El mentoring no ocurre solo en el código: ocurre en las conversaciones. Explícame qué conversaciones tiene regularmente el mentor técnico con el junior: el check-in semanal de desarrollo (qué aprendiste esta semana, qué te bloqueó, qué quieres aprender), las conversaciones de carrera (dónde quiere estar en dos años, qué tipo de engineer quiere ser), y las conversaciones difíciles cuando el junior está cometiendo errores de comportamiento (no pide ayuda cuando se bloquea, hace estimaciones irreales, entrega sin testear). Dame el protocolo de la 1:1 de desarrollo para un junior engineer. **6. Construir el pensamiento de ingeniero, no solo las habilidades técnicas** La diferencia entre un buen junior y un buen mid-level engineer es el pensamiento de ingeniería: la capacidad de entender los trade-offs, de hacer las preguntas correctas antes de codificar, y de pensar en el mantenimiento además de en la funcionalidad. Explícame cómo el mentor desarrolla este pensamiento: los ejercicios de diseño de sistemas simplificados que desarrollan el pensamiento arquitectónico, las conversaciones sobre los por qué de las decisiones técnicas del codebase existente, y cómo enseñar al junior a leer código ajeno como una fuente de aprendizaje. Quiero técnicas concretas, protocolos de sesión y ejemplos reales de feedback técnico que pueda aplicar directamente con mi mentee.