❯ Outlier React screening prep

Updated 2026-09-13 · every claim carries an evidence grade; sources at the end.

Outlier’s React screening is a per-skill gate on an AI-training platform, not an engineering interview. That changes what to study. The questions still cover hooks, rendering and state, but the skill the screening exists to predict is reviewing AI-generated front-end code against a rubric and saying precisely what is wrong with it. This page gives you what is publicly known about the format, the rules that fail more people than the content does, the review method itself, and a six-day plan that runs on the React and JavaScript & TypeScript tracks on this site.

One honesty rule up front: every claim below is marked strong, medium or weak. Outlier states none of the numbers people most want — how many questions, how long, what score passes, when you may retry — so this page does not invent them either.

How the screening works, as far as the evidence goes

Two gates, not one (strong). Outlier’s FAQ describes onboarding as platform onboarding first — account, expertise selection, skill screenings, identity check — then project qualification, where you review a project’s guidelines and complete its assessment tasks, then tasking. The FAQ’s “typically takes 30 to 90 minutes” is the whole platform-onboarding stage, not a screening timer. Project qualification has no published length, is unpaid or paid at a lower onboarding rate (medium), and passing it still does not guarantee front-end work: many contributors report months without a project after clearing every screen (strong).

One screening per skill (medium-strong). HTML, CSS, JavaScript, TypeScript and React each carry their own badge, and the result sets a tier that feeds your rate. A bundled “Frontend Development” screen granting several badges at once was reported in early 2025; whether it still exists is unconfirmed.

What the front-end screen contained (medium — one first-hand breakdown, April 2025): several multiple-choice questions, then three or four recorded video answers where you explain a concept in depth with examples, camera and microphone on, then three or four tasks that evaluate and rewrite short JavaScript snippets. Later accounts (December 2025) describe the React and HTML screens as leaning further toward talking to the camera. Whether the React screen contains code-output or algorithm items is not established.

What the JavaScript screen contained (strong — several accounts): “what does this code print” questions answered in a text box, debugging and correcting a given snippet, and occasionally two small algorithm problems, all in a browser editor with copy, cut and paste disabled.

Timing and grading (medium). Every screen is timed and described as tight, with per-item timers on the video questions. Grading is automatic; the pass or fail arrives instantly with no feedback. The 80% pass mark that circulates rests on one fail notice for HTML/CSS and third-party blogs (weak).

Rules that fail people before the content does

These come from Outlier’s Terms, its Community Guidelines (effective 2026-05-11), a community manager’s statements, and repeated first-hand reports. Treat every one as binding.

• One account, ever (strong). A second account after a fail or suspension breaches the Terms; people have lost both.
• Camera and microphone on for the whole attempt (strong). If any part cannot be completed — a video that will not record, a dropped connection — no accurate attempt is recorded and it counts as a fail. Support may not unlock a rescreen.
• No paste, no keyboard shortcuts, no other windows (medium-strong). The editor blocks copy, cut and paste. Tab-outs, pasted question text, IDE autocomplete and eye movement that reads as looking at another screen have all produced fails, and in several reports permanent deactivation with appeals denied. One window, nothing else open, eyes on the screen.
• Work alone (strong). No second person, no scripts, no third-party tools; sharing task content is prohibited.
• Three skill assessments per rolling thirty days (medium-strong, unofficial). Spend them only on skills you genuinely work in — failing many is reported to risk the account.
• Retakes: unknown (weak). Reports range from fourteen days to never. The only official wording is that the system allows a retake “once the necessary amount of time has passed”. Prepare as if you have one attempt.

The job behind the screening: reviewing AI code against a rubric

Outlier’s own description of the front-end role is reviewing and evaluating code generated by AI in JavaScript, React and similar frameworks, and assessing the UI/UX quality, accessibility and design choices that code makes (strong — job posting). Its blog frames the contribution as spotting where the model gets it wrong: a rendering bug, misuse of state, a missing alt attribute, an unnecessary re-render, inconsistent indentation, an unhandled edge case (medium — recovered from search snippets). Project tasks reported first-hand match that: rate a generated UI for functionality and visual quality on a scale, pick the better of two responses, rank two or three, rewrite a golden response as one self-contained file, write a prompt no one else has written.

