On this page
Most React Native interview question lists read like quizzes on framework documentation. "What is the Virtual DOM?" "Explain the component lifecycle." "What's the difference between state and props?" A candidate who memorized the docs for two days can answer all of these. A candidate who has shipped three production apps and debugged a Fabric threading issue at 2 AM can also answer them, but you've learned nothing about the gap between those two people.
The questions that actually reveal expertise test how a developer thinks through real problems, not what they can recite. They expose whether someone has built production apps or just tutorial projects, whether they understand why the framework works the way it does or just know which API to call, and whether they can diagnose problems they haven't seen before.
In this guide, we have compiled the interview questions that we ask at Softaims, also many FAANG companies, when hiring React Native developers. But this is not just a list of questions. We explain what each question is designed to evaluate, the engineering judgment or problem-solving ability it assesses, examples of strong vs. weak answers, and the seniority level for which each question is most relevant. The goal is to help you understand how experienced teams assess real React Native capability beyond memorized theory or surface-level knowledge.
How to Structure the Technical Interview
Before the questions, the format matters. A 4-hour whiteboard marathon testing algorithm trivia will tell you nothing about whether someone can ship a React Native app. Here's what works:
| Stage | Duration | Purpose |
|---|---|---|
| Screening call | 15 min | Verify experience, communication, logistics |
| Technical questions | 30-45 min | Test conceptual depth and diagnostic thinking |
| Live coding | 45-60 min | Watch them build something real |
| Portfolio review | 20-30 min | Examine shipped work and architectural decisions |
The questions below cover stage 2. For live coding tasks by seniority level and the full hiring process, see our step-by-step hiring guide.
Core Architecture Questions
These test whether the developer understands how React Native actually works under the hood, not just how to use it.
"Explain how React Native renders a component to a native view. What happens between your JSX and what the user sees on screen?"
Appropriate for: Mid-level and senior
What a strong answer includes: The developer explains that React Native doesn't render to a browser DOM. JSX gets compiled to React elements, which the reconciler processes into a tree of native view instructions. In the New Architecture, the Fabric renderer builds a shadow tree in C++ that calculates layout (using Yoga), then commits native view operations to the UI thread. They should mention that this is fundamentally different from Web React, where the output is HTML elements in a browser.
Red flag answer: "React Native converts JavaScript to native code." It doesn't. JavaScript runs in a JavaScript engine (Hermes), and native views are created separately. The bridge (old architecture) or JSI (new architecture) connects them. Candidates who think React Native "compiles to native" have a fundamental misconception about the framework.
"Walk me through the difference between a Native Module and a Turbo Module, and where JSI fits."
Appropriate for: Senior
What a strong answer includes: Native Modules used the old async bridge, serializing data as JSON between JS and native. Turbo Modules use JSI (JavaScript Interface) for synchronous, zero-copy communication. They're typed via Codegen specs, lazy-loaded instead of eagerly initialized, and don't require JSON serialization. JSI is the C++ layer that lets JavaScript hold direct references to native objects. The developer should be able to explain why this matters: faster startup (lazy loading), better performance (no serialization overhead), and type safety (Codegen catches errors at build time).
Red flag answer: A textbook definition that collapses when you ask, "Have you actually written a Turbo Module spec from a Codegen file?" About a third of senior candidates can't answer the initial question at all. Another third gives a surface-level answer. The third group, who can walk through the binding and the Codegen spec, is the one that can own a New Architecture migration.
"What is the Fabric renderer and how does it differ from the old rendering system?"
Appropriate for: Senior
What a strong answer includes: Fabric replaces the old rendering pipeline, in which the shadow tree was built in Java (Android) or Objective-C (iOS). In Fabric, the shadow tree is built in C++, which enables concurrent rendering (multiple trees can be prepared simultaneously) and synchronous layout measurement. This means components can be measured and laid out without async round-trips. The developer should connect this to practical impact: smoother animations, more responsive gesture handling, and the ability to interrupt and prioritize rendering work.
Red flag answer: "Fabric is the new architecture." That's too vague. Fabric is specifically the rendering system. The New Architecture also includes JSI and Turbo Modules. A candidate who conflates these three layers doesn't understand the architecture deeply enough for senior-level work.
State Management Questions
These reveal architectural thinking, not just API knowledge.
"You're building an app with user authentication, a product catalog that updates in real time, a shopping cart, and user preferences. Walk me through your state management strategy."
Appropriate for: Mid-level and senior
What a strong answer includes: Not everything belongs in one global store. Auth state (global, persisted) might use a lightweight solution like Zustand with persistence middleware. Product catalog (server state, frequently refreshed) belongs in React Query or TanStack Query, which handles caching, background refetching, and stale-while-revalidate automatically. Shopping cart (global, persisted, frequently modified) could use Zustand or Redux Toolkit depending on complexity. User preferences (local, persisted) might use MMKV or AsyncStorage directly.
The key signal is that they distinguish between server state and client state, and don't try to put everything in Redux.
Red flag answer: "I'd use Redux for everything." This was acceptable in 2020. In 2026, putting server state in Redux means writing boilerplate for caching, loading states, error handling, and refetching that React Query handles out of the box. A developer who defaults to Redux for everything hasn't kept up with the ecosystem.
"When would you use Context API vs Zustand vs Redux Toolkit? What are the performance implications of each?"
Appropriate for: Mid-level and senior
What a strong answer includes: Context API is built-in and works for low-frequency updates (theme, locale, auth status), but every consumer re-renders when any context value changes, which makes it problematic for high-frequency state. Zustand is lightweight, supports selectors (components only re-render when their selected slice changes), and has no boilerplate. Redux Toolkit is more structured and better for very large apps with complex state logic, middleware needs, and team conventions.
Red flag answer: "They're all the same, just different syntax." They're fundamentally different in how they trigger re-renders, and that difference determines app performance.
Performance and Debugging Questions
These separate developers who have shipped production apps from those who have only built tutorials.
"Your FlatList with 500+ items is janky on Android. Walk me through how you'd diagnose and fix it."
Appropriate for: All levels (depth of answer reveals seniority)
Junior answer (acceptable): Mentions using keyExtractor, checking that list items have a fixed height, and avoiding inline functions in renderItem.
Mid-level answer (good): Adds getItemLayout for fixed-height items to skip measurement, windowSize to control how many off-screen items are rendered, React.memo on the list item component to prevent unnecessary re-renders, removeClippedSubviews on Android, and checking for expensive operations inside renderItem.
Senior answer (great): Everything above, plus opens Flipper's performance monitor to check JS frame rate vs UI frame rate. If JS frames are dropping, the bottleneck is in JavaScript (expensive computations, too many re-renders). If UI frames are dropping, the bottleneck is native rendering (complex view hierarchies, overdraw). They might suggest moving to FlashList as a drop-in replacement with better recycling behavior or profiling with Hermes to find specific hot paths in the JavaScript thread.
"Describe how you would debug a crash that only happens on physical Android devices running Android 12 but works fine on simulators and iOS."
Appropriate for: Senior
What a strong answer includes: Start with crash logs from a crash reporting tool (Sentry, Firebase Crashlytics). Check whether it's a native crash (e.g., a segfault or ANR) or a JavaScript exception. For Android 12 specifically, check for new permission requirements (exact alarms, foreground service type, and Bluetooth permission changes), new restrictions on background execution, or changes to the PendingIntent mutability flag introduced in Android 12. Connect the physical device via USB and run adb logcat to capture native logs. If it's a native crash in a third-party library, check if there's a known issue or version update that addresses Android 12 compatibility.
Red flag answer: "I'd check the console logs." React Native console logs don't capture native crashes. A developer who has only debugged in Expo's error overlay has never dealt with a platform-specific native crash.
"How would you reduce cold start time in a React Native app?"
Appropriate for: Mid-level and senior
What a strong answer includes: Enable Hermes (if not already enabled) for faster JS parsing and execution. Use RAM bundles or inline requires to defer loading of modules not needed at startup. Minimize the initial render tree by lazy loading screens that aren't immediately visible. Defer heavy initializations (analytics, crash reporting, feature flags) to after the first meaningful paint. On Android, optimize the splash screen duration and use the new SplashScreen API. Profile with Hermes CPU profiler to find which modules take the longest to initialize.
Navigation and App Structure Questions
"How do you handle deep linking in a React Native app? Walk me through the full flow from a user tapping a link to landing on the correct screen."
Appropriate for: Mid-level and senior
What a strong answer includes: Configure URL scheme (iOS) and intent filters (Android) for the app. Use React Navigation's linking configuration to map URL patterns to screen names and parse parameters. Handle the case where the app is already running (warm start) vs launched from a killed state (cold start). Handle authentication: if the deep link goes to a protected screen and the user isn't logged in, store the intended destination and redirect after auth completes. Test with npx uri-scheme on iOS and adb shell am start on Android.
Red flag answer: "React Navigation handles it automatically." It doesn't. You have to configure the linking config, handle auth guards, and manually test the cold-start path.
"You need your app to work offline and sync when connectivity returns. How do you approach this?"
Appropriate for: Senior
What a strong answer includes: Choose a local persistence strategy based on data complexity. AsyncStorage or MMKV for simple key-value data. WatermelonDB or Realm for relational data with queries. Implement optimistic UI updates so the user sees their actions immediately. Queue mutations locally when offline. When connectivity returns, replay the queue against the server. Handle conflicts: last-write-wins is simplest, but for collaborative data you might need vector clocks or CRDTs. Use NetInfo to detect connectivity changes and trigger sync. Consider what happens when the server rejects a queued mutation, and how you notify the user.
Cross-Platform and Deployment Questions
"How do you handle platform-specific behavior in React Native? Give me a real example from a project you've worked on."
Appropriate for: All levels
What a strong answer includes: Platform.OS for simple conditional logic. Platform.select for choosing between platform-specific values. Separate files with .ios.js and .android.js extensions for components with fundamentally different implementations. Real example: Android's back button behavior requires subscribing to the BackHandler API, iOS has swipe-to-go-back by default. Status bar handling differs between platforms. Permission request flows are different. Keyboard behavior (padding vs height adjustment) varies.
The real example matters more than the API knowledge. A developer who gives you a specific story from a shipped app has dealt with the mess of real-world platform differences.
"Walk me through how you'd set up CI/CD for a React Native app that deploys to both app stores."
Appropriate for: Senior
What a strong answer includes: Use EAS Build (Expo) or Bitrise/GitHub Actions (bare workflow). Separate build configurations for dev, staging, and production environments. iOS: manage certificates and provisioning profiles with Match (Fastlane) or Xcode Cloud. Android: manage keystore signing. Automate version bumping. Run tests (Jest + Detox) before every build. Deploy internal testing builds automatically on PR merge to main. Production releases go through manual approval. Use CodePush or EAS Update for over-the-air JS updates without requiring a full store release.
"How do OTA updates work in React Native, and what are the limitations?"
Appropriate for: Mid-level and senior
What a strong answer includes: OTA (over-the-air) updates push JavaScript bundle changes directly to users without going through App Store review. EAS Update (Expo) and CodePush (Microsoft) are the main tools. The critical limitation is that OTA can only update JavaScript and assets. Any change to native code (new native module, updated native dependency, changed app permissions) requires a full binary release through the app stores. A strong candidate explains their versioning strategy: semantic versioning for binary releases, separate update channels for staging and production, and a minimum-version check that forces a full update when the native layer introduces breaking changes. They should also mention rollback capability if an OTA update introduces a regression.
Red flag answer: "We just push updates whenever." No mention of channels, versioning, or the native code limitation means they've never managed a production OTA pipeline.
Animation Questions
These reveal whether a developer can build the smooth, responsive interactions users expect from native apps.
"Explain the difference between the Animated API, LayoutAnimation, and Reanimated. When would you use each?"
Appropriate for: Mid-level and senior
What a strong answer includes: The built-in Animated API can run animations on the native thread, but only when useNativeDriver: true is set, and that only supports non-layout properties (opacity, transform). Layout properties like width, height, and position still run on the JS thread, which means frame drops under load. LayoutAnimation handles simple layout transitions automatically but gives limited control over timing and sequencing.
Reanimated (v3+) is the production standard. It runs entirely on the UI thread via worklets, which are JavaScript functions compiled to execute outside the JS thread. This means animations remain at 60 fps even when the JS thread is busy processing data or network requests. Pair it with react-native-gesture-handler for gesture-driven interactions.
The key mental model a strong candidate articulates is that Reanimated shared values are not React state. They update the UI thread directly without triggering component re-renders. This is what makes them fast, and it's also what confuses developers who try to treat them like useState.
Red flag answer: "I use the Animated API for everything" or no mention of Reanimated. In 2026, any consumer-facing app that requires smooth animations uses Reanimated. A developer who hasn't worked with it has either been building very simple apps or hasn't kept up to date.
"Your app has a gesture-driven drawer that stutters on Android but runs smooth on iOS. How do you diagnose and fix it?"
Appropriate for: Senior
What a strong answer includes: First, check whether the animation is running on the JS thread or UI thread. Open the performance monitor and watch both frame rates. If the JS thread is dropping frames, the gesture handler or animation logic is running in JavaScript instead of on the UI thread. The fix is to move the animation to Reanimated worklets and ensure the gesture handler is using react-native-gesture-handler (not the built-in PanResponder, which runs on JS thread).
If the UI thread is dropping frames, the problem is native rendering. Check for overdraw (too many overlapping views), complex shadow/elevation calculations (Android's elevation is more expensive than iOS shadows), or expensive native view operations during the gesture. Android's rendering pipeline handles drop shadows differently than iOS, which is why Android-specific stuttering on drawer gestures is one of the most common platform-specific performance issues.
Testing Questions
"Walk me through your testing strategy for a React Native app. What do you test at each level?"
Appropriate for: Mid-level and senior
What a strong answer includes: The testing pyramid applies. Many unit tests at the base: Jest for pure business logic, utility functions, and state management reducers. Mid-level: component tests with React Native Testing Library that test behavior from the user's perspective (tap a button, verify the right text appears) rather than implementation details (check which function was called). Fewer integration tests for multi-screen flows. Minimal E2E tests with Detox or Maestro for critical user paths (signup, checkout, payment).
A strong candidate explains the tradeoffs: unit tests are fast and cheap but don't catch integration bugs. E2E tests catch real user-facing bugs but are slow, flaky, and expensive to maintain. The sweet spot for most React Native apps is heavy investment in component tests with RNTL, because they're fast enough to run on every commit and high-level enough to catch real regressions.
Red flag answer: "We don't write tests, we just test manually before release." This is shockingly common and tells you everything about how comfortable the developer is with creating technical debt.
"How do you test platform-specific behavior?"
Appropriate for: Mid-level and senior
What a strong answer includes: Jest lets you mock Platform.OS to run the same test suite against both platform paths. For component tests, RNTL renders components in a platform-simulated environment. But the most important platform-specific testing happens at the E2E level: run Detox against both an iOS simulator and an Android emulator in CI, because the real platform differences (keyboard behavior, permission dialogs, back button, gesture handling) only surface in actual platform environments.
A strong candidate also mentions testing on physical devices, not just simulators. Certain bugs (performance issues, Bluetooth, camera) only appear on real hardware. They should have a device testing matrix: minimum supported OS version, a mid-range Android device (where most performance issues surface), and at least two iOS screen sizes.
Security Questions
"How do you store sensitive data like auth tokens in a React Native app?"
Appropriate for: All levels (depth reveals seniority)
Junior answer (acceptable): "I use AsyncStorage." This works for non-sensitive data, but AsyncStorage is unencrypted. A junior who knows to use it and understands the limitation is on the right track.
Mid-level answer (good): Use the device keychain. On iOS, react-native-keychain stores credentials in the iOS Keychain, which is encrypted by the OS. On Android, it uses the Android Keystore system. Never store tokens in AsyncStorage, SharedPreferences, or anywhere that's accessible without device authentication.
Senior answer (great): Everything above, plus: implement token refresh logic so access tokens are short-lived. Store refresh tokens in the keychain, not access tokens alone. Use certificate pinning (SSL pinning) to prevent man-in-the-middle attacks. For apps handling financial or health data, consider additional encryption layers and biometric authentication gates before accessing sensitive operations. Explain how jailbreak/root detection factors into the security model and what it can and can't prevent.
"What security considerations are specific to mobile apps that don't apply to web apps?"
Appropriate for: Senior
What a strong answer includes: The JavaScript bundle in a React Native app can be extracted and read from the APK or IPA file. Never put API keys, secrets, or sensitive business logic in the JavaScript bundle. Use environment variables that get injected at build time, and keep truly sensitive operations server-side. Code obfuscation (Hermes bytecode provides some obfuscation by default) helps but isn't bulletproof.
Other mobile-specific concerns: clipboard access (other apps can read the clipboard), screenshot prevention for sensitive screens, background app snapshot (iOS takes a screenshot when backgrounding that can expose sensitive data), and deep link URL handling that could be exploited to bypass auth flows. A developer who has worked on fintech or healthcare apps will know these instinctively. One who has only built content apps probably hasn't encountered most of them.
System Design Questions (Senior Only)
These test whether a developer can think beyond individual screens and reason about entire application architectures.
"Design the architecture for a real-time messaging app with React Native. Walk me through the major decisions."
Appropriate for: Senior
What a strong answer covers: WebSocket connection management (reconnection strategy, heartbeat, connection pooling). Local message persistence (WatermelonDB or Realm for fast queries and offline access). Optimistic message sending (show the message immediately, sync with server in background, handle failures gracefully). Push notification integration for messages received when the app is in the background or killed.
State management: messages in a local database rather than Redux store, because chat history can grow to thousands of records and shouldn't live in memory. Pagination strategy for loading older messages (cursor-based, not offset-based). Media message handling: image compression before upload, thumbnail generation, progressive loading.
The depth of their answer reveals how many of these problems they've actually solved versus theorized about. Ask follow-up questions about specific edge cases: what happens when the user sends a message, loses connectivity, then regains it? What happens when two users edit the same group name simultaneously?
"You need to build an e-commerce app that works offline and syncs when connectivity returns. How do you architect the data layer?"
Appropriate for: Senior
What a strong answer covers: Choose a local database based on data complexity. MMKV for simple key-value caching of product data. WatermelonDB for relational data with queries (cart, orders, user data). Implement a sync queue for write operations performed offline (add to cart, update address, place order).
Conflict resolution strategy: for the cart, last-write-wins is probably fine since it's per-user data. For inventory, you need server-side validation when the sync happens because another customer might have bought the last item. For orders placed offline, use an idempotency key to prevent retrying the sync from creating duplicate orders.
The candidate should describe what the user sees in each state: fully synced, syncing in progress (with a progress indicator), offline with N pending changes, and sync failed with a retry option. User trust depends on making the app's connectivity status transparent.
Questions You Should NOT Ask
| Don't Ask This | Why It's Useless |
|---|---|
| "What is React Native?" | Anyone can Google this. Tests nothing |
| "What's the difference between state and props?" | Beginner concept. Even juniors know this from tutorials |
| "What are hooks?" | Same problem. Tests recall, not ability |
| "Reverse a linked list" / algorithm puzzles | Tests CS theory, not React Native ability. A developer who aces this might not be able to debug a FlatList |
| "Rate yourself 1-10 on React Native" | Self-assessment correlates poorly with actual skill. The Dunning-Kruger effect means the weakest candidates often rate themselves highest |
The pattern across all bad questions: they test what a developer knows, not what they can do. Framework trivia is searchable in 30 seconds. Diagnostic thinking, architectural judgment, and production debugging experience are not.
Scoring Framework
After the interview, score each candidate on these five dimensions:
| Dimension | What You're Evaluating | Junior Bar | Senior Bar |
|---|---|---|---|
| Architecture | Can they structure an app that scales? | Follows patterns they've seen | Designs patterns for the team to follow |
| Debugging | Can they diagnose problems systematically? | Uses console.log and error messages | Uses profilers, reads native logs, traces across JS and native layers |
| Platform knowledge | Do they understand iOS and Android? | Knows Platform.OS exists | Handles platform-specific edge cases from experience |
| Code quality | Do they write maintainable code? | Consistent style, basic typing | Strict TypeScript, tested, documented, reviewable |
| Communication | Can they explain their thinking? | Describes what they did | Explains why they made each decision and what alternatives they considered |
A mid-level candidate should clear the junior bar on all five and the senior bar on at least one. A senior candidate should clear the senior bar on four of five.
What to Do Next
The questions in this guide test what matters: diagnostic thinking, production experience, and architectural judgment. Use them alongside the live coding tasks and portfolio review from our full hiring guide.
If you'd rather skip the interview process entirely, Hire React Native Developers has already run these evaluations. Every developer on our platform passed a 5-stage assessment including live coding on JSI, Turbo Modules, and Fabric. Vetted senior developer in your team within 5 days, 2-week risk-free trial.
