Taking an assessment rather than buying one? This page is written for employers. Here is the page for candidates.
Software engineering · Senior level
How to assess a Senior Frontend Engineer
Giving a senior front-end candidate the mid-level build-this-UI take-home measures a skill they stopped being paid for years ago, and measures nothing they are being hired for now. The senior job is boundary work: deciding what belongs in the shared component library and what belongs to one feature, deciding what the server should send so the client is not permanently reconciling, deciding which of the twelve requested additions to the page this quarter fit inside the performance budget and which do not. Every one of those decisions is made in a conversation with someone who wants the opposite thing, and none of them is a coding exercise. The other structural failure is that past-project conversations are the most gameable interview format in existence — they are unverifiable, rehearsed, and reward the candidate who was nearest the impressive project rather than the one who made the decisions in it.
Senior front-end is a different job from front-end, in a way that senior backend is not quite a different job from backend. The mid-level front-end engineer owns components. The senior one owns the rules that determine what components exist, and spends a surprising share of their week outside the editor arguing for those rules with designers, product managers and backend engineers who each have a reasonable competing interest.
Performance is the clearest example, and the field data shows why it needs an owner. HTTP Archive's 2024 Web Almanac, drawing on Chrome UX Report field measurements rather than lab tests, put good Core Web Vitals at 43 percent of mobile page loads against 54 percent on desktop, with the individual metrics telling the story — 59 percent of mobile loads passing LCP against 72 percent on desktop. Sites do not become slow through a decision; they become slow through forty reasonable decisions, each of which added a little. Holding a budget means being the person who says no to the fortieth reasonable request, and being able to say why in a currency the requester cares about. That is a negotiation competence sitting on top of a technical one, and it is the actual reason senior front-end engineers are expensive.
The second boundary is with the API. A great deal of front-end pain is downstream of a response shape agreed in a hurry: the client now denormalises, merges two endpoints, holds state that the server should have held, and every subsequent feature pays interest. A senior front-end engineer who reviews API proposals and pushes back — "if you send it in this shape I need a second request and a client-side join, send me the joined object" — removes a category of future work that nobody will ever measure. A senior who does not simply accepts whatever arrives and builds increasingly baroque adapters.
The third is the shared-versus-local decision. Design systems fail in two opposite ways: too permissive, and every team forks it; too strict, and every team routes around it. Getting this right requires knowing which variations are real product needs and which are a designer having a preference on a Tuesday, and the only way to know is to ask. It is a judgment about people applied through code.
Accessibility remains a senior responsibility rather than a mid-level one in most organisations, because at senior level it stops being "add a label" and becomes "make it impossible to ship the component without one". WebAIM's 2026 million-page scan found 95.9 percent of home pages with detected WCAG 2 failures and low contrast text on 83.9 percent of them; those numbers persist because individual conscientiousness does not scale and systemic enforcement does. A senior candidate who talks about lint rules, CI gates and component defaults is describing the intervention that works.
The design for this role reflects all of it. The sandbox is not a blank page; it is an existing component library with a feature request that could reasonably be built either as a new shared component or as a local one, plus a bundle that has grown and a proposed API response that pushes work into the client. The follow-up conversation asks: you put this in the shared library — who else has to agree, and what happens when the next team wants a variant? You accepted this response shape; what would you have asked for instead, and what does it cost the backend team? Something on this page has to go to hold the budget — which, and how do you tell the product manager? Walk me through what your change did to the bundle. Those are the questions a senior front-end engineer answers every week, and they cannot be answered by anyone but the person who made the decisions.
What the job actually needs
- defining boundaries between shared and feature code
- holding a performance budget against feature pressure
- specifying what the API should return
- reviewing components for changeability
- translating a design constraint into a business argument
How people fail in this seat
- builds a design system nobody adopts because it was not negotiated
- lets a bundle grow because each individual addition was reasonable
- accepts an API shape that pushes reconciliation into the client forever
- blocks a release over an aesthetic disagreement
- cannot explain to a product manager why the thing they want costs a second of load time
What most employers do instead
The same take-home given to mid-level candidates, plus a deeper framework interview and a conversation about past projects.
The assessment
About 85 minutes end to end.
The systems it runs in
A pnpm workspace holding a shared React and TypeScript component library and three consuming applications, with Storybook over the library and a bundle-size budget enforced in CI on the pull request, so the number moves visibly when the requested implementation adds a dependency. The API response in t2 is posted as a real comment thread on a real pull request, not handed over as a document.
- React
- TypeScript
- pnpm workspaces
- Turborepo
- Storybook
- size-limit
- Vite
- GitHub Actions
- Figma
Nx in place of Turborepo, bundlewatch or a Lighthouse CI performance budget in place of size-limit, and Vue or Angular in place of React. The architectural fork — a seventh boolean prop against composition against a local fork with a stated intention to converge — is a property of shared component libraries rather than of any framework, and survives every swap. Buyers who publish their library to a package registry rather than keeping it in a monorepo get that shape instead, and it makes the fork sharper, because the migration cost in the correct path is then paid across releases rather than in one commit.
What the candidate actually does
| Task | What happens |
|---|---|
| Shared or local coding_sandbox · 35 min | An existing component library with three consuming applications in the same repository, and a feature request from one of them: a data table that needs a sticky column and an inline edit affordance. The library already has a table. It has six boolean props, two of which were clearly added the same way this request would add a seventh. The fork is architectural rather than algorithmic. The cheap path adds the seventh prop, ships quickly, works, and passes review anywhere; a model asked to add the feature will do exactly this because it is the smallest diff. The correct paths are several and all more expensive — compose rather than configure, fork locally with a stated intention to converge, or change the shared component's shape and migrate the other two consumers. The sandbox has a bundle-size budget enforced in CI on the pull request, and the requested implementation also adds a dependency that moves the number. Nothing in the ticket mentions the budget. |
| The response shape you have to live with written_artifact · 15 min | A backend engineer's proposed API response for the same screen, posted for comment. It is not wrong. It is normalised in a way that requires the client to make a second request and perform a join, and it returns timestamps and enum codes that the client will have to map to display strings forever. The candidate writes the reply they would post. The cheap response is approval, or a request for one convenience field. The strong response names what the client will end up owning permanently if the shape ships, proposes a specific alternative, and prices what that alternative costs the backend team rather than pretending it is free. |
| Something has to go live_call · 15 min | A live spoken call with an AI product manager. Three things are queued for this page: the new table, a third-party chat widget marketing wants, and a recommendations carousel that tested well. The page is already at the edge of its performance budget and the candidate has just measured what their own change did to it. The product manager wants all three, does not dispute the numbers, and does not consider load time to be their problem. What is scored is whether the candidate converts a technical measurement into a consequence the product manager cares about, whether they bring a proposal rather than a complaint, and whether they can concede the right one — including conceding their own feature if that is the correct answer. |
| Interview on the boundary you drew live_call · 20 min | A spoken conversation over the candidate's own decisions. You put this in the shared library — who has to agree, and what happens when the second team wants a variant of it? You added a seventh prop; what is the rule that says when to stop, and does your own change satisfy it? Walk me through exactly what your change did to the bundle, and how you know. You accepted this response shape; what would you have asked for instead, and what does it cost the backend team? Then the live change: the third application now needs the same table without the sticky column and with a different row height — does your implementation survive that, or does it grow another prop? The last question is the whole role compressed into one turn, and it can only be answered by whoever actually made the placement decision. |
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.
Draws the shared-versus-local boundary deliberatelyweight 0.3States the rule they are applying before writing, names who else has to agree, says what happens when the next variant is requested, and under the thi…
Holds the budget with a measurementweight 0.25Measures their own change, states the number, converts it into something the product manager cares about, and brings a specific proposal about what go…
Specifies what the API should returnweight 0.2Names the permanent client-side ownership the shape creates, proposes a specific alternative shape, prices it for the backend team, and says which par…
Ownership of the decisions in the artefactweight 0.15Volunteers the weakest part of their own boundary decision before being asked, and traces the third-application change to specific files and a specifi…
Reviews for changeability rather than correctnessweight 0.1Names the specific way the component has become hard to change, and proposes an incremental route out that does not require anyone to stop shipping.
How it is scored
Weighted mean of five criteria, 1-5 against the anchors, each reported with the code excerpt, the written reply, the bundle measurement, or the transcript line behind it. Note that pixel fidelity, CSS technique and framework knowledge appear nowhere in this rubric. A senior front-end candidate who builds beautifully and adds the seventh prop scores below one who builds adequately and refuses to.
Integrity
- AI assistance permitted and logged; the smallest-diff solution is what a model produces and the design accounts for that
- Edit timeline retained, including whether the other two consuming applications were opened before the shared component was changed
- Bundle report is instrumented, so whether the candidate looked at it is recorded, not inferred
- Two live spoken segments — the product-manager negotiation and the follow-up — both on the candidate's own work
- No automated cheating verdict; a generated component is expected, and the boundary questions are the control
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
- Diff and edit timeline, including which consumers were opened
- Bundle-size delta for the candidate's change
- The written API reply as posted
- Recordings and transcripts of both spoken segments
- Per-criterion score with the excerpt or quotation behind it
Who decides
Required. Three of the five criteria are judgments about trade-offs where more than one answer is defensible, and a reviewer who has owned a design system should confirm or override each with a written reason. In particular, a candidate who forks locally with an explicit convergence plan may deserve a 5 on the boundary criterion where a naive marker would want the shared change; the anchor is about deliberateness and about who has to agree, not about which option was chosen.
What this does not measure
This design does not measure visual design ability, motion and interaction craft, or CSS depth, and a team hiring a senior engineer principally for visual execution should assess that separately. It does not observe how someone builds consensus over months, which is most of the real design-system job — a fifteen-minute negotiation samples the disposition, not the campaign. It does not observe mentoring, hiring, or how the candidate behaves when the product manager outranks them and does not concede. Fairness risks to monitor: the negotiation segment rewards a directness that is unevenly distributed by culture, seniority of previous employer, and first language, so score the content of the argument and the quality of the proposal, never assertiveness, volume, accent or fluency — a candidate who says the same thing quietly and precisely scores identically. The fixture is one framework and one build tool, which advantages recent users; offer alternatives and keep the rubric fixed, as no criterion here is framework-specific. Offer both spoken segments with captions, extra time, or in written form on request. Finally, this assessment is calibrated for an organisation that owns a shared component library; used for a senior role at a company with a single application, the heaviest criterion is measuring something the job does not contain.
Giving a senior front-end candidate the mid-level build-this-interface exercise measures a skill they stopped being paid for years ago. The senior job is boundary work — what belongs in the shared library and what belongs to one feature, what the server should send so the client is not permanently reconciling, which of the twelve requested additions to this page fit inside the budget. Every one of those decisions is made in a conversation with somebody who wants the opposite thing, and none of them is a coding exercise. So this design has one sandbox segment and three artefacts that are not code, and the sandbox segment exists mainly to produce decisions worth interrogating.
The seventh prop is the fork, and it is deliberately the option that every incentive in the room points at. It is the smallest diff. It ships today. It passes review at most companies. It is what a model produces when asked to add the feature, because minimal-diff is the shape of the request. And it is how a component library becomes unmaintainable — not through one bad decision but through six reasonable ones, each of which added a little, exactly as pages become slow. The rubric does not require any particular alternative. Composition, a local fork with a convergence plan, or changing the shared shape and migrating the two other consumers are all worth a 5 if the candidate can say who has to agree and what happens when the next variant arrives. What is worth a 1 is doing it without noticing that a decision was being made.
The bundle report is instrumented rather than asked about, which matters. A candidate can talk fluently about performance culture in an interview; whether they opened the report before the product-manager call is a fact. And the call itself is built so that the technically correct answer is not automatically the one that earns the score. The product manager does not dispute the numbers and does not care about them, which is the ordinary situation. Converting a kilobyte figure into a consequence someone outside engineering can act on is the actual competence, and the strongest candidates arrive with a proposal about what should go rather than an objection to what should stay — including, when it is the honest answer, proposing that their own table waits.
The API reply is included because a large share of front-end pain is downstream of a response shape someone agreed to in a hurry. Once the client is denormalising, merging two endpoints and mapping enum codes to display strings, every subsequent feature pays interest, and nobody ever attributes that cost to the fifteen-minute decision that caused it. A senior engineer who pushes back with a specific alternative and an honest price for the other team removes a category of future work that will never appear in any metric. One who accepts whatever arrives builds increasingly baroque adapters for the next three years.
The final interview question — a third application wants the same table without the sticky column and with a different row height — is the entire role compressed into one turn. It is not a harder version of the original task; it is the second variant, which is the moment every shared-component decision is actually tested. A candidate who drew the boundary deliberately answers in about a minute, names the files, and says honestly whether their implementation absorbs it or grows another prop. A candidate who accepted the smallest diff answers about design system philosophy, in general, and the gap is unmistakable to anyone listening.
Sources
Every figure on this page is traceable. Where a claim could not be sourced it is stated qualitatively instead.
- HTTP Archive, Web Almanac 2024, Performance chapter, based on Chrome UX Report field data, https://almanac.httparchive.org/en/2024/performance
- WebAIM, The WebAIM Million: an annual accessibility analysis of the top 1,000,000 home pages, February 2026, https://webaim.org/projects/million/
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