OctogleHire
← Interview questions library

25 React Native interview questions

Structure the React Native interview loop around evidence, not trivia. Start with a short screening call to confirm production experience, app store exposure, and whether the candidate has worked with Expo or bare React Native. Use a technical interview to probe debugging, state management, navigation, platform differences, and release judgment. Add a practical exercise or pair session that touches API data, lists, forms, and native-device concerns. For mid and senior candidates, include an architecture interview covering offline behavior, performance, New Architecture migration, CI/CD, and observability. Finish with a collaboration interview focused on code review habits, incident response, product trade-offs, and communication with iOS, Android, backend, QA, and design partners.

Junior React Native questions

Fundamentals, learning speed and how they debug.

  1. 01A screen works on iOS but crashes on Android after a dependency update. How would you narrow down the cause?

    Listen for: A strong answer starts with reproducing on a clean build, checking native logs with Android Studio or adb logcat, reviewing the changed dependency and autolinking output, and isolating the smallest failing screen. They should mention platform-specific files, permissions, Gradle changes, and avoiding random package downgrades before understanding the failure.

    Red flag: They only suggest reinstalling node_modules or asking a senior engineer to fix it.

  2. 02How would you build a sign-in form that handles validation, loading state, API errors, and keyboard behavior?

    Listen for: Look for practical handling of controlled inputs, field-level validation, disabled submit state, password manager compatibility, secure text entry, KeyboardAvoidingView or scroll behavior, and clear error placement. Good candidates separate form state from network state and consider accessibility labels, return key behavior, and not logging credentials.

    Red flag: They focus only on styling the inputs and ignore error, keyboard, and security behavior.

  3. 03You need to load a user profile from an API and show cached data while refreshing. What approach would you take?

    Listen for: They may use TanStack Query 5, RTK Query, or a small custom abstraction, but should explain loading, error, stale, retry, and refetch states. Listen for awareness of cache keys, screen focus refetching, optimistic updates only when appropriate, and separating API code from the component tree.

    Red flag: They put fetch calls directly in multiple components without thinking about duplicate requests or stale data.

  4. 04A FlatList scrolls poorly with image-heavy rows. What would you try before rewriting the screen?

    Listen for: A good answer mentions measuring first, stable keys, memoized row components, avoiding inline functions where they cause re-renders, image sizing, pagination, getItemLayout when possible, and tuning initialNumToRender or windowSize carefully. They should know not every list needs FlashList, but it can be considered for complex lists.

    Red flag: They say to wrap everything in useMemo without explaining what is actually re-rendering.

  5. 05How would you structure navigation for an app with signed-out, onboarding, and signed-in areas?

    Listen for: Listen for conditional navigator trees, persistent auth state hydration, splash screen handling, deep link considerations, and avoiding navigation resets scattered across screens. React Navigation 7 knowledge is useful, but judgment matters more: auth transitions should be predictable, testable, and not show the wrong screen briefly.

    Red flag: They plan to navigate manually from every auth-related screen with no single source of truth.

  6. 06What would you include in a pull request for a small React Native feature so it is easy to review?

    Listen for: Good signals include a focused diff, screenshots or recordings for iOS and Android, notes about tested devices, edge cases, accessibility checks, and any follow-up risks. They should mention tests where useful, clear component boundaries, and calling out native build or permission changes explicitly.

    Red flag: They think a PR is complete if the happy path works on their simulator.

Mid-level React Native questions

