1 – Define what you are actually assessing before launching a technical test
A React technical test without a scoring framework is wasted time on both sides. Before sending anything to the candidate, you need to lock down three elements: the actual technical scope of the role, the elimination criteria, and the acceptance threshold. Without these, you will assess by gut feeling, and gut feeling does not scale.
1.1: Map your real front-end stack, not a wishlist
Open your package.json. List the dependencies actually used in production. That is your specification, not a job description copied from LinkedIn. If your app runs on React 18 with Zustand, React Query, and Tailwind, you do not need to test Redux Saga. If you use Next.js with SSR, the candidate must demonstrate they understand the server rendering cycle, not recite the Create React App documentation.
Create a one-page document with three columns: "essential from day 1" (what is in production), "required within 30 days" (what is coming in the roadmap), "bonus" (what would be appreciated). Column 1 defines your elimination criteria. Column 2 defines the upskilling potential. Column 3, you ignore during the assessment.
This work takes 20 minutes if you know your own code. If you do not, that is a signal: you need cartographier vos processus internes avant d'externaliser quoi que ce soit.
1.2: Separate elimination criteria from progression criteria
Every technical assessment must distinguish what is a dealbreaker from what can be learned in two weeks. A React developer who does not understand the component lifecycle, who mutates state directly, or who has never touched a custom hook: elimination criteria. A developer who does not know your CSS naming convention or has never used Storybook: trainable within a few days.
The elimination criteria for a React front-end role in 2025 fit on a short list. Mastery of fundamental hooks (useState, useEffect, useRef, useCallback, useMemo). Understanding of conditional rendering and lists with keys. Ability to structure reusable components with typed props. Basic async handling (fetch, promises, error handling). Reading and writing TypeScript if your project uses it.
Everything else (specific state management libraries, testing frameworks, CI/CD tooling) falls under upskilling. Confusing the two means eliminating solid profiles for cosmetic reasons.
1.3: Set a numbered acceptance threshold before reading the first line of code
Before receiving any deliverable, write your scoring grid. Not after. Before. Each criterion receives a score from 0 to 3. 0: absent. 1: understood but poorly executed. 2: functional and clean. 3: elegant, well-structured, with edge case handling. Set a minimum global score and a minimum score per elimination criterion.
Concrete example: across 8 criteria, maximum score of 24. Acceptance threshold at 16. No elimination criterion below 2. This framework prevents two common biases: confirmation bias ("they seem nice, I will give them a good score") and excessive-demand bias ("nobody reaches 24, we keep searching").
Share this grid with everyone involved in the assessment. If your lead dev and you are both evaluating, you must score independently and then compare. That is the only way to achieve reproducible hiring, especially when you are hiring remotely a développeur front-end offshore you will never meet in person.
2 – The 48h technical test: format, content, and signals to watch
A technical test for an offshore React developer must be completable in 3 to 4 hours, deliverable within 48 hours, and assessable in 30 minutes. Longer, and you lose the good candidates. Shorter, and you see nothing. Here is how to structure each step.
2.1: The 3h asynchronous test: a mini-project mirroring your reality
Forget multiple-choice quizzes and LeetCode algorithms. You are looking for a front-end developer capable of delivering interfaces, not an algorithmics researcher. Build an exercise that resembles what the candidate will actually do. Take a simple feature from your product (or a simplified version of it) and ask them to recreate it.
A solid 3-hour React test: consume a REST API or a JSON mock, display the data in a filterable list, handle a loading and error state, allow a user action (add, delete, edit). Provide a boilerplate with your actual stack (Vite + React + TypeScript if that is what you use). Add a README with precise instructions, the expected output as a wireframe or screenshot, and the evaluation criteria.
Give exactly 48 calendar hours. The candidate organises their time as they see fit. This format respects timezone differences (negligible between France and Madagascar, but the principle holds for your future processes) and filters out profiles who cannot deliver within a deadline.
2.2: The 45-minute live coding session: what the asynchronous code does not reveal
The asynchronous test shows the result. The live coding shows the reasoning. After receiving the test, schedule a 45-minute video session. The first 15 minutes: the candidate presents their code, explains their architecture choices, justifies their trade-offs. You observe their ability to verbalise in French (a non-negotiable criterion for a dedicated developer integrating into your team on a daily basis).
The next 20 minutes: you request a modification in real time. Add a filter, change the API response structure, introduce an edge case. You are not looking for perfection. You are looking for method. Do they read the error in the console before searching on Google? Do they break down the problem or dive in headfirst? Do they ask clarifying questions?
The final 10 minutes: open questions. How would they handle caching for this request? What would they do if this list contained 10,000 items? These questions reveal technical depth beyond the delivered code. A profile who answers "I would use React Query with a staleTime" or "I would virtualise the list with react-window" knows what they are talking about. A profile who hesitates on fundamental concepts after delivering a clean test has probably been assisted by AI.
2.3: The 6 warning signals to detect during the assessment
First signal: the code works but no component has been split out. Everything in a single 400-line file. This developer will produce technical debt from sprint 1. If you want to understand why this is critical in a remote context, read our article on comment éviter la dette technique offshore dès le premier sprint.
Second signal: no error handling. The happy path works; everything else fails silently. Third signal: npm dependencies added for trivial tasks (an entire library just to format a date, for example). This betrays a lack of native JavaScript mastery.
Fourth signal: the candidate cannot explain their own code live. Intelligent copy-paste of AI-generated code without real understanding. Fifth signal: no questions asked about the instructions. A good developer clarifies grey areas. An executor guesses and delivers something off-target. Sixth signal: the code completely ignores TypeScript typing (if required) or uses "any" everywhere. This profile will not save you time — it will cost you time in code review.
3 – Integrating the developer into your stack in 5 days, not 3 weeks
The test is done, the profile is validated. What remains is the classic trap: an onboarding that drags on, a developer waiting for access, introduction meetings that lead nowhere. Here is how to make an offshore React developer operational in 5 working days.
3.1: Day 1 and Day 2 — access, environment, and first commit
Before day 1, everything must be ready. Git access (with the right permissions on the right repos), access to Jira or your ticketing tool, access to Slack or Teams, access to the staging environment. If you lack a method for this, our guide on gestion des accès et droits informatiques pour une équipe offshore covers every step.
Day 1: the developer clones the repo, installs the dependencies, and runs the project locally. Their end-of-day objective: the project is running on their machine and they have read the README (you do have one, right?). Day 2: first ticket. Not a critical ticket. A minor bug or a cosmetic improvement. The objective is not value delivery — it is completing the full cycle: read the ticket, create a branch, code, push, open a pull request. This first commit validates that the entire technical chain works and that the developer knows how to navigate your workflow.
At Taram, every integrated developer works on the client's infrastructure (client Git, Jira, and Slack) from day one. No intermediate environment, no technical proxy. The developer is in your team, full stop.
3.2: Day 3 and Day 4 — progressive ramp-up with systematic code review
Day 3, the developer picks up a real functional ticket. A medium-complexity feature: a form with validation, a display component with filters, an API endpoint integration. The deliverable goes through code review before merging. This is where you calibrate the real level under production conditions.
The day 3 code review is your true moment of truth. You see whether the developer respects your conventions (or adapts quickly to feedback), whether they structure their components consistently with the existing codebase, and whether they handle edge cases. Document your feedback in the pull request, not verbally. Every written comment becomes a reference for future contributions. To structure this mechanic remotely, our code review asynchrone protocol covers formats and tooling.
Day 4: second ticket, similar or slightly higher complexity. The code review should show a reduction in feedback compared to day 3. If the developer repeats the same mistakes despite explicit comments, that is a signal. A good profile integrates feedback immediately.
3.3: Day 5 — controlled autonomy and first velocity checkpoint
End of the first week. The developer must be able to pick up a ticket, handle it end to end, and open a pull request without assistance. No complex ticket at this stage, but real production tickets that move your roadmap forward.
Hold a 30-minute check-in at the end of day 5. Three questions. What blockers did you encounter? Which parts of the codebase are still unclear? What do you need to double your velocity next week? The answers will tell you whether the profile is on the right trajectory or whether an adjustment is needed.
Measure concrete output: number of tickets handled, number of code review comments, average time between opening a ticket and the pull request. These metrics become your baseline. Week 2, you expect a 30 to 50% improvement. Week 3, the developer should be at cruising speed. Three weeks of onboarding is what others sell you. Five days with a structured process is what it actually takes when the technical hiring was done seriously upfront.
Your next sprint starts without this developer
Every week without an extra pair of hands on your front-end is a feature that does not ship, a client who waits, and a competitor who moves forward. You now know the method: scoring grid before the test, mini-project mirroring your real stack, live coding to validate reasoning, integration in 5 days with code review from day 3. The process exists. French-speaking React profiles in Madagascar exist. The only missing variable is your decision. Taram recruits, tests, and integrates a front-end developer dedicated exclusively to your team. One developer, one client, zero resource sharing. While you are re-reading this article, someone else is signing.
