The final chapter of this series: typical React Native interview questions for advanced-level positions – EVERY answer points back to the chapter where we worked through that topic PRACTICALLY on our own project.

"Explain the difference between the old bridge and JSI"

The old bridge: JSON serialization on EVERY call, ALWAYS asynchronous, all modules loaded at startup. JSI: direct, synchronous C++ object access, modules loaded LAZILY. A STRONG answer gives a concrete example of why this matters (e.g. Reanimated, which needs to communicate synchronously with the UI thread). Deep dive: chapter 8.

"What is Fabric?"

The JSI-based reimplementation of the rendering system – enables synchronous layout measurements, the shadow tree lives directly in C++ instead of as a copy synchronized over the bridge. Deep dive: chapter 8.

"What does Hermes do differently from other JS engines?"

Hermes compiles JavaScript to bytecode ALREADY at build time, not at app start – saves parse time at (especially critical for mobile apps) cold start. Downside: the bytecode itself tends to be larger than minified JS source text. Deep dive: chapter 6.

"What is a worklet in Reanimated?"

A JavaScript function that, thanks to JSI, gets copied to the UI thread and executed there – keeps running unaffected even when the JS thread is blocked. A convincing answer mentions runOnJS() as its counterpart: the way to switch back to the JS thread from INSIDE a worklet. Deep dive: chapters 9-10.

"How do you optimize a slow FlatList?"

• Apply React.memo to the item component AND make sure its props (especially callback props) actually stay stable.
• Provide getItemLayout when item height is fixed, to skip layout calculations.
• Fine-tune windowSize/maxToRenderPerBatch, based on actual profiler measurements.
• For TRULY long lists (hundreds/thousands of entries): consider @shopify/flash-list as an alternative.

Deep dive: chapter 5, with the profiler tool from chapter 4 for measuring BEFORE optimizing.

"Zustand or Redux Toolkit in React Native – any differences from the web?"

Same core principle as on the web (selective subscriptions instead of context-wide re-renders), BUT an RN-specific detail: Zustand's persist middleware explicitly needs createJSONStorage(() => AsyncStorage), since RN has no localStorage (unlike the default web case). Redux Toolkit's persistence equivalent (redux-persist) is a SEPARATE library, not a built-in feature. Deep dive: chapters 2-3.

"When do you write your own native module?"

Only when: (1) a platform-specific SDK exists with no ready-made JS wrapper, (2) extremely performance-critical code is better placed directly in Swift/Kotlin, or (3) native behavior is needed that React Native doesn't expose. For the vast majority of cases, a ready-made community/Expo library already exists. Deep dive: chapter 11.

"What are over-the-air updates, and what can they NOT do?"

Distributing new JavaScript/asset code to already-installed apps WITHOUT a store review. Do NOT work for changes to native code (new native libraries need a fresh store build) and, per Apple's guidelines, must not be used to change core functionality without review. Deep dive: chapter 17.

Bonus: rebuilding a typical live-coding exercise yourself

A common task in advanced-level interviews: "Build a list where you can delete an item by swiping, with a smooth animation." You built exactly that in chapter 10 (swipe-to-delete with Gesture Handler + Reanimated). Practice rewriting SwipeableCartItem from memory WITHOUT looking it up (the structure of the gesture/animation logic, not word-for-word) – realistic preparation for a live-coding interview.

That wraps up "React Native for Professionals" – from the limits of local hooks, through state management libraries, performance tools, the new architecture, TypeScript integration, all the way to testing, deployment, and interview readiness, all worked out directly on the same, continuous produktkatalog-app that began with "React Native for Beginners". Congratulations!