Independent delivery, trade-offs and code quality.

  1. 07When would you choose Expo managed, Expo prebuild, or a bare React Native app for a new product?

    Listen for: Strong answers compare product needs, native SDK requirements, config plugins, build ownership, OTA update policy, and team skill. They should know Expo SDK 54+ can handle many production apps, but bare or prebuild may be better when native code is heavily customized or third-party SDKs need direct maintenance.

    Red flag: They say Expo is only for prototypes or that bare React Native is always more professional.

  2. 08You are asked to migrate an older app to the New Architecture. How would you plan the work?

    Listen for: Listen for inventorying native dependencies, checking Fabric and TurboModule support, upgrading React Native incrementally, validating Hermes behavior, and using feature branches with real devices. A strong answer includes risk management, test coverage, crash monitoring, rollback planning, and performance comparison rather than treating it as a simple config switch.

    Red flag: They assume enabling the New Architecture flag is the whole migration.

  3. 09A native dependency builds locally but fails in CI for Android release builds. How do you debug it?

    Listen for: They should inspect Gradle output, Java or Kotlin version alignment, Android Gradle Plugin compatibility, CMake or NDK issues if present, signing versus debug differences, and environment parity. Good candidates reproduce with a clean release build locally and avoid masking errors with broad Gradle exclusions.

    Red flag: They blame CI immediately and suggest rebuilding until it passes.

  4. 10How would you implement push notifications and deep links without creating navigation bugs?

    Listen for: Look for clear handling of cold start, background, and foreground events, idempotent routing, permission prompts at the right product moment, and mapping notification payloads to safe app routes. They should coordinate with backend payload contracts and handle unavailable content, expired sessions, and analytics without blocking navigation.

    Red flag: They directly call navigation.navigate from every notification callback without considering app state.

  5. 11What would you examine if users report that the app feels slow to open after a release?

    Listen for: Strong answers separate native startup, JS bundle load, initial render, network blocking, font or asset loading, and auth hydration. They may mention React Native DevTools, Xcode Instruments, Android Studio Profiler, Hermes profiling, bundle analysis, and deferring noncritical work until after first meaningful screen.

    Red flag: They immediately blame the backend without checking startup measurements or app initialization work.

  6. 12How do you decide what belongs in global state versus local component state in a React Native app?

    Listen for: A good answer distinguishes server cache, session state, UI state, form drafts, feature flags, and navigation state. They may use TanStack Query, Zustand, Redux Toolkit, or context, but should justify boundaries, persistence, hydration, and testability instead of defaulting everything into one global store.

    Red flag: They put all state in Redux or Context because it is easier to access.

  7. 13Your team wants to use over-the-air updates. What guardrails would you recommend?

    Listen for: Listen for understanding that OTA updates can change JavaScript and assets but not native binaries. Strong candidates mention runtime versioning, phased rollout, crash monitoring, feature flags, compatibility with app store review rules, rollback strategy, and avoiding updates that depend on unavailable native modules.

    Red flag: They treat OTA as a replacement for normal app releases.

Senior React Native questions

Judgement, architecture and raising the team's bar.

  1. 14How would you structure a React Native codebase that has multiple product areas, shared design components, and several teams contributing?

    Listen for: Strong answers cover module boundaries, ownership, dependency direction, shared UI primitives, navigation organization, API clients, and testing strategy. They may discuss monorepos, package workspaces, Storybook, design tokens, and release discipline, while avoiding over-abstracting before product seams are clear.

    Red flag: They propose a large architecture template without asking about team size, release cadence, or product boundaries.

  2. 15A low-end Android device shows jank on a complex home screen, but iOS is fine. How would you lead the investigation?

    Listen for: Look for profiling before refactoring, distinguishing JS thread, UI thread, image decoding, layout cost, animations, network waterfalls, and native module work. They should know Reanimated can help specific animation issues, but also mention list virtualization, reducing initial render cost, asset strategy, and measurable acceptance criteria.

    Red flag: They suggest replacing React Native or rewriting the screen natively as the first step.

  3. 16What security decisions matter in a React Native app that handles authenticated financial or health-related data?

    Listen for: A strong answer includes secure token storage with Keychain or Keystore-backed libraries, minimizing local sensitive data, TLS assumptions and pinning trade-offs, biometric re-auth when appropriate, log hygiene, jailbreak or root signal limitations, screenshot handling, and coordination with backend session and revocation policies.

    Red flag: They say AsyncStorage is fine for tokens because the app bundle is private.

  4. 17How do you decide whether a feature should be implemented in JavaScript, a native module, or a third-party SDK?

    Listen for: Listen for trade-offs around performance, platform APIs, maintenance burden, privacy, SDK size, New Architecture compatibility, testability, and team expertise. Senior candidates should discuss proof-of-concept spikes, vendor risk, fallback behavior, and ownership after launch rather than focusing only on initial implementation speed.

    Red flag: They choose third-party packages by popularity without reviewing native impact or maintenance.

  5. 18How would you design the release process for a React Native app used by customers on both app stores?

    Listen for: Good answers include branch strategy, semantic runtime versioning for OTA, CI builds, signing custody, environment configuration, beta distribution, automated tests, release notes, crash and performance monitoring, staged rollout, rollback paths, and coordination with backend changes. They should value repeatability over heroics.

    Red flag: They rely on one engineer’s laptop and manual checklist for production releases.

  6. 19How would you raise accessibility and internationalization quality across an existing React Native app?

    Listen for: Strong candidates discuss auditing core flows, screen reader labels and roles, focus order, dynamic type, color contrast, reduced motion, RTL layout, pluralization, date and currency formatting, and test devices. They should propose component-level defaults and review standards instead of one-off fixes.

    Red flag: They treat accessibility and localization as QA-only tasks near the end of a release.

  7. 20How do you handle a team that is shipping quickly but accumulating React Native-specific technical debt?

    Listen for: Look for prioritization by user impact and delivery risk, visible debt tracking, refactoring while touching code, ownership of flaky builds, dependency update cadence, and mentoring through reviews. A senior answer balances pragmatism with standards and avoids blocking product work for broad rewrites.

    Red flag: They either ignore debt completely or demand a long rewrite before any new features.

