A fair React skills test checks whether you can build and change real UI safely, not whether you can recite API trivia. You should be measured on component structure, state and effects, performance habits, and testing judgement. The best tests adapt to your level, constrain time per question, and resist memorised answer banks.
What should a React skills test actually measure?
It should measure the decisions you make while building React interfaces, not just what you remember. That means how you structure components, manage state and side effects, and keep behaviour correct as an app grows.
Most complaints about “bad React tests” come from a mismatch between the job and the measurement. A role building design-system components needs different evidence from a role maintaining a large app with messy state. A fair test still shares a core: it checks the mechanics you use every week.
Here is a practical way to describe React competence levels. Use it as a checklist for choosing a test, or for writing your own rubric.
| Area | Beginner (can follow patterns) | Intermediate (can choose patterns) | Advanced (can explain trade-offs) |
|---|---|---|---|
| Components | Composes simple components from props | Designs reusable components with clear boundaries | Shapes component APIs for teams and long lifetimes |
| State | Uses local state for UI flags and inputs | Chooses local vs lifted vs derived state sensibly | Prevents drift and duplication across complex views |
| Effects | Uses effects for data fetch and subscriptions | Avoids common effect bugs and stale closures | Builds predictable side-effect boundaries and cleanup |
| Performance | Knows memoisation exists | Spots wasteful renders and avoids them when needed | Diagnoses rendering issues and applies measured fixes |
| Data flow | Passes props down, events up | Uses context carefully when it reduces coupling | Designs stable data flow across large feature areas |
| Testing | Writes basic tests for pure logic | Tests components with meaningful user interactions | Balances unit/integration tests and reduces flakiness |
| Debugging | Uses console and React DevTools basics | Tracks bugs across components and state transitions | Explains root causes and prevents regressions |
A fair test samples across several rows, at a depth that matches the level you claim. If it only hits one row, it is really a quiz on that row.
If you want a concrete reference for what “React as a skill” covers, use the React skill page: /skills/react.
How do you tell if a React test is fair rather than “gotcha”?
A fair test makes React skill the main limiting factor. It removes advantages from memorised trivia, lucky question selection, or knowing a platform’s quirks.
You can judge fairness by looking at what the test is trying to control. In React assessments, three failure modes show up again and again.
First, the test rewards recall over reasoning. That looks like “what does this option default to” questions, where one forgotten detail sinks you. Reasoning-heavy prompts instead ask you to choose an approach and defend it, because that is what you do at work.
Second, the test confuses speed with skill. A harsh global timer pushes careful people into guessing. Per-question time limits can still create pressure, but they keep the test focused on decision quality.
Third, the test is too predictable. If everyone gets the same questions, the market shifts to memorising answers. Then the test measures who has seen it before.
Use this checklist when you compare providers, or when you design an internal test. If you need help making a rubric you can score consistently, the technical assessment template can be a useful companion: /blog/technical-skills-assessment-template.
| Fairness check | What you want | What to watch for |
|---|---|---|
| Measures reasoning | Prompts that require choosing between approaches | Pure definition or “name the API” prompts |
| Samples breadth | Components, state, effects, testing and debugging | Only hooks trivia or only DOM knowledge |
| Controls time realistically | Time pressure per decision | One big countdown that rewards rushing |
| Resists memorisation | Different paths per person and question rotation | Everyone gets the same fixed set |
| Has human review paths | A way to understand unusual attempts | Fully automated decisions with no appeal |
A test can be fair and still not be right for your use. For example, fixed tests can be good for standardised comparison, and take-homes can be good for seeing real code structure. The question is what kind of evidence you need.
Should a React skills test be adaptive?
Yes, when your goal is to estimate level efficiently and reduce trivia. Adaptive testing changes question difficulty based on your answers, so you spend less time on items that are clearly too easy or too hard.
The mechanism is simple. Questions are organised by difficulty and topic. Your earlier answers influence what comes next. Over a sequence of questions, the test converges on a stable level.
Lemma’s adaptive assessments follow that pattern. They run on a 1 to 10 difficulty scale, ask between 15 and 25 questions, and stop once your level holds steady. You pass at 6.5 out of 10. Each question has a time limit, and you cannot change an answer after submitting it. You can read the product description here: /product/assessments.
Adaptive does not automatically mean “best for every purpose”. Fixed tests can be easier to debrief because everyone saw the same material. Adaptive tests are usually better at placing someone accurately without padding the experience with too-easy questions.
| Test style | Good for | Trade-off to accept |
|---|---|---|
| Adaptive questions | Fast level placement across mixed ability | Less shared “same questions” discussion |
| Fixed question set | Standardised comparison and debrief | Easier to memorise and coach to |
| Take-home project | Seeing real code structure and writing style | Harder to control authorship and time spent |
| Live interview task | Watching debugging and communication | Interviewer variance can dominate outcomes |
If you use more than one method, make the join explicit. For example, let the test place level, then use an interview to explore trade-offs. A structured interview guide helps keep that part fair too: /blog/assess-technical-skills-in-interview.
What React topics separate levels in practice?
The separations show up in how you prevent mistakes, not in how many APIs you know. A good test probes for the points where React work tends to go wrong.
Components: boundaries and data shape
Beginners often build “one component per screen” and pass props down because it works. Intermediate developers refactor around responsibilities because it limits blast radius. Advanced developers design component APIs that prevent misuse, because those choices compound over time.
A fair question here looks like a refactor. Example: you need to reuse a component in three contexts, each with slightly different behaviour. What do you extract, what do you keep, and what do you explicitly not generalise yet?
State: derived data and synchronisation
Many React bugs come from duplicating the same fact in two places. Another common issue is storing derived data instead of deriving it, then forgetting to update it.
A good test does not need to force a specific state library. It can ask you to choose between local state, lifting state, or using context, and to name the failure mode you are avoiding.
Effects: predictable side effects
Effects are where otherwise strong developers still trip. Cleanup, timing, and stale values all matter.
A fair prompt forces you to reason about when something runs and how it stops running. You are being tested on predictability, not on remembering a slogan about dependencies.
Performance: measured restraint
Performance skill in React is often knowing when not to optimise. Memoisation and caching have costs, and they can hide bugs.
So a fair test checks whether you can identify when performance work is justified, and choose a small, safe fix. If the question expects optimisation everywhere, it is training bad habits.
Testing: confidence in behaviour
React testing is about user-observable behaviour. A test suite that asserts implementation details can still miss real regressions.
A useful test asks what you would test first and why. It probes whether you can pick stable selectors, write meaningful assertions, and avoid brittle tests.
What time limits and integrity rules keep a React test honest?
Per-question timing and clear integrity rules keep the measurement focused. They reduce the benefit of searching for every answer while still allowing careful thinking.
On Lemma, each person takes a different path through an adaptive assessment, and recently seen questions are not served again. Tab switches, paste events, and developer tools use are logged. If something looks unusual, it is flagged to a person for review, and the flag does not automatically cut a score. This is part of the assessment design described on /product/assessments, and it fits the broader “evidence, not claims” approach in /methodology.
It is worth asking any provider how review works. Automated signals can be noisy. Human review gives room for honest explanations, like assistive tech, a crash, or a genuine mistake.
Another fairness detail is what happens after a failed attempt. If there is no cost at all, people can keep retrying until luck carries them. If the cost is too harsh, one bad sitting becomes a permanent label.
In Lemma’s SCI scoring, assessments contribute to the Proof part of the SCI score for a skill. A certification assessment can earn up to 15 points and a skill assessment up to 12, and only the higher counts. Failed attempts cost 2 points each, capped at 6 in total, and retakes have a cooldown. You can read the SCI overview on /product/sci, and how the score is explained to a reader in /blog/how-sci-works.
How should you use a React skills test result in hiring or verification?
Use it as one piece of evidence, not as the whole decision. A React test is good at checking React knowledge under controlled constraints, but it is weaker at showing teamwork, communication, and long-term codebase judgement.
The mechanism that makes a test result more useful is traceability. You want to see what was tested, under what rules, and when the result happened. That helps you interpret the score alongside other evidence, rather than treating it as a final verdict.
If you want a way to present evidence beyond a single score, Lemma’s Skills Passport groups evidence from assessments, live sessions, AI tutor practice, and connected work into skill records. Each skill shows its SCI score and the drivers behind it, and the Passport document is signed so a reader can confirm Lemma issued it and it has not changed since. The evidence underneath is append-only, with corrections, revocations, and disputes recorded as new events rather than erased. Background is on /product/passport.
For hiring, a balanced bundle of signals is usually clearer than any single test:
- A React test to place level and surface obvious gaps.
- A structured discussion to explore trade-offs and debugging.
- Work evidence you can attribute to the person, to show habits over time.
If you want the “why” behind using evidence this way, the skill verification primer is a good frame: /blog/what-is-skill-verification.
ChatGPT
Claude
Perplexity
