Get started

Taking an assessment rather than buying one? This page is written for employers. Here is the page for candidates.

Software engineering · Mid level

How to assess a Frontend Engineer

Front-end is the one specialism where the artefact under review actively conceals the defects. The reviewer opens the submission in a modern browser on a fast laptop with a mouse, sees an interface that matches the design, and marks it passed. Everything that separates a good front-end engineer from a bad one is invisible in that moment: whether the control is reachable by keyboard, whether the button has an accessible name, whether the contrast holds, whether there is any rendering path for the request failing, whether the list re-renders in its entirety on every keystroke, whether the layout survives a longer string in another language. WebAIM's February 2026 analysis of a million home pages found 95.9 percent with detected WCAG 2 failures and an average of 56.1 errors per page, up 10.1 percent year on year — an industry-wide statement that this exact category of defect ships routinely, which is what you would expect if the dominant screen is "does it look right". Assistance makes it worse in a specific way: a model reliably produces a component that renders correctly and is untestable, inaccessible and over-coupled, because renders-correctly is what its training signal rewarded too.

The front-end engineer's real subject is not layout. It is state: the set of things that can be true at once in a browser tab, and what the user sees for each combination. A list can be loading, loaded and empty, loaded with results, loaded and stale, or failed — and it can be any of those while a second request is in flight and while the user is halfway through typing into a filter. The difference between a competent front-end hire and an expensive one is almost entirely whether they enumerate those states deliberately or discover them in production.

Hour to hour, the work is translating an interface design that specifies exactly one of those states into code that handles all of them, against an API that someone else is still changing. That is why "build this design" is such a poor proxy for the job. The design shows the loaded-with-results case. The design never shows what happens when the request 500s, when the name is forty characters long, when the user has reduced-motion set, or when someone is navigating with a screen reader. A candidate who asks about those before writing code is telling you more than a candidate whose submission is pixel-perfect.

Accessibility deserves to be treated as a competence rather than a compliance footnote, and the industry data explains why. WebAIM's 2026 million-page analysis found detected WCAG 2 failures on 95.9 percent of home pages, with low contrast text on 83.9 percent, missing image alternative text on 53.1 percent and missing form input labels on 51 percent — six categories accounting for 96 percent of all detected errors. These are not subtle defects requiring specialist tooling to find. They are the defects you get when nobody at build time was thinking about anyone using the page differently from the person who built it. A hiring process that never observes whether a candidate reaches for a label, a role or a focus state is a hiring process that will keep reproducing that number.

The top quartile is also distinguished by restraint about state management. Weak front-end engineers reach for global state because it makes the immediate problem go away, and every subsequent feature inherits a slightly larger untraceable blob. Strong ones keep state as local as it can be, lift it exactly once when a second consumer appears, and can tell you which component owns each piece and why. That is a judgment about ownership, not a framework preference, and it survives whatever library is fashionable when you read this.

What the hiring manager is trying to predict is how much of the next two years of front-end work will be spent on features versus on undoing this person's choices. The costliest front-end hires are not the ones who write slow code; they are the ones who write code that cannot be changed — components with eleven boolean props, tests that assert on class names, a design system fork that now has to be maintained forever.

The follow-up conversation about the candidate's own component is what makes this legible, and it is unusually cheap to run because the questions are so concrete. Open your submission and tab through it — what happens, and is that what you intended? What does a screen reader announce when this dialog opens? Show me the code path for the request failing; if there is not one, tell me what you would have done and why you did not. This list re-renders when I type — why? Which of your props would you remove first? A candidate who built the interface answers by pointing at their own lines. A candidate who generated it starts describing general good practice, which is the tell, and it arrives within a minute.

What the job actually needs

How people fail in this seat

What most employers do instead

CV screen, a framework trivia interview, and a take-home asking the candidate to build a small interface from a design, reviewed by running it and looking at it.

Front-end is the one specialism where the artefact under review actively conceals the defects. The reviewer opens the submission in a modern browser on a fast laptop with a mouse, sees an interface that matches the design, and marks it passed. Everything that separates a good front-end engineer from a bad one is invisible in that moment: whether the control is reachable by keyboard, whether the button has an accessible name, whether the contrast holds, whether there is any rendering path for the request failing, whether the list re-renders in its entirety on every keystroke, whether the layout survives a longer string in another language. WebAIM's February 2026 analysis of a million home pages found 95.9 percent with detected WCAG 2 failures and an average of 56.1 errors per page, up 10.1 percent year on year — an industry-wide statement that this exact category of defect ships routinely, which is what you would expect if the dominant screen is "does it look right". Assistance makes it worse in a specific way: a model reliably produces a component that renders correctly and is untestable, inaccessible and over-coupled, because renders-correctly is what its training signal rewarded too.

The assessment

About 75 minutes end to end.

The systems it runs in

A React and TypeScript application served by Vite in the sandbox, a single Figma frame as the entire design input, and a deliberately imperfect HTTP API behind it. Chrome DevTools and the React DevTools profiler are open, so the full-list re-render in t3 is something the candidate can be asked to demonstrate rather than assert. Accessibility is exercised the way it is exercised on the job — keyboard first, then a screen reader — not by a lint rule that can be satisfied without understanding it.