The method is the same whatever the task shape:

1. Read the prompt twice. Once to understand the request, once to list every requirement as a checklist. Most “instruction following” misses are a requirement the model silently dropped, changed, or padded with a feature nobody asked for.
2. Score each criterion on its own. A response that is correct but unreadable is high on correctness and low on style. Averaging in your head is the error the guidance from every platform in this space warns against.
3. Quote the line. “setItems(items.push(next)) on line 14 mutates state and returns a number, so the list never re-renders” is a finding. “State handling could be better” is not.
4. Fix with the smallest complete change. A minimal rewrite that preserves the structure, delivered as runnable code — not a diff, not a fragment with “rest unchanged”.

The criteria to score separately, with what a failure looks like:

Twelve defects to train your eye on

Each of these appears in the categories Outlier names or in first-hand task reports. Practice finding them in eight minutes per component, with the line quoted and the minimal fix written out.

1. State mutated in place — items.push(x) then setItems(items): same reference, no re-render. Fix: setItems([…items, x]).
2. Stale closure — setInterval(() => setCount(count + 1), 1000) inside an effect with [] deps counts to 1. Fix: the functional updater.
3. Derived value stored in state — a total kept in useState next to the items it is derived from drifts. Compute it during render.
4. Hook behind a condition — if (user) useEffect(…) shifts every later hook’s slot. Hooks are unconditional and top-level.
5. Effect with no cleanup — a listener, interval or fetch that outlives the component. Return the unsubscribe; abort the fetch with an AbortController.
6. setState during render — an infinite loop; the value wanted was derived state or an event handler.
7. Index keys on a list that reorders or deletes — inputs keep the wrong state. Keys come from the data.
8. The 0 leak — count && <List/> renders a literal 0. Use count > 0 && or a ternary.
9. Fresh props into memo — onSelect={() => ...} or style={{...}} defeats React.memo every render.
10. Missing alt, missing label, div-as-button — the three accessibility misses every review tool catches; decorative images want alt="", not no alt.
11. ARIA that fights the element — role="button" on a <button>, aria-label on a plain span, aria-hidden on something focusable. First rule of ARIA: prefer the native element.
12. Non-runnable deliverable — bash install commands in place of code, imports of packages the prompt excluded, no default export, three files where one self-contained file was required, or hard-coded output that fakes the requested logic.

The syllabus, mapped to drills on this site

Weights are this page’s reading of the evidence, not Outlier’s — the skill that the whole job runs on gets the most time.

The mock exam and drills on this site are multiple choice; the screening also wants you to type code and rewrites without paste. Pair every drill session with hand-typed code in a plain editor with autocomplete off.

The HTML, CSS and accessibility gap

No track here covers markup and styling, and the HTML and CSS screens are reported to ask for property names and code blocks from memory. Thirty items to be able to state and type cold:

Semantics. header, nav, main, section, article, aside, footer and what each claims · one h1, headings in order, never chosen for size · strong and em carry meaning, b and i do not · button for actions, a for navigation, never a div for either · ul/ol for lists, dl for name–value pairs · table only for tabular data, with th and scope · figure with figcaption · time with datetime.

Forms and accessibility. Every input has a label via htmlFor/id or wrapping · alt describes function or content; alt="" for decorative images · required, type and autocomplete on inputs · focus-visible styling never removed without a replacement · keyboard reachable: Tab order follows DOM order, Enter/Space activate buttons · modal traps focus and returns it on close · aria-live for status messages · color never the only cue (WCAG 1.4.1) · 4.5:1 text contrast (1.4.3) · target size at least 24×24 CSS px (2.5.8) · prefer native semantics before any ARIA.

