¿Cómo mentorizas a ingenieros móviles junior en tu equipo?

#Qué está preguntando realmente esta pregunta

A los entrevistadores rara vez les importa si "haces 1:1s" — casi cualquier candidato dice eso. Lo que distingue una respuesta senior es mostrar que tienes un modelo de mentoría real: cómo diagnosticas una brecha antes de recetar trabajo, cómo dejas que alguien falle sin dejar que falle de forma peligrosa, y cómo sabrías seis meses después si funcionó. Ancla tu respuesta en un ingeniero concreto, una brecha concreta y un resultado concreto y verificable — no una filosofía de mentoría en abstracto.

#Diagnostica antes de recetar

Empieza por evaluar, no por actuar. Antes de asignar cualquier cosa, intento ubicar a un ingeniero junior en tres ejes: fundamentos de plataforma (¿tiene un modelo mental real del hilo principal, el ciclo de vida de las vistas, la propiedad de memoria — o está reconociendo patrones de Stack Overflow?), criterio de producto (¿puede convertir un ticket de dos líneas en los casos borde que nadie escribió?) y hábitos de colaboración (¿avisa de un bloqueo el primer día, o desaparece dos días y aparece con lo que no era?). Un ingeniero al que mentoricé dominaba la sintaxis de Swift pero seguía provocando ciclos de retención en closures — eso no es descuido, es un modelo mental ausente de ARC, y cambia lo que le doy después: no "ten más cuidado", sino una sesión en pareja reconstruyendo en una pizarra el grafo de propiedad de una pantalla.

#El modelo de "reto con red de seguridad"

El crecimiento real necesita trabajo de producción real, un escalón por encima de la zona de confort, con una red de seguridad explícita debajo. En concreto: acordar el enfoque de diseño en pareja antes de escribir código, revisar el diff en dos pasadas separadas — primero arquitectura, después detalles menores, nunca mezcladas — y acordar un plan de rollback antes de que se integre. Tuve a un ingeniero de nivel medio liderar la migración de un módulo de RxJava a coroutines y Flow: suficientemente grande como para ser propiedad real con su nombre en el documento de diseño, suficientemente acotado — un módulo, detrás de un flag — para que un error costara un revert, no una alerta a las 2am.

#El code review como espacio de enseñanza, no como filtro

Separa los comentarios de "arregla esta línea" de los comentarios de "así es el concepto", y cuando algo se repite, saca la idea de fondo fuera del diff por completo. Un ingeniero de mi equipo seguía haciendo decodificación de bitmaps y trabajo de layout dentro de RecyclerView.onBindViewHolder — en vez de marcarlo PR tras PR, expliqué una sola vez la matemática del presupuesto de frame (16ms a 60fps, qué pasa cuando lo excedes, por qué es invisible en un emulador y evidente en un teléfono de tres años), y esa clase entera de bug dejó de aparecer en sus diffs.

#Dejar espacio para fallar de forma segura

La señal que escuchan los entrevistadores senior aquí es si has dejado deliberadamente que alguien cometa un error recuperable, porque un error que uno mismo descubre enseña más que uno que le cuentan a uno. Dejé que el diseño de un mentorizado llegara a la revisión de equipo con un fallo que yo ya había visto, específicamente para que el proceso de revisión — no yo — lo detectara, y después hicimos un debrief sobre cómo detectarlo ellos mismos la próxima vez. Eso es delegar autoridad en el proceso, no enrutar cada decisión a través de ti como único punto de control de calidad.

#Medirlo en vez de solo afirmarlo

Conecta la historia con señales que puedas señalar un trimestre después: el tiempo de respuesta en revisiones bajando, el volumen de comentarios de "por qué" en sus PRs reduciéndose y — la señal real — que empiecen a dejar comentarios sustanciales en el código de otras personas, o a presentar ellos mismos su documento de diseño en la revisión en vez de que lo presentes tú. Esa es la mitad de "resultado" de la historia; no dejes que la respuesta termine en la intervención.