Lesson 1 of 5
What Mobile Interviews Probe
"A map is not the territory it represents, but, if correct, it has a similar structure to the territory, which accounts for its usefulness." — Alfred Korzybski, Science and Sanity (1933)
The most common way to fail a React Native interview is to prepare for a React interview.
It is an easy mistake and the job description encourages it. React Native is React; the components take props; the hooks are the same hooks. A strong web engineer walks in expecting questions about reconciliation and memoisation, and gets asked what happens when the user takes a phone call mid-upload.
That question is not a trick. It is the interview. React is the assumed baseline — the part nobody spends time on because everyone has it. What is being probed is everything the previous seven Parts of this volume were about: a runtime with a thread boundary, a device with a battery and a permission model, and a release process with no recall. None of that is React, and none of it is visible from the web.
An interview is a lossy compression of a job into an hour. Mobile compresses worse than most, because the things that actually make mobile hard — a bug reported once from a device you do not have, a release you cannot take back, a permission a user denied eight months ago — unfold over weeks and cannot be staged at a whiteboard. So every mobile interview is measuring a proxy. Which proxies are honest, and which ones select for people who are good at interviews about mobile rather than people who are good at mobile?
The surface, measured
Start with something checkable rather than an opinion. React Native's public entry point exports a fixed list, and you can ask how much of it a web React developer has ever encountered.
Seventy percent is an uncomfortable number if you were planning to lean on React knowledge, and a reassuring one if you have read the rest of this volume: nearly all of it has appeared in these Parts, under its own chapter.
A driving test for someone who has only ever driven automatics, taken in a manual. Everything about the road is identical — the signs mean the same things, the right of way rules have not changed, the hazard perception is the same skill — and none of that is what the examiner is watching. They are watching the hill start. The candidate who prepares by revising the highway code will be genuinely well prepared for the part of the test that was never in doubt, and will stall at the first junction. What makes this analogy uncomfortable rather than merely tidy is that the hill start is not the important part of driving; it is just the part that distinguishes the two licences. Mobile interviews have the same property. They over-weight the delta because the delta is what they are for, which means a candidate can fail one while being a better engineer than the person who passed.
Four axes, and which one a question is on
Nearly every mobile-specific question is probing one of four things. Recognising which one is most of the work, because it tells you what kind of answer is wanted.
The classifier is crude — it matches keywords, and a real question can sit on two axes at once. Its value is the habit: before answering, decide which of the four you are being asked about, because the same words mean different things on different axes. "How do you handle an error" on the runtime axis is about a rejected promise crossing a module boundary; on the shipping axis it is about whether the fix can go out over the air.
Mobile interviewing inherited its shape from two different traditions that had never had to agree. Native iOS and Android hiring grew up asking about memory management, view lifecycles and the platform's own idioms — questions with exact answers, because the platform documented them. Web hiring grew up asking about the language, the DOM, and increasingly about a framework, with a much larger tolerance for "it depends". React Native landed in between, and for several years interviews were visibly one tradition or the other depending on who wrote them: a Swift engineer's React Native interview asked about threading and lifecycles, a web engineer's asked about hooks. Candidates reported wildly inconsistent experiences for the same job title, which is exactly what you would expect. What has settled since is a rough consensus that the React half is a screening filter and the mobile half is the actual signal — which is why a strong React answer rarely saves an interview and a strong answer about backgrounding often does.
What "it is slow" is really asking
The single most common mobile question is a performance one, and it is not really a performance question. It is a question about whether you know there are layers.
That is the general shape of a good mobile answer, and it is worth naming: narrow before you fix. Mobile rewards it more than web does, because the layers are further apart — a web performance problem is usually somewhere in one runtime, and a mobile one might be in JavaScript, in native, in the image decoder, or in the operating system's decision to suspend you.
The export count surprised me and I checked it twice. My prior was that React Native's surface was mostly familiar with a handful of device APIs bolted on — that the novel part was a long tail. It is not a tail; it is the body. Even classifying generously, counting Animated as the Web Animations API and PanResponder as pointer events, about seven exports in ten are things a web React developer has simply never typed. What makes that number useful rather than discouraging is the other measurement beside it: eight exports name a platform in their own identifier. Those two facts together say something the documentation never says outright — that this is not React with extra components, it is a second platform that React happens to render into, and one tenth of it does not even agree with itself about which device you are on. I had written six Parts of this volume before I thought to count, which is its own small lesson about how long an unexamined prior can survive.
The questions with a false premise
A specific and under-prepared-for category: the question whose premise is wrong, where the expected answer is to correct it. These are not traps in the hostile sense — they are the fastest available test of whether you have actually used the thing.
The reflex matters more than the list because the list ages. Half of those seven could change in a future release, and the habit of verifying would survive all of it.
The numbers worth carrying, and why
There is a small set of measurements from this volume that are worth being able to produce from memory — not because anyone will ask you to recite them, but because each one is the compressed form of a mechanism, and the mechanism is what gets asked.
That asymmetry is worth taking seriously when you prepare, because the two kinds of preparation feel identical and produce very different interviews. Reading a list of numbers is fast and satisfying and leaves you with nothing to say to the follow-up. Working out why each number is what it is takes an evening per Part and answers questions you have not seen.
The pattern I see most often in candidates who are genuinely good and interview badly is over-indexing on the framework. They can explain reconciliation precisely, and when asked what happens to an in-flight upload when the app is backgrounded, they answer as though the process keeps running — because on the web it broadly does. Nothing about that answer is stupid; it is a correct model of a different platform. The inverse failure is rarer and more damaging: the candidate who has memorised mobile trivia and cannot reason about it. They know AppState has five states and cannot say which of them their upload actually has to survive. Interviewers distinguish these quickly by asking one follow-up, and the follow-up is almost always "what would you do about it?" — which is why the useful preparation is not a flashcard deck. It is having once, actually, been on the wrong end of a backgrounded upload.
Common Mistakes
- Preparing for a React interview. React is the screening filter; the mobile half is the signal.
- Assuming the web model of the process. Your app can be suspended or killed between two lines.
- Proposing a fix before identifying the layer. Five layers produce the same symptom.
- Treating device APIs as a happy path. Permissions, network and storage are state machines.
- Accepting a false premise to be agreeable. Several common claims about React Native are wrong.
- Memorising numbers without their mechanism. The follow-up is always "what would you do about it?"
- Forgetting the platform split. Eight public exports work on one platform by name.
- Talking about releases as deploys. There is no recall and no instant rollback.
- Ignoring the interviewer's tradition. A Swift-trained interviewer and a web-trained one want different answers.
- Not asking which axis you are on. The same words mean different things on each of the four.
Interview Corner
flexDirection is column rather than row. Your JavaScript runs on its own thread alongside a native UI thread, so blocking one does not necessarily freeze the other. And you get a device — permissions, a background lifecycle, a camera, a battery — none of which the browser exposes in the same way. Concretely, of React Native's roughly eighty public exports, only about a quarter have any browser counterpart at all, which is a fair measure of how much of it is genuinely new.renderItem is an inline arrow, because the cell renderer is a PureComponent and an inline function defeats it for every mounted row. If memory climbs, it is virtualization — the default window mounts far more rows than are visible. If the jank is image-specific or platform-specific it is decode cost on the native side. And if only an animation stutters while the rest is fine, it is whether that property is one the native driver can take off the JS thread. The order matters more than the list: a fix proposed before the layer is identified is a guess.Hands-on
Build the classifiers this chapter reasons with. Implement surfaceSplit, partitioning an export list into familiar, novel and platform-named; axisOf, scoring a question against the four axes; narrowFirst, ordering diagnostic layers so the blocking check comes first; checkPremise, returning the correction for a false claim; and weighAnswer, scoring recall against reasoning the way the advanced answer above argues it should be. The checks below run either way — a stub scores zero, so a passing run means the behaviour is real.
Summary
- React is the screening filter, not the signal. The mobile half of the interview is what decides it.
- About seven of React Native's public exports in ten have no browser counterpart, even classifying generously.
- Eight of the eighty-four name a platform in their own identifier, so one export in ten works on half your devices.
- Four axes cover nearly every mobile question: the runtime boundary, the device, the lifecycle, and shipping.
- The axis determines what kind of answer is wanted, because the same words mean different things on each.
- "It feels slow" is a layering question, and at least five distinct layers produce that one symptom.
- Narrow before you fix. A fix proposed before the layer is identified is a guess, and it shows.
- Some questions carry a false premise, and correcting it is the fastest proof you have used the thing.
- The verifying reflex outlasts the facts, since any specific claim about the runtime may change next release.
- Every mobile interview measures a proxy, because what makes mobile hard unfolds over weeks, not an hour.
Next: The Render Path at the Whiteboard — tracing one setState from a JavaScript call to a pixel on a screen, out loud, with nothing but a marker, which is the single question most likely to separate the two halves of a mobile loop.
I am wary of a chapter that tells you how to be interviewed, because the genre is full of advice that optimises for the hour and not for the job, and the two diverge more than anyone admits. What I have tried to do instead is notice that in this particular case they diverge less than usual. The four axes are not interview categories I invented to make a list; they are the actual structure of what is different about this platform, which is why they also happen to be this volume's table of contents. Narrowing before fixing is not an interview technique; it is what you do at two in the morning when a list is janky on one device. And the verifying reflex — going and reading Node.h rather than trusting the documentation about flex — is the single habit that produced almost every correction in these eight Parts, including several where I had confidently written the wrong thing first. If that reflex reads well in an interview, it is because it works, not because it performs.
Q&A · 0
Enrol to ask questions and join the discussion.
No questions yet — be the first to ask.