A Fair Take-Home Assignment for Hiring React Native Developers

Take-home assignments have a bad reputation, mostly earned. Candidates get a vague brief, an unspoken expectation of twenty hours of unpaid work, and a rejection with no feedback, graded on whether they picked the reviewer's favourite state library. Strong engineers with jobs and families quietly drop out, and the process selects for free time rather than skill.

A fair React Native take-home assignment does the opposite. It's short, clearly scoped, close to the real job, scored against a rubric the candidate sees in advance, and followed by a conversation about the decisions behind it. This guide gives you the principles, a brief you can copy, a scoring rubric, a follow-up interview plan, a variant for senior roles and a clear policy on AI tools.

Key takeaways

• Time-box it to about three hours, and pay candidates if it needs to be longer.
• Share the scoring rubric up front, so candidates know what matters and what doesn't.
• Test everyday work: data loading, loading, empty and error states, a mutation, a test and written trade-offs.
• Follow up with a conversation about decisions and a small live extension; it reveals understanding and discourages copying.
• State your AI tools policy clearly. Allowing tools with disclosure is usually fairer and closer to real work.

Principles of a fair take-home

1. Respect time. Three hours of focused work is plenty to see how someone builds. If you need more, pay for it.
2. Make it realistic. Use the kind of feature your team builds, not an algorithm puzzle.
3. Provide a starter. A blank Expo project and a mock API remove setup busywork and level the field.
4. Be explicit about scope and what to skip ("no need for pixel-perfect styling").
5. Share the rubric. Hidden criteria reward guessing, not skill.
6. Offer an alternative, such as a paired session or walking through existing code, for candidates who can't take time out.
7. Give feedback. A few sentences of honest feedback respect the hours they spent.

The brief (copy and adapt)

# Take-home: class schedule

## Context
You're building part of a fitness app. Members browse this week's classes
and book a spot. We've provided an Expo starter and a mock API.

## What to build (about 3 hours)
1. A list of this week's classes from GET /classes, with loading,
   empty and error states, and pull to refresh.
2. A class detail screen with instructor, time and spots left.
3. A "Book" button using POST /bookings. Show the result immediately,
   handle failure (the API returns 409 when the class is full) and
   keep the list in sync.
4. At least one component test for the booking flow.

## Constraints
- TypeScript. Any state or data library you like.
- No need for custom styling beyond clear, accessible layouts.

## Deliverables
- A repository link.
- A README with how to run it, the decisions you made, the trade-offs,
  and what you'd do next with more time.

## AI tools
Allowed. Tell us in the README which tools you used and for what.
We'll discuss your code in a follow-up call.

The mock API matters. Serve fixed data from a small mock server (JSON Server works) or mock requests in the app with Mock Service Worker, and make it deliberately imperfect: add latency, an occasional 500 error and a 409 when a class is full. That's where real skill shows.

The scoring rubric

What isn't on the rubric matters too: no points for a particular library, for visual polish beyond clarity, or for extra features outside the brief.

Calibrate your reviewers first

Before any candidate sees the exercise, have two engineers on your team complete it within the time box. You'll learn whether three hours is realistic, which parts of the brief are ambiguous, and what a strong submission looks like at your company. Then, for every candidate, have two reviewers score independently against the rubric before discussing. Independent scoring stops the first opinion in the room from setting everyone else's, and comparing scores across a few hires shows whether the rubric actually predicts who does well in the job.

The follow-up conversation

Book 45 to 60 minutes with two engineers:

1. Walkthrough (15 minutes): the candidate explains their structure and the decisions in their README.
2. Probing questions (15 minutes): "What happens if the booking request times out?" "How would this work offline?" "Where would you add analytics?"
3. Small live extension (15 to 20 minutes): add pagination, a filter or a cancel booking action, talking through it.
4. Their questions (10 minutes).

The conversation shows whether they understand their own code, how they reason under gentle pressure and how they collaborate, which a repository alone can't.

A variant for senior roles

For senior candidates, add judgement rather than more code:

• A pull request review: give them a 200-line pull request with a few real problems (a missing error state, a re-render issue, a security slip, a breaking API change) and ask for review comments.
• A production scenario: a crash report with a stack trace and breadcrumbs, plus "the rollout is at 20%; what do you do?"
• An architecture discussion: "This app now needs offline booking and a staff app. What changes?"

Keep the total time similar. Senior signal comes from decisions and communication, not from building twice as much.

A clear policy on AI tools

Engineers use AI assistants at work, so banning them in a take-home tests something your team doesn't do. A fairer policy: tools are allowed, candidates say what they used and for what, and the follow-up conversation checks that they understand and can extend the code. If you do ban them, say so explicitly, and expect the same honesty from your own process.

From the field: This exercise mirrors everyday React Native work of the kind I've done across 50+ apps shipped to the stores over 7+ years: data states, optimistic updates with error handling, a test that guards the risky path, and a written note on trade-offs. If a take-home doesn't look like the job, it doesn't predict how someone will do the job.

Common mistakes to avoid

• Multi-day unpaid projects, or briefs that look suspiciously like a real production feature.
• Hidden criteria, such as expecting tests or a particular architecture without saying so.
• Grading on taste: library choices, folder names, formatting.
• No follow-up, which makes copied work hard to spot and good decisions easy to miss.
• No feedback after hours of a candidate's time.
• Different exercises for different candidates, which makes comparisons unfair.

FAQ

How long should a React Native take-home assignment take?

Around three hours of focused work is enough to see how someone handles data, states, structure, testing and communication. If your exercise needs more time, shorten it or pay candidates for their time.

Should take-home assignments be paid?

Short, clearly time-boxed exercises are commonly unpaid, but anything beyond a few hours should be paid. Paying for longer work, or offering a paired session as an alternative, keeps strong candidates with limited free time in your process.

Should candidates be allowed to use AI tools in a take-home?

Usually yes, with disclosure, because engineers use these tools at work. The follow-up conversation and a small live extension then check that the candidate understands the code and can change it. Whatever your policy, state it clearly in the brief.

What should a take-home test for a senior React Native developer?

Judgement as well as code: handling of failure states and edge cases, structure and typing, a meaningful test, and clear written trade-offs. Add a pull request review, a production incident scenario or an architecture discussion rather than a longer build.

Next steps

If you're hiring for a React Native role, or want a senior engineer who can set up a fair hiring process for your team, see my résumé, or get in touch.

Sources

• Use structured interviewing, Google re:Work
• create-expo-app, Expo documentation
• JSON Server, GitHub
• Mock Service Worker, MSW
• React Native Testing Library, Callstack