What should a frontend engineer coding interview test?

The work the job involves: reading and fixing a component, handling state and data fetching, making an interface accessible, and explaining trade-offs. A 20-minute review of a prepared component shows more than an algorithm puzzle. Use the same component and the same planted issues for every candidate.

Should we test React knowledge specifically?

Test it if the job uses React daily and you cannot afford ramp-up time, but weigh the underlying skills more. State, the DOM, accessibility and performance carry over between frameworks, and an engineer strong in those learns a new framework quickly. Say in the invitation which framework the exercise uses.

How do we assess accessibility if nobody on the panel is an expert?

Plant two or three clear issues in the review exercise, such as an unlabeled input and a clickable div, and write the expected findings down before the first interview. Then ask how the candidate would check a fix. That works without a specialist on the panel.

How is a frontend interview different from a general software engineer interview?

It keeps the core of problem solving and code quality, but moves the evidence to the browser: state and rendering, accessibility, performance on real devices, and work with designers. For a full-stack role, combine this kit with the software engineer kit and keep only the competencies the job needs.

Free interview kit

Frontend Engineer interview kit: questions and rubric

For hiring teams interviewing a mid-level frontend engineer, roughly three to six years in, who builds web interfaces in a component framework such as React with TypeScript. It covers a short screen, five competencies with a 20-minute component review, behavioral and situational questions, anchored ratings, the questions never to ask, and a rule for deciding.

5 competencies · 12 questions · anchored 1-to-5 scale · Updated 10 October 2026 · Written by the Itya team

Share this kitLinkedIn X WhatsApp Email

How to use this kit

Agree the competencies with the hiring manager before the job is posted.
Give each interviewer one or two competencies, so nothing is asked twice.
Ask every candidate the same core questions; follow up freely.
Rate each competency against the anchors straight after the interview, alone.
Debrief on quotes, not adjectives, then decide with the rule at the end.

First-round screen

Fifteen to twenty minutes, by phone, video or a disclosed AI screen. The aim is to confirm the basics before the panel spends its time.

What draws you to frontend work, and what kind of interface work do you want more of in your next job?
Walk me through an interface you built that real users depend on: what it does, which part you owned, and one thing you would change about it.
This role works in the framework and stack named in the job description. Which parts of it have you shipped production code in, and for how long?
The job description sets out the location, working pattern and start date. Do those work for you, what is your notice period, and what compensation range are you expecting?

Competency 1

Component design and state

Most frontend bugs are state bugs: stale data, two sources of truth, effects that run at the wrong time. Engineers who know where state should live build interfaces that stay correct as they grow.

