React Native Interview Questions — the bridge is dead and the bar moved

Your React Native app boots. Your Expo starter renders. You will still fail the loop if you cannot explain why the async bridge is gone and what replaced it.

The real question here is — which company is actually hiring you? Some treat React Native as "React that runs on phones." Others treat it as native engineering with a JavaScript front. The gap between those two interviews is the rest of this post.

If you came from the iOS guide or the Android guide, you know the three-bucket split already. React Native has a narrower surface, but the bar is higher on architecture. You are expected to understand both runtimes under the JS.

The React Native interview is a systems interview

Diagram

Copy source

Rendering diagram...

Discord, Shopify, Meta, and Microsoft all hire React Native engineers, and they all ask different things. Discord probes frame-level performance. Shopify probes offline-first and native hardware integration. Meta probes the framework itself — you are closer to the source than anywhere else.

What the interviewer is actually listening for is whether you know where the abstraction leaks. React Native looks like React until it does not. The moment you touch navigation, gesture handling, or a native module, you are in platform territory.

Same failure mode every time. A candidate builds five side projects in Expo, cannot debug a native crash, cannot explain why their FlatList stutters on Android but not iOS. That is a 2021 profile. In 2026, that is a no-hire.

Old bridge vs New Architecture

The old bridge was an async JSON-serialization pipe between the JS thread and the native thread. Every call crossed the pipe. Every response came back serialized. Nothing was synchronous. That is why old RN could never ship a 60fps gesture handler without dropping into native code.

JSI — the JavaScript Interface — replaces the pipe with direct C++ bindings. JS holds references to C++ objects and calls their methods synchronously, no serialization. Fabric is the new renderer built on top. It runs synchronous layout and unlocks React 18 concurrent features like Suspense and Transitions. TurboModules are native modules that load lazily and are type-safe by codegen from a TypeScript spec.

The strong answer walks the interviewer through a concrete scenario. A gesture handler that needs to respond to touch within a single frame cannot tolerate a bridge round-trip. JSI lets you call the native animation driver synchronously from JS. VisionCamera, the library cited in the official RN docs, processes roughly 2 GB of frame data per second through JSI — the bridge could never have carried that.

Performance — what interviewers actually probe

Hermes is the JS engine React Native ships by default. It compiles JS to bytecode (.hbc) at build time, which means faster startup, lower memory, and smaller app size compared to JavaScriptCore. Verify it is active with !!global.HermesInternal. That one-liner is a favorite phone-screen check.

Frame drops are the next probe. The JS thread runs your logic. The UI thread paints. If your JS thread blocks for 32 ms, you have dropped two frames and the screen stutters. useNativeDriver: true on animations moves them to the UI thread so a blocked JS thread cannot stall them. Reanimated 2 and 3 go further — worklets run actual JS on the UI thread, so animations are driven by logic, not just tweened values.

FlatList is the single most-asked optimization question. Discord's engineering blog describes their custom FastList implementation that reduced mounted views from roughly 2,000 to 400, hitting 10–30 ms renders versus the 100+ ms they saw with stock FlatList. The interview version is narrower — know getItemLayout, windowSize, removeClippedSubviews, and keyExtractor, and know why inline function={() => ...} on every row kills recycling.

Platform-specific code and native modules

React Native does not ship every native API. Camera, Bluetooth, custom UI, background tasks — you drop to native. The interview pattern is: "walk me through adding a native capability that does not have a community library."

The modern answer is a TurboModule. You write a TypeScript spec, Codegen generates the C++/Kotlin/Swift contract, and your Kotlin or Swift implementation conforms to it. No more NativeModules.X runtime lookup, no more stringly-typed method calls. The interviewer is listening for whether you know the spec-first flow, not whether you have memorized the boilerplate.

Microsoft's Office team calls their pattern "Content Islands" — React Native components embedded inside existing native apps, shipping more than 40 Office experiences from Privacy Dialog to the Accessibility Assistant to the Copilot UI. The lesson for interviews: RN at scale is not "rewrite the app in JS." It is "use JS where it speeds you up, keep native where it matters."

Codegen is the piece most candidates skip. Under the New Architecture, your TypeScript spec is the source of truth. The generated contract is what protects you from runtime type errors when the native side and JS side drift. If you cannot explain that flow, you are still thinking in old-bridge terms.

That same spec-level precision shows up in the classic LRU Cache prompt. You are proving that you can define the contract cleanly, keep the invariants tight, and avoid hand-waving when state starts moving.

State management and navigation

State management in RN is less dogmatic than the web. Zustand is the default for most new apps — small, no provider hell, plays well with async storage. Redux Toolkit still wins at scale when you need middleware, devtools, and a coordinated action log. Jotai fits apps where state is genuinely atomic and derivations matter more than a single store.

React Navigation is the interview default. Know the difference between a stack, a tab, and a drawer, and know how deep linking works on each platform — universal links on iOS, app links on Android, and the Linking API underneath. Offline-first is the other probe. AsyncStorage for small KV, MMKV when performance matters, WatermelonDB when you actually have a relational model.

Companies that ask React Native-specific questions

Discord rebuilt iOS on React Native with three core engineers, shipping a 4.8 App Store rating and 99.9% crash-free sessions. They probe Fabric migration, gesture handling, and frame-level debugging.

Shopify runs every mobile app — Shop, POS, Shopify, Inbox — on React Native. Shop and the old Arrive app hit 95% code sharing; Compass hits 99%. Shopify's engineering post cites sub-500 ms P75 screen load times and greater than 99.9% crash-free rates. They probe offline-first, native hardware modules (barcode scanners, receipt printers), and the "native and React Native" framing rather than "native or."

Meta is the source. You are interviewing with the team that wrote Fabric. They ask about the framework internals, not the consumer API.

Microsoft ships React Native across Office, Teams, and Outlook. They are the ones with the most public information on RN Windows — worth knowing if the role is cross-platform desktop as well as mobile.

The honest close

I have seen this go wrong dozens of times. A candidate ships impressive Expo side projects, cannot trace a crash past the red-screen overlay, cannot read a native stack trace, cannot explain why their animation works on iOS but judders on Android. That profile was fine in 2021. The bar moved.

The version that gets the offer knows where the abstraction leaks, knows why the bridge is gone, and can walk through a TurboModule spec without pulling up the docs. That is what makes you hireable in 2026.