Senior React Native Developer — React Native interview questions

Explain Fabric and TurboModules as a system, not just definitions.

Fabric is the new renderer: it moves layout and view management onto a C++ core shared across platforms, so JS describes the tree via JSI directly into that core instead of going through the bridge's async UIManager calls, and it enables synchronous layout measurement that the old architecture could not do without a round trip. TurboModules are the native-module equivalent — lazily loaded (a module is not instantiated until first used, cutting startup cost) and invoked through JSI's direct C++ bindings instead of the bridge's serialize-queue-deserialize cycle. Together they remove the bridge as the single serialization bottleneck, which is what made the old architecture's ceiling on both startup time and UI thread throughput hard to push past.

How do you plan a migration from the old architecture to the New Architecture on a production app?

Start with an audit of every native module and third-party dependency — the biggest risk is not your own code, it is whether the libraries you depend on have shipped New Architecture support, since an unmaintained native module can block the whole migration. Enable interop mode where the framework supports running old-architecture modules under Fabric/TurboModules, migrate incrementally screen by screen or feature by feature rather than flipping a global switch, and budget real QA time because subtle behavior differences (layout timing, event ordering) show up only under load, not in a quick smoke test. Treat it as a multi-sprint infrastructure project with its own rollback plan, not a version bump.

How do you profile a performance problem that is not visible from the JS side?

Start by isolating whether it is the JS thread, the native UI thread, or actual native work (image decoding, native module calls) — the JS profiler in Flipper only shows you the first of those. Native-side tools (Xcode Instruments' Time Profiler on iOS, Android Studio's profiler on Android) show where the native thread is actually spending time, which is where issues like excessive view hierarchy depth, unoptimized image decoding, or a chatty native module show up. The JS thread and UI thread run independently but block on each other at points like layout and animation, so "JS is fast" and "the app is smooth" are separate claims that both need verifying.

You are responsible for release and rollout across a growing mobile team — what does that actually involve?

A CI/CD pipeline (Fastlane, EAS Build, or Bitrise) that produces signed, versioned builds without a human running Xcode or Android Studio by hand, feature flags so a broken feature can be killed without an emergency store release, and a staged rollout (percentage-based on Play Store, TestFlight groups on iOS) so a bad build reaches 5% of users before 100%. It also means owning the OTA-vs-native-release policy — deciding what is safe to ship instantly and what needs the full review cycle — and making sure crash reporting (Sentry, Bugsnag) is wired to the exact commit and bundle version so a spike is traceable to a specific release.

How do you scale a React Native codebase and a growing team working in it at the same time?

Split the app into modules or a monorepo with clear package boundaries (Nx, Turborepo, or a custom workspace setup) so teams own a vertical slice instead of everyone editing the same screens, and enforce it with lint rules or dependency-graph checks rather than just convention. Standardize the things that cause the most cross-team friction in practice — navigation structure, state management choice, native module ownership, design system components — early, because retrofitting a standard after five squads have diverged costs far more than setting one. The mentoring part is less about code review and more about making the "how do we do X here" answer discoverable without asking a senior every time.