System design React Native questions

Designing real systems end to end.

  1. 21Design an offline-first React Native app for field workers who complete forms, attach photos, and sync when connectivity returns.

    Listen for: Strong answers cover local persistence, sync queues, conflict handling, attachment upload retry, background constraints on iOS and Android, user-visible sync status, data encryption, schema migrations, and API idempotency. They should pick tools deliberately, such as SQLite, WatermelonDB, or a simple queue, based on data shape.

    Red flag: They say to store everything in memory until the network comes back.

  2. 22Design a real-time chat feature in an existing React Native app with push notifications, unread counts, and media attachments.

    Listen for: Listen for WebSocket or subscription lifecycle, reconnect behavior, pagination, local optimistic messages, server acknowledgments, media upload flow, notification routing, app foreground versus background handling, and list performance. A strong answer also covers moderation states, failed sends, and consistent unread counts across devices.

    Red flag: They treat chat as a simple FlatList plus send button with no delivery or lifecycle design.

  3. 23Design a white-label React Native app used by multiple brands with different themes, assets, and feature availability.

    Listen for: Good answers discuss build-time versus runtime configuration, design tokens, asset management, bundle size, environment separation, app identifiers, signing, OTA compatibility, feature flags, and testing each brand’s critical path. They should avoid duplicating the entire app per brand unless constraints justify it.

    Red flag: They plan to fork the repository for every customer without an ownership or merge strategy.

  4. 24Design a media capture and upload flow for videos recorded in the app, with progress, retry, and background behavior.

    Listen for: Strong answers cover permissions, camera library selection, file size and duration constraints, compression or transcoding trade-offs, resumable uploads, temporary file cleanup, progress UI, cancellation, low-storage handling, and OS background limits. They should coordinate signed URL or multipart upload design with backend.

    Red flag: They upload the full video directly from component state and assume it will finish.

  5. 25Design how a React Native module would be embedded inside an existing native iOS and Android app with shared authentication.

    Listen for: Listen for boundaries between native and React Native navigation, dependency initialization, auth token handoff, event contracts, versioning, error isolation, bundle delivery, and New Architecture readiness. A strong answer treats the React Native surface as a product module with clear ownership, monitoring, and rollback behavior.

    Red flag: They assume the React Native app can take over navigation and storage without coordinating with native teams.

Practical task · 2–3 hours

Build a Resilient React Native Orders Screen

Create a small React Native app or feature using Expo SDK 54+ or a current bare React Native setup. The app should show a paginated list of orders from a provided mock API, support pull-to-refresh, show order details, and include a simple status filter. Add loading, empty, and error states, plus one form action such as adding a note to an order with optimistic or clearly staged update behavior. The exercise can be completed live or as a 2–3 hour take-home. Include a short README explaining trade-offs, setup, and what you would improve next.

How to evaluate it

  • Clear component boundaries and understandable state management.
  • Correct handling of loading, error, refresh, pagination, and empty states.
  • Good React Native UX details: keyboard, accessibility labels, list performance, and platform checks.
  • Readable TypeScript, focused tests or testable structure, and minimal unnecessary dependencies.
  • Practical explanation of trade-offs and next steps in the README.

Rather skip the interview loop?

Every Octogle React Native engineer has already passed a technical assessment, system design and a live interview with an engineer who has shipped React Native. Send a brief and get 3–5 scored profiles in 48 hours.