Frontend Engineer Interview Questions: What to Ask and What a Good Answer Contains
Frontend candidates are easy to over-interview on framework trivia and under-interview on the things that decide whether the product feels right: state that stays correct, pages that load, interfaces everyone can use. These questions are about those.
- Ask about work the candidate owned, not opinions: every question below asks for a system, a deal, a campaign or a decision that actually happened, with what they did and what came of it.
- Score each answer against the note beside it. The notes describe observable things a strong frontend engineer answer contains, so two interviewers write down the same evidence and reach the same score.
- Use the scorecard: state management; performance; accessibility, and two more. Five criteria, scored 1 to 4, with a sentence of evidence each.
- Ask five questions well rather than eight in a rush. The first one, about something the candidate owned end to end, sets the tone: specifics, not generalities.
- Watch for the red flags listed below, which are patterns rather than single answers: answers every question with the name of a library, for one.
The questions
1. Show me, or describe, the most complex piece of UI state you have managed. Where did the state live, and why there?
What a strong answer contains: A deliberate answer about locality: server state versus client state versus URL state, and why each piece went where it did. Strong candidates mention what went wrong when state lived in the wrong place.
2. A page is slow to become interactive. How do you find out why, and what are the usual causes?
What a strong answer contains: Measures before guessing: a performance profile, the network waterfall, what is blocking the main thread. Names hydration cost, oversized bundles, unoptimised images and render-blocking requests as the usual suspects.
3. How do you make a custom component accessible? Take a dropdown or a modal.
What a strong answer contains: Focus management, keyboard operation, ARIA roles used correctly (and the observation that native elements need none of it). A candidate who has actually tested with a screen reader will say so.
4. Tell me about a UI bug that only reproduced for some users. How did you track it down?
What a strong answer contains: A method: what those users had in common (browser, locale, data shape, timing), how they narrowed it, and what the fix taught them. Race conditions and locale-dependent formatting are common honest answers.
5. How do you decide between fetching on the server and fetching on the client for a given screen?
What a strong answer contains: Talks about what the user needs first, caching, SEO for public pages, and personalisation. Knows the difference between static, cached-with-revalidation and per-request rendering and can say when each is right.
6. How do you keep a design system from drifting as the team grows?
What a strong answer contains: Ownership, review, tokens over hard-coded values, and a story about a component that was forked and what they did about it. Process answers with no example are weak.
7. What is your approach to testing on the frontend?
What a strong answer contains: Tests behaviour through the interface a user sees (roles, labels, text), not implementation details; a few end-to-end journeys for the paths that make money; knows why snapshot tests rot.
8. Tell me about a design you disagreed with. What did you do?
What a strong answer contains: Raised it with reasons a designer could use (a usability problem, a constraint, data), proposed an alternative, and accepted the outcome. Look for respect for the discipline, not for winning.
Scorecard
Score each 1 to 4 with one line of evidence. A total is less useful than a pattern.
- State management: reasons about where state lives and why
- Performance: measures first, names the usual causes, has fixed one
- Accessibility: has built and tested an accessible component
- Debugging: a method for bugs that reproduce for some users only
- Collaboration with design: disagrees with reasons and accepts outcomes
Red flags
- Answers every question with the name of a library
- Has never opened a performance profile or a screen reader
- Accessibility described as "adding ARIA"
- Cannot describe a bug they found without help
How to run the interview
The state question is the one to spend time on. Ask for the specific screen, ask where each piece of state lived, and ask what happened when two pieces disagreed. A candidate who has been bitten by stale caches and duplicated state will have stories; one who has not will describe a diagram.
For the performance and accessibility questions, prefer a candidate who has done the thing once, badly, and learned from it, over one who can recite the checklist. "We shipped a modal nobody could close with a keyboard and a customer told us" is a better answer than a list of ARIA attributes.
If you do a practical exercise, make it a small fix in a component like yours, with the tools they normally use. Ask them to narrate. What they look at first tells you how they debug.
Frequently asked questions
Do we need framework-specific questions?
One or two, if you are hiring for a specific stack and the candidate claims it. Most of what matters transfers between frameworks; the questions above deliberately do not depend on one.
How do we assess visual taste?
Ask them to critique a screen of your product. Not to redesign it: to say what they would change first and why. Taste shows in what they notice.
Should the interviewer be a designer or an engineer?
An engineer for these questions, with a designer for a separate conversation about collaboration. Mixing the two in one hour shortchanges both.
Related guides
- Backend Engineer Interview Questions: What to Ask and What a Good Answer Contains
- UX Designer Interview Questions: What to Ask and What a Good Answer Contains
- QA Engineer Interview Questions: What to Ask and What a Good Answer Contains
- DevOps Engineer Interview Questions: What to Ask and What a Good Answer Contains
Screening frontend engineer CVs this week?
Paste the job description into WadeCV, check the rubric it drafts, and upload the CVs. Each one is read against the rubric and scored with an explanation. Ten screenings are free; there is no subscription.
Screen your first CVs free