Work sample, 20 minutes: here is a 50-line React and TypeScript search-as-you-type component from an anonymized pull request. It copies a prop into state, fetches on every keystroke with no cancellation, so a slow early response can overwrite a later one, renders the results as clickable divs and has no label on the input. Review it out loud as you would for a teammate. Rate the state findings here and the accessibility findings under accessibility.
Follow up with
- Which of your comments would block the merge, and which are suggestions?
- How would you stop an older response from overwriting a newer one?
- Where should the results live if two other components need them?
Strong answer
Finds the race between responses and fixes it by cancelling or ignoring stale requests (an AbortController, a request id, or a data-fetching library that handles it). Spots the prop copied into state and derives it instead. Separates blocking comments from optional ones and explains each.
Weak answer
Comments on naming and formatting only, misses the race, or rewrites the component in a new library without saying what was wrong. Adds more state or another effect to fix a bug that state caused.
Tell me about a frontend bug caused by state that took you a long time to find. What was going on?
Follow up with
- How did you narrow it down?
- What did you change so that kind of bug was harder to write?
Strong answer
Describes a specific bug (a stale closure, server data copied into two stores, an effect firing twice), the tools used to narrow it (browser devtools, the network panel, a failing test), the root cause, and a structural fix such as a single source of truth.
Weak answer
Fixed it by adding a timeout, a key or another effect until the symptom went away, and cannot explain why the fix worked.
What would you do if a page you own keeps server data in a global client store, and users often see stale records after editing them?
Follow up with
- What would you change first, and how would you ship it safely?
- What would you leave alone?
Strong answer
Separates server state from UI state, proposes a query cache with invalidation after each mutation (or the framework's own data loading), migrates one screen at a time behind tests, and leaves genuinely client-only state where it is.
Weak answer
Proposes rewriting the app around a new state library, or patches each screen with manual refetches and no plan.

Rating	What it looks like
5 · Strong	Finds the race and the derived-state bug unprompted, explains where each piece of state belongs and why, and proposes fixes that remove a whole class of bug rather than one symptom.
3 · Mixed	Finds the main state bug in the review and knows where state belongs in simple cases. Needs prompting on races, derived state, or server versus client state.
1 · Weak	Misses the response race and the copied prop in the review, even with a hint. Fixes state bugs by adding more state, effects or timeouts.

Competency 2

Accessibility

Keyboard and screen reader users are customers, and accessibility is decided in markup and interaction code, which frontend engineers write. Building it in costs far less than retrofitting it after a complaint or an audit.

Continuing the component review: how would a keyboard-only user and a screen reader user experience this search, and what would you change?
Follow up with
- How would you check your fix without a specialist?
- When would you reach for ARIA attributes, and when not?
Strong answer
Names the missing label, the divs that cannot be focused or announced, and the missing arrow-key support. Prefers native elements or a tested accessible combobox pattern over hand-rolled ARIA, and checks the fix with the keyboard, a screen reader and an automated checker such as axe.
Weak answer
Adds an aria-label to the div and calls it done, or says accessibility is the design team's job. Relies on an automated checker alone.
Tell me about an accessibility problem you found and fixed in something you built. How was it found?
Follow up with
- How did you test the fix?
- What did you change in how you or your team work afterwards?
Strong answer
Gives a specific problem (focus lost when a modal closes, low contrast, an unlabeled icon button), how it was found, the fix and how it was checked with real assistive technology. Describes a lasting check, such as a lint rule or automated accessibility checks in tests.
Weak answer
Cannot name a specific issue, or describes accessibility only as alt text on images. Fixed one instance with nothing to stop it returning.

Rating	What it looks like
5 · Strong	Finds keyboard, focus, labeling and announcement problems unprompted, prefers native semantics, tests with a keyboard, a screen reader and automated checks, and builds those checks into the team's workflow.
3 · Mixed	Spots the obvious gaps (labels, focus, keyboard access) and knows the native elements to use. Has not tested with a screen reader, or adds ARIA where a native element would do.
1 · Weak	Treats accessibility as alt text or as someone else's job. Misses the unlabeled input and the unfocusable results in the review.

Competency 3

Web performance

Users feel slow pages on mid-range phones and patchy networks, and Google reports field performance as Core Web Vitals. Frontend engineers decide most of what ships to the browser, so they own most of the fixes.

A product listing page feels slow on mid-range phones, and field data shows poor Largest Contentful Paint and Interaction to Next Paint. Talk me through how you would find the cause before changing any code.
Follow up with
- Which tools would you open first, and what would you look for?
- How would you know the fix helped real users, not just your laptop?
- What changes if the slowness started with the release last week?
Strong answer
Separates lab data from field data, profiles on a throttled or real mid-range device, and looks for the causes of each metric: a late or oversized hero image and render-blocking resources for LCP, long tasks and heavy re-renders for INP. Measures before and after against field data.
Weak answer
Lists generic tips (minify, use a CDN, lazy-load everything) without measuring anything. Tests only on a fast laptop and declares it fixed.
Tell me about a performance improvement you shipped. How did you measure it before and after?
Follow up with
- What did it cost in complexity?
- What stopped it from regressing later?
Strong answer
Names a measured problem, the cause found, the change (code splitting, image sizing, removing a heavy dependency, fewer re-renders) and before-and-after numbers from the same measurement. Added a performance budget or a CI check to hold the gain.
Weak answer
Optimized something because it seemed slow, with no measurement, or added memoization everywhere. Cannot say whether users noticed.

Rating	What it looks like
5 · Strong	Measures first on realistic devices, ties each fix to the metric it moves, confirms the gain in field data, and adds budgets or checks so it holds.
3 · Mixed	Knows the main metrics and tools, and finds common causes such as large bundles or unsized images. Needs prompting to use field data or a realistic device.
1 · Weak	Offers generic tips without measuring, and cannot say what Core Web Vitals measure or how to profile a page.

Competency 4

Testing and quality

Interfaces change every sprint, and clicking through them by hand does not scale. Frontend engineers need tests that catch real regressions without breaking on every markup change.

How do you decide what to test in a frontend feature, and with which kind of test? Use the last feature you shipped as the example.
Follow up with
- What do you test through the browser, and what in isolation?
- How do you find elements in a component test?
- Which test in your current suite would you delete, and why?
Strong answer
Describes a deliberate mix: unit tests for logic, component tests that act as a user would (finding elements by role and label, as Testing Library encourages), and a few end-to-end tests for critical journeys in a tool such as Playwright or Cypress. Avoids testing implementation details and can say why.
Weak answer
Relies on snapshots or tests internal state and private functions, or has no tests and leaves it to QA. Cannot explain why a given test exists.
What would you do if a designer's change to a shared Button component broke 40 snapshot tests across the app?
Follow up with
- What do those 40 tests protect against?
- What would you put in their place, if anything?
Strong answer
Questions what the snapshots were catching, replaces broad snapshots with behavior tests and visual regression checks on the component library, and reviews each visual change on purpose. Treats the incident as a sign the suite was testing markup, not behavior.
Weak answer
Runs the update-all-snapshots command without reading the diffs, or deletes the tests with nothing in their place.

Rating	What it looks like
5 · Strong	Chooses the right level of test for each risk, writes tests the way a user interacts, keeps end-to-end tests few and stable, and removes tests that cost more than they catch.
3 · Mixed	Writes component tests for the main behavior and a few end-to-end tests. Sometimes tests implementation details, or needs prompting on what not to test.
1 · Weak	Relies on manual checks or snapshots nobody reads, and tests internal state instead of behavior.

Competency 5

Working with design and product

Frontend engineers turn designs into working software and see the gaps first: missing states, edge cases, interactions that cannot be built accessibly. How they raise those gaps decides whether the result matches the intent.

What would you do if a design arrives with only the happy path (no loading, empty or error states, and no mobile layout) two days before the sprint starts?
Follow up with
- What would you ask the designer, and how?
- What would you build if the designer were away all week?
Strong answer
Lists the missing states, raises them early with questions or rough proposals, falls back on the design system's existing patterns, and records what was decided. Neither blocks nor silently invents.
Weak answer
Builds exactly what the mockup shows and leaves the rest for QA to find, or invents the missing states without telling anyone.
Tell me about a time you pushed back on a design because it could not be built well, for accessibility, performance or effort. What happened?
Follow up with
- What alternative did you bring?
- What was decided in the end?
Strong answer
Explains the constraint in terms of users, brings an alternative or a quick prototype, respects the designer's goal, and commits once a decision is made.
Weak answer
Said no without an alternative, or shipped something different from the design without discussing it. Talks about designers as obstacles.
Tell me about a component you added to, or changed in, a shared component library or design system.
Follow up with
- How did you make sure other teams could use it?
- How did you handle a breaking change?
Strong answer
Describes designing the component API with its users, building accessibility in, documenting it with examples, and shipping a breaking change with a version bump, migration notes and notice to the teams affected.
Weak answer
Copied the shared component and changed it locally instead, or shipped a breaking change with no notice.

Rating	What it looks like
5 · Strong	Finds gaps early, proposes concrete options in user terms, commits once decided, and builds shared components that other teams can adopt and upgrade safely.
3 · Mixed	Raises missing states and constraints with designers and works well with them. Needs prompting to propose alternatives or to think about other teams using shared components.
1 · Weak	Builds only what the mockup shows, invents or ignores missing states, and pushes back without alternatives.

Never ask

Don't ask a candidate's age, or their graduation year to work it out. Why: age says nothing about frontend skill, and age-based decisions are unlawful in many places.
Don't ask about marital status, children, pregnancy or plans to start a family. Why: none of it is job-related, and the question is still put mostly to women, which makes it discriminatory as well as irrelevant.
Don't ask about religion, caste, community or the origin of a surname, directly or by proxy ('What does your father do?'). Why: in India these questions signal caste and religion, which have no bearing on the job.
Don't ask 'Where are you from originally?' or 'What is your native place?'. Why: it invites judgments about region, language and community. If location matters, ask whether the candidate can work from the job's location.
Don't ask about health conditions or disabilities, including whether the candidate uses assistive technology, even though the role covers accessibility. Why: the only relevant question is whether they can perform the essential functions of the job, with or without reasonable accommodation. Offer every candidate adjustments to the exercise.
Don't ask for salary history where the law restricts it: many US states and cities do, and the EU Pay Transparency Directive requires member states to. Why: it carries past pay gaps into the new offer. Ask for the expected range; in India, where current pay is commonly asked, still set the offer from the role's band.
Don't ask the candidate to build a screen of your real product or redesign your live site as a take-home. Why: that is unpaid work. Use a prepared, anonymized component like the one in this kit, which has nothing to ship.

Making the decision

Each interviewer rates their competencies alone, against the anchors, before the debrief. The must-haves are component design and state, accessibility, and testing and quality. Any 1 on a must-have is a no, and so is any competency rated 1 by two interviewers. A hire needs an average of 3.5 or higher. The hiring manager decides after the debrief and records the component-review findings and quotes behind each rating.

Questions people ask

What should a frontend engineer coding interview test?: The work the job involves: reading and fixing a component, handling state and data fetching, making an interface accessible, and explaining trade-offs. A 20-minute review of a prepared component shows more than an algorithm puzzle. Use the same component and the same planted issues for every candidate.
Should we test React knowledge specifically?: Test it if the job uses React daily and you cannot afford ramp-up time, but weigh the underlying skills more. State, the DOM, accessibility and performance carry over between frameworks, and an engineer strong in those learns a new framework quickly. Say in the invitation which framework the exercise uses.
How do we assess accessibility if nobody on the panel is an expert?: Plant two or three clear issues in the review exercise, such as an unlabeled input and a clickable div, and write the expected findings down before the first interview. Then ask how the candidate would check a fix. That works without a specialist on the panel.
How is a frontend interview different from a general software engineer interview?: It keeps the core of problem solving and code quality, but moves the evidence to the browser: state and rendering, accessibility, performance on real devices, and work with designers. For a full-stack role, combine this kit with the software engineer kit and keep only the competencies the job needs.

A kit is step one.

Itya holds every interviewer to the same rubric, records the interview, and drafts the scorecard with the quotes behind each rating. The AI drafts; your team decides. Free plan, unlimited teammates.

Run this kit in Itya All interview kits