Senior React Native Interview Questions, and What Good Answers Sound Like

Many React Native interviews still ask what a component lifecycle is or how useEffect works, then hire someone who has never shipped an app through store review, debugged a production crash or migrated a codebase to the New Architecture. Those are the things that separate a senior React Native engineer from someone who has built screens, and they're what an interview should probe.

This is a set of senior React Native interview questions for 2026, grouped by the areas a senior engineer owns: architecture, performance, data, native code, releases, testing, security and working with a team. For each, you'll find what a strong answer covers and a red flag to listen for. Candidates can use it to prepare; interviewers can use it to build a loop that tests real experience.

Key takeaways

• Senior interviews should test judgement and trade-offs, not trivia: why, when and what it cost.
• Every strong answer includes specifics: a version, a metric, a failure and what changed afterwards.
• Release ownership is a senior skill: builds, signing, store review, over-the-air updates and crash triage.
• Red flags are often absolutes: "always memoise everything", "never write native code", "tests slow us down".
• Ask follow-ups. "What would you do differently?" reveals more than the first answer.

Architecture and the New Architecture

What problem did the New Architecture solve, and what changed for app developers?
Strong answer: the old bridge serialised every message between JavaScript and native code asynchronously, which added latency and made synchronous calls impossible. JSI lets JavaScript hold references to native objects and call them directly; Fabric is the new renderer that supports concurrent React features; Turbo Modules load lazily with type-safe interfaces generated by Codegen. It became the default in 0.76, and from 0.82 it's the only option. For app developers, the practical work was auditing libraries for compatibility and upgrading or replacing those that weren't.
Red flag: describing the bridge as current, or "it's just faster".

How would you structure a React Native app that will grow to 50 screens and five developers?
Strong answer: feature-based folders, a clear boundary for API access and server state, shared UI components with a small design system, navigation defined in one place, strict TypeScript, and conventions written down. They mention trade-offs and what they'd postpone.
Red flag: a big-bang "clean architecture" with layers nobody needs yet.

Expo or bare React Native for a new project, and why?
Strong answer: Expo by default in 2026, with development builds and config plugins for native needs, because builds, updates and upgrades get much easier; bare only for specific constraints such as unusual native build requirements, brownfield integration into an existing native app, or organisational rules.
Red flag: "Expo can't do native code", which hasn't been true for years.

Performance

A list of 2,000 items stutters on mid-range Android phones. Walk me through it.
Strong answer: measure first in a release build on a real device, then check the list implementation (FlashList v2 or a well-configured FlatList), stable keys, item component re-renders, image sizes and decoding, and work done during scrolling. They mention profiling tools and confirming the fix with numbers.
Red flag: jumping straight to React.memo everywhere without measuring.

How do you improve startup time?
Strong answer: measure time to first meaningful screen, then reduce JavaScript executed at startup (lazy-load screens and heavy modules), defer non-critical SDK initialisation, cache-first data so the first screen renders from storage, optimise images, and keep Hermes on. Hermes precompiles JavaScript to bytecode at build time, which speeds startup.
Red flag: no mention of measuring, or blaming React Native itself.

Where does the React Compiler change how you write components?
Strong answer: it automatically memoises components and values, so most manual useMemo and useCallback becomes unnecessary; you still need to follow the Rules of React for it to work, and you still profile real problems.
Red flag: never having heard of it, or thinking it fixes slow lists by itself.

State and data

How do you separate server state from client state?
Strong answer: server state (data owned by the backend) belongs in a cache with fetching, invalidation and retries, such as TanStack Query; client state (UI, preferences, drafts) in local state or a small store. Mixing them in one global store causes stale data and boilerplate.
Red flag: everything in one global store, synchronised by hand.

How would you make a feature work offline?
Strong answer: decide what must work offline, store data locally (SQLite or MMKV depending on shape), queue writes with idempotency keys, sync when the connection returns, and define conflict rules. They know which parts are hard: conflicts, deletions and migrations.
Red flag: "we cache API responses" as the whole answer.

Native code

When would you write a native module, and how?
Strong answer: when a platform API or SDK isn't available through a maintained library, or when performance requires native code. In 2026, the Expo Modules API or Turbo Modules with Codegen, written in Swift and Kotlin, with a typed JavaScript interface and tests on both platforms.
Red flag: copying native code from an old tutorial for the legacy bridge.

Releases and production

Walk me through shipping a release, from merge to 100% of users.
Strong answer: versioning, a CI build (EAS Build or Fastlane), signing, internal testing, store submission and review notes, phased release on iOS and staged rollout on Android, watching crash-free sessions and key metrics before widening, and a plan if something goes wrong.
Red flag: "someone else handles the stores".

What can you ship with an over-the-air update, and what can't you?
Strong answer: JavaScript and asset changes for bug fixes and improvements, within store rules that forbid changing the app's purpose; anything touching native code needs a store build. Runtime versions keep updates from reaching incompatible binaries. Rollback plans matter as much as the update.
Red flag: "we ship everything over the air", or not knowing about runtime versions.