CSS. Box model and box-sizing: border-box · display: block, inline, inline-block, flex, grid, none · position: static, relative, absolute, fixed, sticky · flex: justify-content vs align-items, flex-wrap, gap, min-width: 0 to stop overflow · grid-template-columns with repeat and minmax · specificity order and the cascade · rem vs em vs px · font-weight, font-style, line-height, letter-spacing · @media (max-width) and mobile-first (min-width) · max-width: 100% on images · Tailwind reading: p-4, flex, gap-2, md:grid-cols-2, min-w-0, sr-only.

Talking to the camera

The video items ask you to explain a concept in depth with examples, timed per question. Use one shape and rehearse it until it is automatic: definition in one sentence, why it matters in one, a concrete example, the pitfall people hit. Sixty to ninety seconds. Say “I don’t know” rather than leaving an item unrecorded, because an unrecorded part is a failed attempt. Press Start Camera, then Record — one report failed because only the first was clicked. Rehearse these eight, recorded and watched back:

1. What is a stale closure in React and how do you avoid it?
2. Why do list keys matter, and why is the array index usually the wrong one?
3. What triggers a re-render, and what does React.memo actually skip?
4. Explain useEffect dependencies and cleanup with a real example.
5. Explain the event loop: microtasks, macrotasks, and where await lands.
6. What makes a form accessible?
7. When is ARIA the wrong tool?
8. How would you review an AI-generated component — what do you check first?

Six days

• Day 1 — baseline and room. Take the React mock exam cold and note the per-domain split. Run one timed pass through the JavaScript types-coercion and scope-closures drills. Read the rules section twice. Set up the exam room: one window, no second monitor, phone away, a stable connection.
• Day 2 — state and rendering. Drill hooks and rendering until misses are under one in ten. Write the rules of hooks, effect dependency and cleanup rules, key rules and controlled-input rules from memory. Five code-review reps: take five small components, plant one defect each from the twelve, and write rating, quoted line and minimal rewrite in eight minutes per component. Record video prompts 1 and 2.
• Day 3 — JavaScript by hand. Rapid practice on async-event-loop and objects-prototypes; predict console output in under a minute. Write three small array functions in a plain textarea with no autocomplete, then trace them by hand. Five debug-and-correct reps, writing the complete corrected code. Record prompt 5.
• Day 4 — markup and accessibility. Type the thirty-item flash list from memory. Build a small semantic page — nav, labelled form, image with alt, two-column responsive layout — by hand and time it. Accessibility review of three generated components, every defect quoted. Record prompts 6 and 7.
• Day 5 — performance, TypeScript, the write-up. Drill performance and server-components; state when memo, useCallback and useMemo help and when they cost. Read three .tsx components and flag typing errors. Two-response comparison reps: two versions of one component, one with an instruction miss, one with an accessibility bug — decide, criterion by criterion, with evidence. Record prompts 3, 4 and 8.
• Day 6 — dress rehearsal, then stop. Retake the React mock and one JavaScript rapid set; compare with Day 1. Run a self-made 45-minute screening in exam-room conditions: eight multiple-choice, three recorded answers, three evaluate-and-rewrite snippets, everything typed. Grade completeness, not just correctness. Sleep. Take the real screen in one sitting.

What could not be confirmed

The exact question count, overall timer, pass mark and retake window for the React screen; whether it contains code-output or algorithm items or is mostly video; whether the bundled front-end screen still exists; the rubric text and rating scale used inside evaluate-and-rewrite items; and whether any front-end project is open at the time you read this — the front-end postings seen were all closed by mid-2025 and later intake reads as general coding. If Outlier’s help center (login-gated) says otherwise, it wins over this page.

Sources

Outlier FAQ, coding landing pages, Terms of Use and Community Guidelines (fetched 2026-09-13); the mirrored “Front-End Developer Expertise for AI Training” posting (2025); r/outlier_ai first-hand threads dated April 2025 through August 2026 on the front-end, React, HTML and JavaScript screens, project onboarding, proctoring and account policy; Glassdoor, Indeed and Trustpilot assessment reviews (search snippets where the sites block fetching). Evidence grades reflect how many independent, dated accounts agree — never a single blog post.