Frontend Developer Assessment

Why Frontend Developers are hard to hire well

Frontend is the only engineering discipline whose output is visible to everyone in the company, which has two unfortunate consequences. The first is that it is widely assumed to be the easy part, because the hard parts are the ones nobody can see. The second is that it is judged almost entirely on the visible layer during hiring: the portfolio looks good, the demo works, and the conversation never reaches the questions that determine whether the codebase survives a year.

The framework churn makes it worse. A hiring process filters on React, or Vue, or whichever library the team currently uses, and in doing so it selects for recency rather than depth. There is a real difference between an engineer who knows React and an engineer who understands the browser, and it becomes obvious the first time something behaves unexpectedly at the boundary between the two. Only one of them can debug an event ordering problem or explain why a layout shift is happening. The framework filter cannot tell them apart, because the person with the shallower model often has the more current CV.

Then there is the accessibility and performance gap, which is large and mostly invisible in interviews. Both are legal and commercial concerns in the UK, and both are cheap during implementation and painfully expensive afterwards. A candidate can have five years of experience and have never once tabbed through their own interface. Nothing in a portfolio review will surface that.

What separates the best from the rest

The strongest frontend developers design the component boundary before they write the component. Interfaces decay through accretion: a card gains a prop for the one page that needs a slightly different card, then another, and eventually there is a component with fourteen boolean props that nobody dares change. Good candidates recognise the shape of that decay early and are willing to have the harder conversation with design about whether the fourteenth variant should exist at all.

They also profile rather than guess. Frontend performance work is full of folklore, and a great deal of memoisation exists in production codebases for no measured reason, adding complexity and occasionally making things slower. The engineers worth hiring reach for the performance panel first, form a hypothesis about what is expensive, and only then choose a fix. This is the same instinct as debugging, and it distinguishes people quickly.

The third difference is how they treat the platform. Weaker candidates solve every problem inside the framework, including the ones the browser already solves. Stronger ones know when a native element, a CSS feature or a form behaviour will do the job with less code and better accessibility for free. Semantic HTML is not nostalgia, it is the cheapest route to an interface that works with assistive technology, and candidates who have internalised that produce durably better work.

Why interviews alone fall short

The typical frontend screen is a live coding exercise building a small component from scratch. It measures typing under observation, familiarity with one API surface, and composure. What it cannot reach is the judgement the job runs on: whether this state belongs in the component or the store, whether the design should be pushed back on, whether the accessible version of this interaction is the same as the mouse version. Those decisions have no single right answer and are invisible in a forty-minute build.

Portfolios have the opposite problem. They show the finished surface, which is the part of the work that was reviewed by other people and therefore the part least likely to reveal anything. You cannot see the props interface, the test coverage, what happened when the requirements changed, or how the component behaved when the API returned an error. A structured situational assessment puts the invisible decisions in front of every candidate identically, so what you compare is how they reason about maintainability, accessibility and performance rather than how confidently they type.

Common hiring mistakes in frontend recruitment

• Screening on framework version rather than fundamentals - a candidate strong in Vue will be productive in React within weeks, and one who has never understood the event loop will not be
• Skipping accessibility entirely - it is a legal exposure and a design constraint, and asking about it in the interview is the cheapest possible time to find out
• Treating design handoff as a solved problem - much of the friction in this role is negotiating what gets built, and candidates who never push back produce inconsistent interfaces
• Assuming visual polish implies engineering quality - the beautiful demo and the maintainable component are produced by different habits and only one of them is on the screen
• Ignoring how they test UI - component testing is genuinely difficult to do well, and a candidate with no view on it will leave you a suite that breaks on every refactor

The work this role is assessed against

• Translate Figma or Sketch designs into responsive, accessible components and screens
• Integrate APIs, manage client-side state, and handle routing and data fetching
• Profile and optimise performance (bundle size, runtime bottlenecks, images, caching)
• Write and maintain unit, integration, and end-to-end tests, fix defects, and prevent regressions
• Configure and maintain build tooling (Vite, Webpack), linting, formatting, and CI jobs
• Conduct code reviews, document components in Storybook, and triage production issues with real user monitoring and logging

Tools and outputs this role works with

HTML5 and CSS3, JavaScript and TypeScript, React or Vue or Angular, state management (Redux, Zustand, Pinia, NgRx), Webpack, Vite, Rollup, Node.js with npm, yarn or pnpm, Git with GitHub, GitLab or Bitbucket, VS Code, browser DevTools (Chrome, Firefox), Jest, Vitest and React Testing Library, Cypress or Playwright, Storybook, ESLint and Prettier, Tailwind CSS, Sass and PostCSS, Figma, Sketch and Adobe XD, REST and GraphQL clients (Axios, Apollo), Lighthouse and WebPageTest, Axe DevTools for accessibility, Sentry, Datadog RUM and LogRocket, and CI/CD via GitHub Actions, GitLab CI or CircleCI.