A crash spikes after a release. What do you do in the first hour?
Strong answer: check whether it's tied to the new version, pause the rollout, read the symbolicated stack trace and breadcrumbs, decide between a hotfix, an over-the-air fix or a kill switch, and communicate. Afterwards, a short write-up and a guard against the class of bug.
Red flag: no mention of pausing the rollout.

Testing and security

What does your testing strategy look like for a React Native app?
Strong answer: strict TypeScript and linting, unit tests for logic, component tests with React Native Testing Library that query by role and label, a small set of end-to-end flows in Maestro or Detox for critical paths, and crash reporting in production.
Red flag: hundreds of snapshot tests as "coverage".

Where do you store tokens, and what should never be in the app bundle?
Strong answer: tokens in the Keychain and Keystore through secure storage; no secrets in the bundle, including public environment variables, because the bundle can be extracted. Authorisation always happens on the server.
Red flag: AsyncStorage for tokens, or API keys for paid services in the app.

Working as a senior engineer

Tell me about a technical decision you'd make differently now.
Strong answer: a specific decision, the context at the time, what happened, and what they learned, without blaming others.
Red flag: "I wouldn't change anything."

How do you estimate a feature you've never built before?
Strong answer: break it into parts, spike the riskiest unknown first, give a range with assumptions, and update the estimate as they learn.
Red flag: a single confident number with no assumptions.

From the field: These questions map to the work a senior React Native engineer actually does. Mine has included 50+ apps shipped to the App Store and Google Play over 7+ years, 8 New Architecture migrations, and release ownership from EAS builds and store review to phased rollouts and Sentry crash triage. Interviews that probe those areas find people who can do the job.

Questions by experience level

Not every role is senior. These shorter sets fit earlier stages, with the core of a good answer for each.

Around 2 to 3 years of experience

• How do props and state differ? Props come from the parent and are read-only; state belongs to the component and changes over time, triggering a re-render.
• Why does a list need keys? So React can match items between renders; stable IDs prevent wrong rows updating and lost input state.
• How do you store a login token? In secure storage (Keychain or Keystore), not AsyncStorage.
• How do you debug a crash that only happens in release builds? Reproduce with a release build, read the symbolicated stack trace from crash reporting, check minification and environment differences.

Around 5 years of experience

• How would you structure navigation for an app with auth, tabs and modals? An auth stack and an app stack switched on session state, tabs inside the app stack, modals presented above; deep links mapped to routes.
• When would you move logic into a native module? For platform APIs without a maintained library, or heavy computation; with a typed interface and tests on both platforms.
• How do you keep an app usable on a poor connection? Cache-first reads, an outbox for writes, idempotent APIs, clear sync status.

7+ years of experience

• Plan the migration of a large app to the New Architecture. Audit dependencies, upgrade in steps, release each step with a staged rollout, watch crash-free rates.
• How do you decide between building a feature in-app or on the backend? By where the source of truth lives, how often it changes, and whether old app versions must keep working.
• How do you raise the quality bar of a team without slowing it down? Automated checks in CI, small pull requests, shared component and API conventions, written decisions.

For interviewers: running a better loop

• Use one practical exercise that mirrors real work, such as reviewing a pull request or debugging a small app, rather than puzzles.
• Ask every candidate the same core questions, so comparisons are fair.
• Score against written criteria before discussing candidates.
• Leave time for their questions. Senior engineers interview you too.

FAQ

What are the most common React Native interview questions?

Common topics include the New Architecture (JSI, Fabric, Turbo Modules), list and startup performance, state management and server state, navigation, native modules, release processes and over-the-air updates, testing strategy and secure token storage. Senior interviews focus on trade-offs and real experience in these areas.

How do I prepare for a senior React Native interview?

Prepare specific stories from your own work: a performance problem you measured and fixed, a release that went wrong and how you handled it, a migration you led, and a decision you'd make differently. Review the New Architecture, current Expo tooling and release practices, and practise explaining trade-offs out loud.

What should a senior React Native developer know in 2026?

The New Architecture and how to work with native code through Turbo Modules or the Expo Modules API, performance profiling, server state and offline data, Expo and EAS tooling, store submission and over-the-air update rules, testing strategy, security basics and how to lead technical decisions on a team.

How long should a React Native technical interview be?

A focused loop often includes a 45 to 60 minute technical conversation using questions like these, plus one practical exercise of a few hours at most, either live or as a short take-home. Longer processes tend to lose strong candidates.

Next steps

If you're hiring a senior React Native engineer for your product, see my résumé for the projects behind these answers, or get in touch to talk about your team.

Sources

• About the New Architecture, React Native docs
• The New Architecture is here, React Native blog
• Performance overview, React Native docs
• React Compiler, React docs
• Runtime versions and updates, Expo documentation