On this page
A bad React Native hire doesn't announce itself with a dramatic failure. It shows up slowly: a feature that takes three weeks instead of three days. A codebase that nobody else on the team can read. A "senior" developer who freezes the first time a native crash log appears in Xcode. An app that works on the simulator but crashes on 30% of real Android devices.
The numbers on bad hires are brutal. The U.S. Department of Labor estimates a bad hire costs at least 30% of the employee's first-year earnings. For a senior React Native developer at $150,000, that's $45,000 minimum. SHRM's research puts it higher: replacing an employee costs between 50% and 200% of their annual salary, depending on seniority and specialization. A 2024 CareerBuilder study found that nearly 75% of employers admitted to making a bad hire, with the average reported loss at $17,000 per incident. For senior technical roles, that figure climbs past $240,000.
And the cost isn't just financial. A LinkedIn survey found that 85% of hiring professionals reported that a bad hire negatively affected the entire team. Managers spend 17% of their time managing underperforming employees, time that could be spent on strategic work. Gallup's 2025 State of the Global Workplace report found that global employee engagement fell to 21% in 2024, and actively disengaged employees cost US companies $450-$550 billion annually in lost productivity.
These seven red flags show up early in the hiring process. Recognizing them before the offer saves you the cost of discovering them after.
Red Flag #1: No Live Apps in Their Portfolio
This is the single strongest filter and the one most hiring managers skip. A developer claims, "I built a social media app with React Native" or "I worked on an e-commerce platform." You ask for the App Store or Google Play link. They can't provide one.
Why this matters: Building a React Native app and shipping a React Native app are completely different levels of difficulty. The gap between "it works on my simulator" and "it's live on both stores" includes code-signing certificates, provisioning profiles, App Store review compliance, crash-reporting setup, production build optimization, and a dozen other steps that tutorial projects never cover. SHRM reports that the average time to fill a technical role is 42 days. If you spend those 42 days hiring someone who has never navigated an App Store review rejection or debugged a production-only crash, you've burned six weeks and the average $5,475 cost-per-hire before discovering the gap.
How to spot it: Ask for links to live apps during the resume screen. Not GitHub repos. Not screenshots. Apps you can download and use on your phone. If they say the app was taken down or the company shut down, ask for video recordings, client references, or detailed case studies with architecture diagrams. Legitimate developers document their work. And always verify: 85% of employers have discovered lies on resumes through background checks. In mobile development, the most common fabrication is inflating involvement on a shipped project from "I contributed a few screens" to "I built the app."
Use practical coding assessments as a second layer. Research from Codility found that candidates who complete relevant coding challenges perform 40% better in actual work than those evaluated solely through interviews. A 60-minute live coding session in which the candidate builds a real React Native component yields more than an hour of conversation about their resume.
What to do about it: If a candidate has strong technical skills in a live coding test but no shipped apps, they might be a talented junior who hasn't had the opportunity yet. That's fine for a junior hire with mentorship. It's not fine for a senior role where you're paying for production experience. Match the requirement to the role level.
Red Flag #2: Can't Explain the New Architecture
React Native 0.76 made the New Architecture the default. The old async JSON bridge is no longer available in new projects. JSI, Turbo Modules, and Fabric are the stack for any production React Native project started in 2026. React Native sees 1.6 million weekly npm downloads, and the 2024 Stack Overflow Developer Survey shows it is used by 9.14% of professional developers globally. But the fraction of those developers who have actually shipped a production Turbo Module spec from scratch is dramatically smaller than those numbers imply.
A developer who lists "senior React Native" but can't explain what JSI does, what a Turbo Module is, or how Fabric's rendering pipeline differs from the old bridge has been working on legacy codebases and hasn't kept current with the framework's most significant architectural change.
Why this matters: If your project runs on the New Architecture (or will migrate to it), this developer will be learning on your project. That learning curve isn't a week of reading docs. It involves understanding C++ JSI bindings, Codegen spec files, and Fabric's shadow tree, which are concepts that take months of hands-on work to internalize. National average React Native salary is $129,348, but senior New Architecture specialists command $145,000-$185,000, a 20-30% premium driven by scarcity. If you're paying those rates, you're paying for someone who already has that context, not someone who will acquire it on your dime.
How to spot it: One question does the work. "Walk me through the difference between a Native Module and a Turbo Module and where JSI fits." About a third of self-described senior candidates can't answer at all. Another third gives a surface-level answer that falls apart with one follow-up question ("Have you actually written a Turbo Module spec from a Codegen file?"). The final third can walk through the binding, the Codegen spec, and the lazy-loading behavior. Those are the engineers you want.
What to do about it: If your project runs on 0.73 or earlier and no migration is planned, this isn't a dealbreaker. The developer's old-bridge experience is exactly what you need. But if migration is on the roadmap, don't hire someone who will need to learn the New Architecture from scratch while simultaneously shipping features. That's two full-time jobs in one salary.
For more on what the New Architecture means for hiring, see our post on React Native's new architecture: what it means when hiring.
Red Flag #3: Expo-Only Experience for a Bare Workflow Role
Expo managed workflow and bare React Native are fundamentally different development environments. A developer who has built exclusively in Expo managed workflow has never configured a Podfile, never opened the native iOS or Android project directly, never debugged a native crash in Xcode or Android Studio, and never written or modified a native module in Swift or Kotlin.
That's a completely valid skill set for a product that lives inside managed Expo with no plans to eject. It's the wrong skill set for bare workflow, New Architecture, or any product that needs hardware integrations beyond what the expo-modules library covers.
Why this matters: The mismatch is invisible on a resume. Both developers list "React Native" as their primary skill. Both have shipped apps. The Bureau of Labor Statistics projects 17% growth in software developer employment through 2034, and React Native's cross-platform appeal means the talent pool is growing quickly. But growth in Expo-managed developers is outpacing growth in bare-workflow specialists, which makes the profile distinction more important, not less. Drop an Expo-only developer into a bare workflow codebase, and they'll hit a wall the first time they need to configure Xcode build settings, resolve a CocoaPods conflict, or debug a native module throwing a platform-specific error. The symptoms look like slow progress, frequent blockers, and an inability to solve problems independently, all of which are easy to misinterpret as laziness or incompetence when the real issue is a skills mismatch.
How to spot it: Ask directly during the screening call: "Do you work primarily with Expo managed workflow or bare React Native?" Then follow up: "Have you ever configured a Podfile? Set up a Gradle build variant? Written a native module from scratch?" If the answer to all three is no, you know the scope of their experience.
A second-stage test: "How does background processing work in React Native, and how does that change between managed Expo and bare workflow?" This question cleanly separates the two profiles. A bare-workflow developer understands the native-layer constraints on background execution. An Expo-only developer often doesn't know they exist.
What to do about it: Put your workflow in the job description. State "bare React Native" or "Expo managed" explicitly. This single line filters out the mismatch before anyone applies. For more on this, see our post on Expo vs. bare React Native.
Red Flag #4: Buzzword Answers Without Specifics
You ask about their architecture approach. They say, "I follow clean architecture with SOLID principles, microservices, and agile methodology." You ask for an example from a project they actually built. Silence. Or they give a vague description that could apply to any framework in any language.
Why this matters: React Native development involves specific, concrete decisions. Which navigation library and why? How to structure the file system for a cross-platform project. Where to put business logic versus UI logic. How to manage the split between JavaScript state and native state. A developer who answers in generalities either hasn't made these decisions in a real project or can't remember the reasoning behind the ones they did make. Neither is good.
How to spot it: Every question should be followed with "Give me a specific example from a project you worked on." Strong developers light up. They have stories about trade-offs they evaluated, mistakes they made, and problems they solved in unexpected ways. Weak developers deflect: "It depends on the project" or "Every situation is different." Those answers aren't wrong. They're empty.
The same principle applies to tools and libraries. A developer who says, "I use Redux for state management," should be able to explain why Redux over Zustand or Context for that specific project. A developer who can't articulate why they chose a tool probably didn't choose it. They inherited it and never questioned it.
What to do about it: Don't reject a candidate for one vague answer. Interviews are stressful, and people sometimes blank on specifics. But a pattern of buzzword answers across multiple questions is a reliable signal of surface-level knowledge. Two or three in a row, and you have your answer.
Red Flag #5: No Testing Strategy
You ask how they ensure code quality. They say, "I test manually before each release." Or "QA handles testing." Or they mention Jest but can't describe what they actually test or how their test suite is structured.
Why this matters: A developer without a testing practice ships code that works today and breaks tomorrow. Every new feature risks breaking existing functionality because there are no automated checks. The 2024 Stack Overflow Developer Survey found that 52.9% of professional developers say maintaining code quality is their top priority, yet a significant percentage of React Native codebases in production have minimal test coverage.
The data on what testing actually prevents is clear. Teams that implement regular code reviews reduce defects by over 50%. Organizations running CI/CD pipelines report a 30% increase in deployment frequency compared to manual deployment workflows. Teams using automated testing frameworks achieve 90% testing coverage rates, minimizing manual testing effort and accelerating release cycles. A developer who doesn't test isn't just creating bugs. They're creating an environment where every future developer who touches the codebase inherits their risk.
How to spot it: Ask, "Walk me through your testing strategy for a React Native app." A strong mid-level developer talks about unit tests with Jest for business logic, component tests with React Native Testing Library for user-facing behavior, and at least awareness of E2E testing with Detox or Maestro for critical flows. A strong senior developer adds CI integration (tests run on every PR), device testing matrices (physical iOS and Android devices, not just simulators), and explains the tradeoffs between test levels (unit tests are fast but don't catch integration bugs; E2E tests catch real bugs but are slow and flaky).
Then ask: "Show me a test you've written recently." A developer who writes tests regularly can pull one up in seconds. A developer who doesn't will stall.
What to do about it: For a junior hire, the absence of testing experience is normal and trainable. For a mid-level hire, it's a yellow flag: they should at least be writing component tests. For a senior hire, it's a hard no. A senior developer who doesn't test isn't senior. They're an experienced junior who has been writing untested code for a long time.
Red Flag #6: Gives Timelines Without Asking Questions
You describe a feature: "We need a user profile screen with photo upload, account settings, and a change-password flow." The developer immediately says, "I can do that in a week."
No clarifying questions. No, "Where does the photo get stored?" No, "What authentication provider are you using?" No, "Are there any existing design specs?" Just a number, delivered with confidence.
Why this matters: Accurate estimation requires understanding the scope. The Project Management Institute reports that approximately 70% of projects fail due to unclear requirements. A profile screen with photo upload could take three days if you're using a pre-built image picker with Cloudinary for storage and Firebase Auth for password changes. It could take three weeks if you need a custom camera interface with cropping, a self-hosted storage backend with image processing, and a custom password-reset flow with email verification and rate limiting. A developer who doesn't ask clarifying questions isn't estimating. They're guessing. And according to PMI's research, 31% of projects fail specifically because objectives weren't clearly defined upfront, the exact failure mode this red flag predicts.
How to spot it: During the technical interview, describe a feature with deliberately vague requirements. A strong developer's first response is questions. What does the design look like? What's the backend API structure? Are there edge cases I should know about? What platforms need to be supported? A weak developer's first response is a timeline.
What to do about it: This red flag is about process, not intelligence. Some developers have simply never worked in an environment where estimation was structured. If the candidate is strong on every other dimension, ask them to walk through how they'd scope the feature before estimating. If they can do that when prompted, they can learn the habit. If they insist on guessing even after you push for a breakdown, the problem is deeper.
Red Flag #7: Doesn't Ask About the Product or Users
The entire interview passes. The developer answers every technical question competently. They demonstrate strong React Native knowledge. You ask, "Do you have any questions for us?" They ask about salary, remote work policy, and vacation days. They never ask who uses the app, what problem it solves, what the business model is, or what the product roadmap looks like.
Why this matters: A developer who never asks about the product will build exactly what you specify in the ticket, and nothing more. They won't push back on a feature that doesn't make sense for users. They won't suggest a simpler implementation that achieves the same business goal. They won't notice when a design decision creates a terrible user experience. They'll write technically correct code that misses the point.
The data backs this up. Glassdoor research indicates that 77% of recruiters believe company culture is vital for employee retention. A separate study found that 46% of new hires fail within 18 months due to cultural mismatch rather than technical inability. In React Native teams, "cultural mismatch" often manifests as a developer who writes isolated code without understanding how it connects to the product experience, who treats tickets as output targets rather than user problems to solve, and who never contributes to product discussions because they don't see it as their job.
The best React Native developers care about what they're building, not just how they're building it. They ask about user personas, growth metrics, competitor positioning, and why the last feature didn't work as expected. They understand that their code exists to serve a business outcome, and they make better technical decisions as a result.
How to spot it: Pay attention to the questions they ask throughout the interview, not just at the end. During the technical portion, a product-minded developer asks, "What does the user see when this fails?" instead of just "What's the error format?" During the architecture discussion, they ask "How many concurrent users are we expecting?" instead of just "Which database should I use?"
What to do about it: For a short-term contract or a purely technical feature build, product curiosity is nice-to-have but not essential. For a long-term hire who will be shaping the product, it's non-negotiable. The developers who build the best apps are the ones who understand why they're building them.
The Hidden Red Flag: Choosing Cost Over Quality
This isn't a red flag you spot in the candidate. It's a red flag in your own hiring process. Focusing solely on cost compromises quality every time. Teams that optimize for the lowest hourly rate consistently pay more in total project cost than teams that pay market rate for experienced developers.
Before you anchor to the cheapest option, consider industry salary benchmarks. The table below summarizes average hourly rates for React Native developers based on experience, drawn from Glassdoor, and the Stack Overflow Developer Survey:
| Experience Level | Average Hourly Rate (USD) | What You Can Expect |
|---|---|---|
| Junior (0-2 years) | $25-$50 | Needs guidance. Can build screens from specs. Cannot architect or deploy independently |
| Mid-Level (2-5 years) | $50-$90 | Ships features independently. Handles navigation, state management, and store deployment |
| Senior (5+ years) | $90-$150+ | Architects systems. Owns New Architecture migrations. Mentors team. Debugs native crashes |
Paying below these benchmarks for a given experience level is possible, but the tradeoff is real. A high-quality application built by skilled developers leads to a 50-70% decrease in future maintenance and support costs. The upfront expenditure on proficient talent pays for itself by minimizing long-term issues. Customer satisfaction rates are also significantly higher when a project is developed by experienced engineers, because polished performance and fewer bugs directly affect app store ratings, retention, and revenue.
Here's what the cost-vs-quality tradeoff looks like across a full project lifecycle:
| Criteria | Low-Cost Developers | Skilled Professionals |
|---|---|---|
| Initial cost | Lower rate | Higher rate |
| Quality of work | Variable quality. Inconsistent patterns, minimal testing | Consistent high quality. Clean architecture, tested, documented |
| Time to market | Longer due to fixes, rework, and back-and-forth | Quicker with fewer issues and revision cycles |
| Future maintenance costs | Higher costs. Technical debt accumulates from day one | Reduced costs. Maintainable code saves 50-70% on ongoing maintenance |
| Customer satisfaction | Lower satisfaction. Bugs and performance issues erode user trust | Higher satisfaction. Polished, performant app from launch |
Investing in experienced developers doesn't just enhance product quality. It significantly influences market reception. According to research by the Project Management Institute, projects with skilled teams are 50% more likely to be successful. That data underscores the risk of prioritizing cost over capability. The long-term benefits of paying market rate, faster delivery, lower maintenance, higher retention, and better user experience, consistently outweigh the short-term savings of a cheaper hire.
This isn't an argument against hiring from cost-effective regions. Eastern European and Latin American developers offer senior-level quality at $55-$90/hr, well below US rates. The mistake is hiring a $25/hr developer for a $90/hr role and expecting the same output. For a full regional cost breakdown, see our React Native developer cost guide.
What Happens After You Hire: Onboarding Red Flags
Even a great hire can fail if onboarding is poor. 33% of new employees feel overwhelmed when adequate training isn't provided, leading to a 24% increase in early turnover. Gallup reports that organizations with strong onboarding programs see 50% greater new hire retention, while companies with regular feedback practices experience 14.9% lower turnover rates.
For React Native developers specifically, onboarding failures look like this: no architecture walkthrough, no access to Figma designs, no documentation of the branching strategy, and no paired PR review on the first task. The developer spends their first two weeks guessing at conventions instead of shipping code.
Our step-by-step hiring guide includes a day-by-day onboarding checklist that prevents these failures.
How to Use These Red Flags
No candidate is perfect. One red flag in isolation doesn't disqualify someone. Here's how to weight them:
| Red Flag | Junior Hire | Mid-Level Hire | Senior Hire |
|---|---|---|---|
| No live apps | Expected. Evaluate via live coding test | Yellow flag. Should have at least 1-2 shipped apps | Dealbreaker. Can't claim senior without production experience |
| Can't explain New Architecture | Expected. Not required at this level | Yellow flag if your project is on 0.76+ | Dealbreaker if migration is on your roadmap |
| Expo-only for bare workflow role | Depends on your stack | Dealbreaker if your project requires native module work | Dealbreaker. Period |
| Buzzword answers | Yellow flag. Might just be nervous | Red flag. Should have concrete project stories by now | Dealbreaker. A senior who speaks in generalities isn't senior |
| No testing strategy | Expected. Trainable with mentorship | Red flag. Should be writing component tests at minimum | Dealbreaker. Untested code at scale is a liability |
| Timeline without questions | Common in early career. Coachable | Red flag. Should know to scope before estimating | Dealbreaker. This is project management basics |
| Doesn't ask about product | Not a concern for task-level work | Yellow flag for ongoing roles | Red flag for any role with product influence |
The pattern that should concern you most isn't any single red flag. It's multiple red flags appearing together. A developer who gives buzzword answers, has no live apps, and gives timelines without asking questions is telling you a consistent story about their experience level, and that story doesn't match their resume.
For the full hiring process including interview questions, screening frameworks, and onboarding, see our step-by-step hiring guide. For interview questions that specifically test for each of these red flags, see our React Native interview questions guide.
What to Do Next
The best way to avoid red flags is to never encounter them. At Hire React Native Developers, every developer on our platform has already been vetted through a 5-stage process that screens for all seven of these red flags. They've shipped live production apps, demonstrated depth in New Architecture, and passed live coding assessments on real-world React Native tasks.
Vetted senior developer in your team within 5 days. 2-week risk-free trial. If they're not the right fit, you pay nothing.