Vue with Nuxt, Angular, or Svelte. The four unhandled states, the missing accessible name on the icon-only control and the re-render on every keystroke exist identically in all of them. React is the default because the Stack Overflow Developer Survey 2025 reports it as the most used web framework after Node.js, and Figma because it is the surface most product teams hand designs off from. Buyers with their own component library or design system get the fixture rebuilt against it, which makes the accessibility findings sharper because the affordances are theirs.

Working speed is not scored. The cheap path in t1 is also the fast one: render the single state the design shows and stop. Every state the candidate adds costs minutes and earns score. A speed criterion would pay for the omission the task exists to observe, and would specifically penalise the candidate who enumerated states before writing anything. Elapsed time is reported beside the state enumeration, annotated as not a positive signal.

What the candidate actually does

TaskWhat happens
The one state the design shows
coding_sandbox · 40 min		An existing React and TypeScript application with a Figma file for a single screen: a filterable list of people with a detail panel. The design shows exactly one state — loaded, six results, short names, mouse cursor. The API behind it is real inside the sandbox and deliberately imperfect: it is slow on one route, returns an empty array for one filter value, 500s for another, and returns one record whose display name is sixty characters. Nothing in the brief mentions any of that. The ticket says: build this screen. The fork is whether the candidate builds the picture or builds the component. The cheap path renders the design, passes visual inspection on a fast laptop with a mouse, and has no loading, empty or error branch, no accessible name on the icon-only filter control, and a list that re-renders in full on every keystroke. The correct path enumerates the states first. AI assistance is permitted and logged; a model asked for this component reliably produces the pretty, inaccessible, over-coupled version, because renders-correctly is what its training signal rewarded too.
The questions you would have asked the designer
written_artifact · 12 min		A short written note listing the states this screen can be in that the design does not show, what the candidate decided each should look like, and the questions they would have put to the designer before building. This is scored on completeness of the enumeration and on which decisions the candidate flags as theirs rather than the designer's. It is written after the sandbox, so it also exposes candidates whose code handles a state they cannot articulate, and candidates who can articulate states their code does not handle.
Tab through your own component
live_call · 23 min		A spoken conversation with the candidate's own submission running on screen. The interviewer drives it with the keyboard only and asks the candidate to narrate: where is focus now, and is that what you intended? What does a screen reader announce when this panel opens? Show me the code path for the request failing — if there is not one, tell me what you would have written and why you did not. This list re-renders on every keystroke; show me why, in your code. Which of your props would you delete first, and what breaks? Then the requirement changes live: the list must now support multi-select with a bulk action — walk me through which of your components has to change and which piece of state has to move. That last question is the one an assembled submission cannot survive, because it asks who owns each piece of state, and only the person who placed it knows.

The mark scheme

Each criterion is scored 1 to 5 against written anchors, and every score is reported with the excerpt that earned it. A criterion marked floored is reported as a finding rather than averaged into the total. The first is open; open any other to read its anchors in full.

Non-happy states are built, not discoveredweight 0.3Loading, empty, error and stale are distinguishable in the code and in the running interface, and the candidate can point at the branch for each. The …
1 Only the loaded-with-results path exists. The empty filter renders a blank region, the 500 renders nothing or a raw error, and there is no loading affordance on the slow route.
3 Loading and error are handled; empty is conflated with loading, or the stale-while-refetching case shows the previous result with no indication.
5 Loading, empty, error and stale are distinguishable in the code and in the running interface, and the candidate can point at the branch for each. The sixty-character name does not break the layout.
Accessibility at build timeweight 0.25Every control is reachable and named, focus moves deliberately when the panel opens and returns when it closes, and the candidate says out loud what a…
1 Icon-only control has no accessible name; the detail panel is unreachable by keyboard or traps focus; interactive behaviour is attached to a non-interactive element.
3 Semantic elements are used and the screen is navigable, but focus is not managed when the panel opens and closes, and the candidate has not checked it.
5 Every control is reachable and named, focus moves deliberately when the panel opens and returns when it closes, and the candidate says out loud what a screen reader announces before being asked to guess.
State ownership and component boundariesweight 0.2Can name the owner of each piece of state and why, explains the re-render from their own code unprompted, and under the multi-select change identifies…
1 Filter, selection and fetched data all live in one place at the top; every keystroke re-renders the entire list and the candidate has not noticed.
3 State is reasonably placed but the candidate justifies it by habit rather than by who consumes it; the re-render is explained after being shown.
5 Can name the owner of each piece of state and why, explains the re-render from their own code unprompted, and under the multi-select change identifies exactly which state has to move up and what that costs.
Ownership of the submitted componentweight 0.15Names a weakness in their own component before being asked, and traces the multi-select requirement to specific files and specific lines within a minu…
1 Answers about their own code with general good practice; cannot name a prop they would remove; describes the component rather than defending the decisions in it.
3 Explains most of it first-person, with one section they clearly did not author closely.
5 Names a weakness in their own component before being asked, and traces the multi-select requirement to specific files and specific lines within a minute.
Robustness to the API it did not controlweight 0.1Degrades locally rather than globally and states which parts of the response the component treats as contract and which as advisory.
1 Treats the response as guaranteed well-formed; a missing field throws and takes the screen down.
3 Guards the obvious fields; the failure of one item degrades the whole list.
5 Degrades locally rather than globally and states which parts of the response the component treats as contract and which as advisory.

