Almost nobody starts their career in React Native. People arrive from one of two directions — web developers who already knew React, and mobile developers who already knew the device — and the two groups have opposite blind spots.
Interviewers know this. Much of the first ten minutes is spent working out which door you came in through, and most of the rest is spent on the other side of it.
| If you came from | You'll be fine on | Where they'll find the gap |
|---|---|---|
| Web React | Components, hooks, state, the JavaScript itself | Permissions, build variants, native crash logs, what a release build changes |
| Native iOS or Android | The device, the stores, threading, reading a stack trace | React's mental model, why that list re-rendered, what the navigator keeps alive |
So the sections below are arranged around that: your half, their half, and the seam where both groups are equally exposed.
The React half
Where mobile-first candidates get caught. Also where web candidates get overconfident.
- What does
FlatListdo that mapping over an array doesn't, and when does the difference start to matter? - Why does
useEffectcleanup matter more on a screen the navigator keeps mounted? - Where does a screen's data live — navigation params, component state, or a store?
- What's different about styling here compared to CSS on the web?
- What can you share between a web React app and a React Native one — and what can't you?
Saying it out loud: question 1 has an answer everyone gives — "it virtualises, so it only renders what's visible" — and that's the setup, not the answer. Carry it through to what it costs you: "Because rows get unmounted and recycled, anything I keep in a row's local state disappears when it scrolls away, so that state belongs above the list. And the reason people get bad FlatList performance isn't the list, it's passing a new inline renderItem on every parent render, so every row re-renders even though the data didn't change." The first half is knowledge. The second half is having shipped one.
Question 4 is easy to underestimate. It isn't just "no cascade, no units" — there's no inheritance except on text, layout is flexbox with a different default direction, and a shadow is two different implementations wearing one name. Candidates who answer it in one sentence usually haven't fought it.
The React knowledge underneath this section — what a re-render actually is, what belongs in state — is graded the same way in web interviews, and we go through it question by question in Frontend Developer Interview Questions.
The native half
Where web-first candidates get caught, and where "it works on my machine" comes from.
- What's actually inside the
iosandandroidfolders, and when do you have to open them? - How do permissions work, and what happens the second time a user denies one?
- Expo Go, a development build, a release build — what's the difference, and why does it bite people?
- Your app gets backgrounded. What happens to your JavaScript, and does it differ by platform?
- A native crash log lands in your bug tracker. How do you read it?
Saying it out loud: question 8 is the question that sorts people who've only ever run start from people who've shipped. The answer that scores is the failure mode, not the definitions: "Expo Go runs your JS inside a prebuilt client that only contains the native modules Expo bundled — so the moment you add a library with its own native code, it works for me and crashes for you, and the fix is a development build rather than a config change. And release builds are where the surprises land, because that's the first time the bundle is minified and the dev-only warnings are gone."
Question 9 is the one native developers answer well and web developers barely answer at all — the honest short version is that your JavaScript doesn't get a lot of time in the background, that iOS and Android disagree about how much, and that anything you need to happen while backgrounded belongs in native scheduling rather than a JS timer.
If the device half of this is where you feel thinnest, the platform-specific loops are worth reading straight: iOS Developer Interview Questions and Android Developer Interview Questions.
Where the two halves meet
Nobody arrives already good at this section. That's exactly why it decides the loop.
- How does your JavaScript actually talk to native code, and why does that matter for performance?
- You need a native capability and no package exists. What are your options?
- A library works fine on Android and crashes on iOS. How do you approach that?
- When do you write a native module, when do you take a dependency, and when do you push back on the requirement?
Saying it out loud: question 11 is the one where candidates most often recite something they read once. Answer it as a history with a position in it, because that's what shows you've felt the constraint: "The old model was an asynchronous bridge — every call serialised to JSON and batched, which is why moving a lot of data across it, or driving an animation from JS, went badly. The newer architecture lets JavaScript hold direct references to native objects and call them synchronously, so the cost profile is different. I've mostly worked in the era where you assumed crossing was expensive, so my instinct is still to keep animations and gesture handling on the native side."
Question 14 is a seniority question in disguise. Two of the three options are technical and the third one isn't, and candidates who never reach the third option are telling you they've never been the person who had to say no.
What the last three sections have in common: in every one, the weak answer and the strong answer open identically. The whole difference lives in the second half — the consequence rather than the definition, the failure mode rather than the feature list, the era you worked in rather than a fact with no date attached. If you change one thing about how you answer, make it that your second sentence says what it cost you rather than what it does.
On a real device
Almost always asked as a scenario, never as a definition.
- A long list janks while scrolling. What do you actually do about it?
- An animation stutters while the app is doing other work. Why, and what fixes it?
- It takes four seconds before the first screen appears. Where do you look?
Saying it out loud: question 15 rewards the order of operations more than the fixes. Say what you'd measure first: "First I'd check I'm not looking at a development-build problem, because dev builds lie about performance. Then I'd find out whether it's the cost of rendering one row or the whole list re-rendering — those have completely different fixes, and guessing between them is where the time goes." Then name the actual levers. Interviewers are listening for whether you'd measure or guess.
Question 16 is really asking whether you know what runs where. The short answer is that JavaScript is doing your app's work on one thread, so an animation driven from JS competes with it — which is the entire reason for running animations natively instead.
Shipping
Senior weighting, and the section web-first candidates most often have never touched.
- What can you ship over the air, and what needs to go through the stores?
- Some of your users are stuck on an old JavaScript bundle. What do you do about that?
- A crash only happens in release builds and the stack trace is unreadable. How do you get a real one?
Saying it out loud: question 18 is a rules question with a judgment question underneath it. The rule is that JavaScript and assets can go over the air while anything native needs a store build. The judgment is knowing that the two get out of step: "The risk isn't the mechanism, it's shipping a JS update that expects a native module the user's build doesn't have. So the bundle needs to know which native version it's allowed to land on, and I'd rather block an update than push one that white-screens on launch."
Question 20 has a single-word core — source maps — but the answer people remember is the one that mentions uploading them as part of the release build rather than generating them afterwards, because a source map from a different build is worse than none.
The thing that makes this loop different
React Native moves faster than any other ecosystem in this series. The architecture underneath it changed, the default way to start a project changed, and the standard answer to "how do you do navigation" has changed more than once. Which means you will, at some point, be asked about something in a state you haven't used.
That moment is worth preparing for on its own, because the instinct — answering confidently from the version you know — is the one that costs you.
Answering as if nothing moved
“You bridge to native and it's all asynchronous, so you batch the calls.”
Stated flatly, with no era attached. If the team moved on two versions ago, you've just told them how long it's been since you looked — and you've done it while sounding certain, which is the part that lingers.
Dating your own knowledge
“The version I shipped on worked this way — I know that changed, and my understanding of the newer model is roughly this, though I haven't run it in production yet.”
Same knowledge, with a timestamp on it. Now the interviewer can calibrate you instead of guessing, and nothing you said will turn out to be wrong later.
That habit is worth more here than a memorised list of API names, because the API names are the part most likely to be stale by the time you interview.
It's also harder than it sounds when you're doing it in a second language and at interview speed, where the tendency is to speed up as soon as you feel uncertain. That's its own problem, and we wrote about it in what 128 WPM actually feels like.
Practical target: take question 11 and answer it out loud twice — once describing how it worked in the version you actually shipped, once describing what you understand about the current one. If the second version comes out vague, that's fine and it's honest. Saying it that way in the interview is what turns a stale answer into a calibrated one.
