Senior React Native Developer — Perguntas de entrevista React Native

Explique o Fabric e os TurboModules como um sistema, não só como definições.

O Fabric é o novo renderer: ele move o layout e o gerenciamento de views para um núcleo em C++ compartilhado entre plataformas, então o JS descreve a árvore via JSI direto nesse núcleo em vez de passar pelas chamadas assíncronas do UIManager do bridge, e habilita medição síncrona de layout que a arquitetura antiga não conseguia fazer sem um round trip. Os TurboModules são o equivalente para módulos nativos — carregados de forma lazy (um módulo só é instanciado quando usado pela primeira vez, cortando custo de startup) e chamados via os bindings diretos em C++ do JSI em vez do ciclo serializar-enfileirar-desserializar do bridge. Juntos, eles removem o bridge como o único gargalo de serialização, que era o que limitava a arquitetura antiga tanto no tempo de startup quanto no throughput da thread de UI.

Como você planeja uma migração da arquitetura antiga para a New Architecture num app em produção?

Comece com uma auditoria de cada módulo nativo e dependência de terceiros — o maior risco não está no seu próprio código, mas em se as bibliotecas das quais você depende já lançaram suporte à New Architecture, porque um módulo nativo sem manutenção pode bloquear toda a migração. Ative o modo interop onde o framework permitir rodar módulos da arquitetura antiga sob Fabric/TurboModules, migre de forma incremental, tela por tela ou feature por feature, em vez de virar uma chave global de uma vez, e reserve tempo real de QA porque diferenças sutis de comportamento (timing de layout, ordem de eventos) só aparecem sob carga, não num smoke test rápido. Trate isso como um projeto de infraestrutura de vários sprints com seu próprio plano de rollback, não como um bump de versão.

Como você faz profiling de um problema de performance que não é visível pelo lado do JS?

Comece isolando se o problema está na thread de JS, na thread de UI nativa, ou em trabalho nativo de verdade (decodificação de imagem, chamadas a módulos nativos) — o profiler de JS no Flipper só mostra o primeiro caso. Ferramentas do lado nativo (Time Profiler do Xcode Instruments no iOS, o profiler do Android Studio no Android) mostram onde a thread nativa realmente gasta tempo, e é aí que aparecem problemas como uma hierarquia de views profunda demais, decodificação de imagem não otimizada, ou um módulo nativo tagarela. A thread de JS e a thread de UI rodam de forma independente mas se bloqueiam mutuamente em pontos como layout e animação, então "o JS é rápido" e "o app está fluido" são afirmações separadas que precisam ser verificadas cada uma por si.

Você é responsável pelo release e rollout num time mobile em crescimento — o que isso realmente envolve?

Um pipeline de CI/CD (Fastlane, EAS Build ou Bitrise) que produz builds assinados e versionados sem uma pessoa rodando Xcode ou Android Studio manualmente, feature flags para que uma feature quebrada possa ser desligada sem um release de emergência à store, e um rollout escalonado (baseado em porcentagem na Play Store, grupos de TestFlight no iOS) para que um build ruim chegue a 5% dos usuários antes de chegar a 100%. Também significa ser dono da política OTA-vs-release-nativo — decidir o que é seguro lançar instantaneamente e o que precisa do ciclo completo de revisão —, e garantir que o crash reporting (Sentry, Bugsnag) esteja conectado ao commit e à versão do bundle exatos, para que um pico seja rastreável até um release específico.

Como você escala uma base de código React Native e um time crescente trabalhando nela ao mesmo tempo?

Divida o app em módulos ou um monorepo com limites de pacote claros (Nx, Turborepo, ou uma configuração de workspace própria), para que os times sejam donos de uma fatia vertical em vez de todo mundo mexer nas mesmas telas, e reforce isso com regras de lint ou checagens do grafo de dependências em vez de só convenção. Padronize cedo as coisas que na prática causam mais atrito entre times — estrutura de navegação, escolha de gerenciamento de state, ownership de módulos nativos, componentes do design system —, porque adaptar um padrão depois que cinco squads já divergiram custa muito mais do que estabelecê-lo desde o início. A parte de mentoria é menos sobre code review e mais sobre fazer com que a resposta para "como a gente faz X aqui" seja fácil de encontrar sem precisar perguntar a um sênior toda vez.