Three months. That's how long it took us to realize we'd made a mistake.
Not because anything obviously broke. The screens rendered. The navigation worked. The API calls went through. From the outside, progress looked normal — features were getting built, PRs were getting merged, the project was moving.
What we found when we actually dug in was code that worked in the way a demo works. Functional under controlled conditions. Quietly falling apart under real ones. Performance issues on mid-range Android devices that nobody on the team had tested on. Platform-specific bugs that had been sitting in the codebase for weeks, invisible because everyone was developing on iPhones. A FlatList implementation that would have caused serious problems the moment a real user with real data volume opened that screen.
The developer wasn't bad at JavaScript. He was actually pretty good at JavaScript. He just didn't know React Native the way the job required — and our hiring process wasn't designed to catch that difference.
That gap between "knows React Native" and "can run a React Native project in production" is where the hidden cost lives. And when you need to hire React Native developers, finding that gap before someone is three months into your codebase is the whole challenge.
Why React Native Makes This Harder Than Other Hires
React Native sits on top of JavaScript and React — two of the most abundant skills in the developer market. Someone with solid web React experience can build a React Native screen that looks completely reasonable. The component structure makes sense, the styling is fine, the logic flows. A code reviewer who isn't specifically looking for mobile patterns won't catch anything wrong.
The abstraction React Native provides is genuinely good. Good enough that you can build a lot — maybe most of a typical app — without ever understanding what's underneath it. The bridge, or JSI in the new architecture. How the JS thread and the main thread interact. Why certain operations that feel lightweight in web React cause frame drops on mobile. How iOS and Android differ in ways React Native doesn't fully abstract away.
You don't hit these things in development with a clean dataset on a high-end device with a fast connection. You hit them when a real user on a three-year-old Android phone with 2GB of RAM opens a list screen with 800 items and the app drops to 15 frames per second.
By then you've already shipped.
The Signals During Hiring — If You Know Where to Look
Standard technical screens don't surface mobile depth. They surface JavaScript ability. Those are different things and the interview has to reflect that.
Ask them to explain how JavaScript communicates with native code in React Native. Not looking for a lecture — just enough to know they've looked past the abstraction. Developers who understand the bridge, or what JSI changed and why it was necessary, will give you a real answer. Developers who've only worked at the surface level will say something vague about React Native "compiling to native" — which isn't accurate and is a reliable indicator that they haven't thought much about what's actually happening.
Ask about a hard bug they dealt with. This is the question I've come to rely on most. Not "what was a challenge you faced" — that's too soft. Specifically: tell me about a bug in a React Native project that took you more than a day to find. What made it hard? Where did it end up being?
Experienced React Native developers have specific stories. A performance regression that traced back to a memo boundary that wasn't set correctly. A crash on Android that didn't reproduce on iOS and turned out to be a native module behaving differently across versions. A build failure that took two days to attribute to a transitive dependency conflict nobody had touched. These stories have texture. They have dead ends and wrong hypotheses and a moment where the real cause clicked.
Generic answers — "we had some performance issues and we optimized the component rendering" — aren't hiding modesty. They're hiding the absence of the experience.
Ask if they've ever written a native module, and what prompted it. Not every React Native project requires one. But any developer who's worked on React Native seriously has hit a moment where the JavaScript layer couldn't do what was needed and they had to go native. If someone has genuinely never opened Xcode or written a line of Kotlin or Java in the context of a React Native project, they haven't done the kind of work that requires it. That's a real limitation for any project with real requirements.
What Shows Up After They're On the Team
Some things the interview won't catch. They only become visible once someone is writing real code.
The useEffect overuse pattern is one. This is a habit from web React that doesn't transfer cleanly to mobile. Five useEffects in one component, chained dependencies, side effects triggered in ways that create subtle re-render cascades. It works. It just doesn't work well, and the performance cost accumulates across a whole codebase.
Platform blindness is another. iOS and Android are not the same. React Native smooths over many of the differences — not all of them. Developers who code as though the two platforms are identical will ship bugs that only appear on one of them. Usually Android. Usually discovered when a user reports it rather than during development.
Then there's the dependency grab — reaching for a community library for every problem without understanding what the library is doing. This works until the library breaks on a new React Native version, or needs to be customized, or stops being maintained. The developer who understood what the library was doing can adapt. The one who treated it as a black box is stuck in a GitHub issues thread hoping someone else has the same problem.
None of this is dramatic. That's what makes it expensive. It accumulates quietly over weeks and months. The launch date slips a little. The senior developers spend time in code reviews that should be spent building. The technical debt compounds. Nobody traces it back to the hiring decision that started it.
The Interview Questions Worth Adding
Walk me through how you'd diagnose a frame rate issue in a running React Native app. What tools, what would you look at first, what are the most common causes you've seen?
How do you handle offline state in a React Native app? Not looking for a library recommendation — how do you think about the problem?
Have you worked with the New Architecture? Fabric, JSI, TurboModules — not expecting depth necessarily, but have they engaged with it at all, do they understand what problem it was solving?
Tell me about a time a feature behaved differently on iOS and Android. What was different and how did you deal with it?
These questions aren't designed to trip someone up. They're designed to create space for real experience to show itself. Developers who have it will give you real answers. Developers who don't will get vague in ways that are informative.
What The Real Cost Looks Like
Bad hire cost isn't the salary. The salary is visible, budgeted, expected.
The real cost is the senior engineer hours spent reviewing and quietly fixing decisions that should have been made correctly the first time. The launch that slips six weeks and everything that touches — customer commitments, marketing timing, competitor positioning. The performance issues discovered post-launch that require a dedicated sprint to address. The team frustration of working alongside someone who isn't delivering what the role required.
None of this shows up in the hiring decision. It shows up three months later, attributed vaguely to "the project taking longer than expected." The causal chain back to the hire is real but invisible.
When you hire React Native developers for anything with real production requirements, the evaluation needs to be calibrated to what production actually demands. Not just JavaScript ability. Not just React familiarity. Specifically — mobile depth, platform awareness, the ability to operate below the abstraction when the abstraction stops being enough.
That calibration is hard to build from scratch if you haven't run enough React Native hiring to know what the failure modes look like. It's one of the reasons working with Hyperlink InfoSystem on React Native hiring tends to produce different outcomes than sourcing from a general pool — the screening is built around what production React Native work actually requires, not just what looks good on a resume.
Getting it right before someone is three months into your codebase is always cheaper than getting it right after.
Top comments (0)