Senior React Native Developer — Preguntas de entrevista React Native

Explica Fabric y TurboModules como sistema, no solo como definiciones.

Fabric es el nuevo renderer: mueve el layout y la gestión de vistas a un núcleo en C++ compartido entre plataformas, así que JS describe el árbol vía JSI directamente en ese núcleo en vez de pasar por las llamadas asíncronas al UIManager del bridge, y habilita medición de layout síncrona que la arquitectura vieja no podía hacer sin un round trip. Los TurboModules son el equivalente para módulos nativos — se cargan de forma perezosa (un módulo no se instancia hasta el primer uso, recortando el costo de arranque) e se invocan vía los bindings directos en C++ de JSI en vez del ciclo serializar-encolar-deserializar del bridge. Juntos eliminan el bridge como el único cuello de botella de serialización, que era lo que ponía el techo de la arquitectura vieja tanto en tiempo de arranque como en throughput del hilo de UI.

¿Cómo planificas una migración de la arquitectura vieja a la New Architecture en una app en producción?

Empieza con una auditoría de cada módulo nativo y dependencia de terceros — el mayor riesgo no está en tu propio código, sino en si las librerías de las que dependes ya soportan la New Architecture, porque un módulo nativo sin mantenimiento puede bloquear toda la migración. Activa el modo interop donde el framework permita correr módulos de la arquitectura vieja bajo Fabric/TurboModules, migra incrementalmente pantalla por pantalla o feature por feature en vez de voltear un switch global de golpe, y presupuesta tiempo real de QA porque diferencias sutiles de comportamiento (timing de layout, orden de eventos) aparecen solo bajo carga, no en un smoke test rápido. Trátalo como un proyecto de infraestructura de varios sprints con su propio plan de rollback, no como un bump de versión.

¿Cómo perfilas un problema de rendimiento que no es visible desde el lado JS?

Empieza aislando si el problema está en el hilo JS, el hilo de UI nativo, o trabajo nativo real (decodificación de imágenes, llamadas a módulos nativos) — el profiler de JS en Flipper solo te muestra lo primero. Las herramientas del lado nativo (Time Profiler de Xcode Instruments en iOS, el profiler de Android Studio en Android) muestran dónde el hilo nativo realmente gasta tiempo, que es donde aparecen problemas como una jerarquía de vistas demasiado profunda, decodificación de imágenes sin optimizar, o un módulo nativo hablador. El hilo JS y el hilo de UI corren independientemente pero se bloquean mutuamente en puntos como layout y animación, así que "JS es rápido" y "la app va fluida" son afirmaciones separadas que hay que verificar por separado.

Eres responsable del release y rollout en un equipo mobile en crecimiento — ¿qué implica eso en la práctica?

Un pipeline de CI/CD (Fastlane, EAS Build o Bitrise) que produce builds firmados y versionados sin que una persona corra Xcode o Android Studio a mano, feature flags para que una feature rota pueda apagarse sin un release de emergencia a la store, y un rollout escalonado (basado en porcentaje en Play Store, grupos de TestFlight en iOS) para que un build malo llegue a un 5% de usuarios antes que al 100%. También significa ser dueño de la política OTA-vs-release-nativo — decidir qué es seguro lanzar al instante y qué necesita el ciclo completo de revisión —, y asegurarte de que el crash reporting (Sentry, Bugsnag) esté conectado al commit y versión de bundle exactos, para que un pico sea rastreable hasta un release específico.

¿Cómo escalas una base de código de React Native y un equipo en crecimiento trabajando en ella al mismo tiempo?

Divide la app en módulos o un monorepo con límites de paquete claros (Nx, Turborepo, o un setup de workspace propio) para que los equipos sean dueños de una franja vertical en vez de que todos editen las mismas pantallas, y hazlo cumplir con reglas de lint o chequeos del grafo de dependencias en vez de solo con convención. Estandariza temprano las cosas que en la práctica causan más fricción entre equipos — estructura de navegación, elección de gestión de state, ownership de módulos nativos, componentes del design system —, porque retrofit-ear un estándar después de que cinco squads ya divergieron cuesta mucho más que establecerlo desde el principio. La parte de mentoría es menos sobre code review y más sobre hacer que la respuesta a "cómo hacemos X aquí" sea encontrable sin tener que preguntarle a un senior cada vez.