How it is scored

Weighted mean of five criteria, 1-5 against the anchors, reported with the code excerpt, the screen recording moment, or the transcript line behind each score. Visual fidelity to the design is not a criterion anywhere in this rubric, which is deliberate: matching the picture is the part of this job that has become abundant, and it is the only part the standard take-home measures.

Integrity

The log describes what happened. It does not produce a cheating verdict — the follow-up conversation is the control, because a statistical accusation is not something we would ask a reviewer to defend.

What you receive

Who decides

Recommended. A reviewer confirms or overrides each score with a written reason, and the accessibility criterion should be reviewed by someone who has actually used a screen reader — anchor 5 asks what is announced, and a reviewer who does not know cannot mark it. Automated accessibility checking finds a real subset of defects and is used as evidence, never as the score.

What this does not measure

This design does not measure visual or aesthetic judgment, design taste, animation craft, CSS breadth, or framework trivia, and a team hiring specifically for visual polish will not find it here. It does not observe cross-browser behaviour, real device performance, or how someone works with a designer over weeks rather than minutes. The chief fairness risk is that the accessibility criterion rewards prior exposure to a domain that many self-taught and bootcamp-trained candidates were never taught, which correlates with route into the industry rather than with capacity; the mitigation is that anchor 3 is a genuine pass — semantic elements and a navigable screen — and only anchor 5 requires depth, and that the interviewer asks what the candidate would check rather than testing recall of ARIA attribute names. The fixture is in one framework, which advantages its recent users; offer more than one and keep the rubric identical, since no criterion here is framework-specific. Offer the spoken segment with captions, extra time, or in written form on request, and never score delivery.

Front-end is the one specialism in this hub where the artefact under review actively hides the defects. A reviewer opens the submission on a fast laptop, in a current browser, with a mouse, sees something that matches the design, and marks it passed. Every difference between a good front-end engineer and an expensive one is invisible in that moment. So this design never asks a reviewer to look at the screen and judge. It asks the candidate to drive their own component with a keyboard, out loud, while someone watches — and it puts the imperfect API behind the fixture so the states the design does not show are reachable during the assessment rather than in production six weeks later.

The fixture's misbehaviour is the fork. Every candidate is handed the same slow route, the same empty result, the same 500, and the same sixty-character name, and none of it is mentioned in the brief. A candidate who builds the picture will never encounter any of it, because the default filter returns the six happy rows. A candidate who thinks in states finds all four inside the first ten minutes, because they will type into the filter deliberately trying to break it. That difference is behavioural, it happens in the first third of the session, and the sandbox timeline records it. The submitted code shows the outcome; the timeline shows whether the outcome was intent or luck.

Accessibility is scored as a competence rather than a compliance checkbox because that is what it is, and because the industry-level evidence in the role file describes an outcome that individual conscientiousness has repeatedly failed to change. The rubric therefore anchors on behaviour that is observable in the running artefact: is the icon-only control named, does focus move when the panel opens, does it come back when the panel closes. Those are not opinions and a reviewer does not need to argue about them. The interview then adds the question automated tooling cannot ask — what does this announce — and the honest answer "I do not know, here is how I would find out" is scored above a confident wrong one.

The multi-select turn at the end of the interview is the instrument that prices the AI delta for this role specifically. Generated components are coherent and narratable; a candidate can walk through one convincingly for several minutes. Multi-select does not add a feature so much as relocate a responsibility: the selection now has more than one consumer, so a piece of state has to move, and which piece it is depends entirely on how the candidate laid the component out. Someone who made those placement decisions answers in file names and prop names within about a minute. Someone who received the layout starts talking about state management libraries in the abstract, which is the tell, and it arrives early enough that the rest of the conversation can be spent on something more useful.

What a hiring manager is buying here is a prediction about the second year: how much of the next two years of front-end work goes into features and how much goes into undoing this person's component boundaries. The costliest front-end hires do not write slow code. They write code that cannot be changed — the component with eleven boolean props, the test that asserts on a class name, the fork of the design system that now has to be maintained forever. The delete-a-prop question and the state-ownership criterion exist to see that coming, and neither of them has anything to do with whether the submission matched the picture.

Sources

Every figure on this page is traceable. Where a claim could not be sourced it is stated qualitatively instead.

  1. WebAIM, The WebAIM Million: an annual accessibility analysis of the top 1,000,000 home pages, February 2026, https://webaim.org/projects/million/
  2. Stack Overflow, 2025 Developer Survey, Developers section, roughly 49,000 respondents worldwide, developer-type question answered by 43,560, https://survey.stackoverflow.co/2025/developers

See what the employer actually receives. A full report for one role, with every score shown beside the excerpt that earned it, conduct findings reported rather than averaged, and a reviewer sign-off required before any decision. No form.

Read a sample reportOr talk to us about this role