Master React (Beginner to Shipped Product)

Proof required

Submit: the GitHub repository URL and the live deployment URL; a 100-word description of what the app does and who it is for; and a brief explanation (2–3 sentences) of the state management approach you chose and why.

What gets checked

• Live deployment is accessible without authentication — a reviewer must be able to interact with the app without asking for a login or local setup
• At least 5 components are visible in the source code, each with a clear single responsibility — 5 divs wrapped in components named Component1–5 does not count
• Async data operation is real: a network request or a simulated delay that resolves, not a hardcoded array in JSX

Common mistakes

• Copying a tutorial project without modifying the domain or the problem — the app must solve a problem the submitter chose, not the tutorial author
• Building locally but not deploying — without a live URL the reviewer cannot interact with it, and deployment is a fundamental real-world skill
• Mixing all state into a single top-level component rather than thinking about where state belongs — the 'why' question in the proof prompt should expose this

Resources

What a verifier looks for

• Interact with the live deployment — check that async data loads correctly and that UI state updates predictably on user interaction
• Ask the submitter why they chose their state management approach over alternatives — a confident specific answer shows genuine understanding; 'the tutorial used it' does not
• Ask about a component boundary decision: why is this one component and not two? A thoughtful answer shows they understand single-responsibility
• Look for prop drilling in the source code: if state is passed more than 2 levels deep without context, ask whether they considered context and why they chose not to use it

You'll sign in first, then come straight back here.

Proof required

Submit: the updated repository with test files visible; the live deployment URL; a README section covering: the auth provider used, a description of each test with what it covers, and a before/after table for your performance optimisation showing the metric and the change.

What gets checked

• Tests are real: they run with `npm test` or equivalent, they pass in CI or locally on a clean install, and at least one tests a non-trivial behaviour (not just that a component renders)
• Performance optimisation is measured with a tool: a Lighthouse score screenshot before and after, a bundle analyser output, or a React DevTools Profiler trace — a claim without evidence does not count
• Authentication actually works: a reviewer must be able to sign up, see personalised data, and sign out — a UI that accepts any password is not authentication

Common mistakes

• Adding tests that only check that components render without error — these tests pass trivially and catch nothing; tests must assert specific behaviour
• Running Lighthouse once at the end and claiming any score as a 'before/after' — before requires a measurement before the change, not before the final deploy
• Using an auth library without understanding the token flow — the M3 reviewer will ask about it, so know what happens between login and an authenticated API call

Resources

What a verifier looks for

• Run the test suite: confirm tests pass and that at least one tests a real behaviour (a state change, an API interaction, a conditional render)
• Try to break authentication: sign up with duplicate credentials, try an expired session, sign out and confirm the protected data is gone
• Ask the submitter to explain the before/after performance change: what metric, what caused the improvement, and how they measured it
• Ask what they would test next if they had more time — a good answer names a specific behaviour or edge case, not just 'more coverage'

You'll sign in first, then come straight back here.

Proof required

Submit a session record containing: the reviewer's name and a verifiable credential showing 3+ years of professional React experience; the specific hypothetical or 'why' question they posed that you found hardest to answer; and a 200-word post-session write-up naming two specific architectural improvements and your response to each.

What gets checked

• Reviewer credential shows 3+ years of professional React experience: a LinkedIn profile or GitHub contribution history showing production React work, not just personal projects
• Hardest question is documented specifically: the actual question, not a paraphrase — and an honest account of the answer given, even if the answer was incomplete
• Two architectural improvements are specific: 'restructure the global state' is too vague — a real improvement names which state, why it is a problem, and what the fix would be

Common mistakes

• Presenting only the working parts and avoiding discussion of the areas you are unsure about — a good reviewer will find them regardless, and presenting them proactively shows maturity
• Choosing a reviewer who has only used React in tutorials or bootcamp projects — 3+ years professional experience means production apps with real users and constraints
• Writing the post-session write-up as a description of the app rather than a reflection on what the review revealed — the write-up should convey what the submitter now knows that they did not know before

Resources

What a verifier looks for

• Confirm the reviewer's React experience is professional and recent — a LinkedIn role showing React in the tech stack and at least 3 years in that role
• Ask the submitter to describe the hypothetical question posed and their actual answer — if they cannot recall the question specifically, the session details may have been reconstructed
• Ask what the reviewer said about the testing approach — a senior reviewer will always have a specific opinion on how the tests are structured
• Ask which of the two architectural improvements they have already acted on — at least one should show up in a commit after the session date

You'll sign in first, then come straight back here.