Front-end developer screening questions: frameworks, accessibility, performance and design handoff
On this page
- Match the front end before the candidate
- Knockout questions
- What they built and what they owned
- Accessibility questions
- Performance questions
- Design handoff, testing and collaboration
- A 25-minute phone-screen flow
- How front-end experience gets overstated
- Scoring the screen
- Legal cautions
- Questions people ask
Front-end developer screening questions should test what the candidate built in the browser and which parts they personally owned: the framework and state management they used day to day, how they made the interface accessible, which performance problems they found and fixed, how they worked from designs, and how they tested it. A recruiter does not need to judge the code to hear the difference. Developers with real depth describe constraints, trade-offs and bugs; inflated resumes repeat the framework names on the page.
For the general method of screening any engineer, including the ownership ladder and resume inflation patterns, see software engineer phone screen questions. This page adds what is specific to the front end: the browser, users with disabilities, real-device performance and the handoff from design.
Match the front end before the candidate
"Front-end developer" covers a marketing site built in a CMS, a large single-page application, a design system used by twenty teams, and an e-commerce storefront where every 100 milliseconds matters. Ask the hiring manager which it is, which framework and version, whether the role owns a design system or consumes one, and whether the team expects the developer to work in the back end as well. Then screen against that, not against a list of every library on the job ad.
Knockout questions
| Question | What a strong answer sounds like | Red flags |
|---|---|---|
| 1. The team uses [framework and language, e.g. React with TypeScript]. How long have you used each in production, and on what? | A time span and a product: "Three years of React, two with TypeScript, on our customer dashboard." | Tutorial projects offered as production experience. Cannot say which version or when. |
| 2. What is the largest front-end codebase you have worked in regularly, and how many developers shared it? | Some sense of scale: number of developers, screens or packages, and how releases worked. | Only solo projects, for a role on a large shared codebase. |
| 3. The role is [remote, hybrid, on site] with [overlap hours]. Does that work? | A clear yes, or a specific exception. | Hours that do not overlap with the team at all. |
| 4. Will you now or in the future need sponsorship for employment visa status? | A direct answer. Ask it the same way for everyone; see work authorization questions in interviews. | None from the answer itself. Do not ask about citizenship or national origin. |
What they built and what they owned
| Question | What a strong answer sounds like | Red flags |
|---|---|---|
| 5. Tell me about a feature you built end to end on the front end. What was hard about it? | A specific feature, their part of it, and a real problem: a complex form, a slow table, a race condition between requests. | "We built" throughout with no "I". Nothing was hard. |
| 6. How was state managed in that app, and would you choose the same approach again? | Names the approach (framework state, a store, server-state caching) and a trade-off they would change. | Names a library but cannot say why it was chosen or what it cost. |
| 7. Describe a bug that only happened in one browser or on one device. How did you find it? | A concrete story: a Safari layout issue, a touch event on Android, a time zone bug, and the tools used to reproduce it. | Has never tested outside one desktop browser. |
Accessibility questions
Accessibility is where front-end depth shows fastest. WCAG 2.2 became a W3C Recommendation in October 2023. The Justice Department's ADA Title II rule requires state and local government web content to meet WCAG 2.1 Level AA; an April 2026 interim final rule moved the compliance dates to April 26, 2027 for larger entities and April 26, 2028 for smaller ones. Candidates for public sector or regulated clients should know this; everyone should know how to build an accessible component.
| Question | What a strong answer sounds like | Red flags |
|---|---|---|
| 8. How do you make a custom dropdown or modal accessible? | Native elements where possible, correct roles and labels, keyboard support, focus moved into and back out of the modal, tested with a screen reader. | "We add aria labels." No mention of keyboard or focus. |
| 9. How did your team test for accessibility, and what did the tests miss? | Automated checks in CI plus manual keyboard and screen reader testing, and an example of an issue only manual testing caught. | Relies entirely on an automated score. |
| 10. Which WCAG level did your product target? | A version and level (such as 2.1 AA), and how it was tracked. | Has never heard of WCAG, for a consumer or public sector product. |
Performance questions
Google's Core Web Vitals are Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift. INP replaced First Input Delay on March 12, 2024, so a candidate still talking about FID as current has not worked on performance recently.
| Question | What a strong answer sounds like | Red flags |
|---|---|---|
| 11. Tell me about a performance problem you measured and fixed. | The metric, how they measured it (field data, lab tools, profiler), the cause (large bundle, render-blocking resource, heavy re-renders) and the before and after. | "We made it faster," with no measurement. |
| 12. How did you keep the JavaScript bundle under control as the app grew? | Code splitting, lazy loading, auditing dependencies, a budget checked in CI. | Never looked at bundle size. |
Design handoff, testing and collaboration
| Question | What a strong answer sounds like | Red flags |
|---|---|---|
| 13. How did you work from designs, and what did you do when a design did not cover a case? | Worked from Figma or a design system, raised missing states (empty, error, loading, long text) with the designer early. For the designer side of this, see UX designer phone screen questions. | Built it their own way without asking, or waited until QA found it. |
| 14. What did you test, with what, and what did you choose not to test? | Unit tests for logic, component tests, a few end-to-end tests for critical flows, and a reason for the balance. | No tests, or "QA handles testing." |
| 15. Tell me about a code review comment you disagreed with. | Explained their reasoning, listened, and either changed their mind or reached agreement. | Ignores reviews or treats them as personal criticism. |
A 25-minute phone-screen flow
- Minutes 0 to 3: the product, stack, team size and working pattern.
- Minutes 3 to 7: knockouts 1 to 4.
- Minutes 7 to 14: questions 5 to 7 on what they built. Write down names, numbers and trade-offs in their words.
- Minutes 14 to 20: one accessibility and one performance question.
- Minutes 20 to 25: design handoff or testing, pay expectations and next steps.
If the next stage is a take-home task, keep it short and scored on stated criteria, as described in how to evaluate a take-home assignment.
How front-end experience gets overstated
- Framework by adjacency. A developer who fixed CSS in a React app lists React as a core skill. Ask what they built in it.
- Full stack as a label. A front-end developer who called existing APIs lists back-end work. Ask what they designed on the server.
- Accessibility as a checkbox. A score from an automated tool described as accessibility work. Ask about keyboard and screen reader testing.
- Design system ownership. Using a component library described as building one. Ask which components they created and who used them.
Scoring the screen
Score each area 1 to 3 and write the evidence in the candidate's words, so the engineering interviewer knows what to probe next:
- Stack match: 1 = adjacent framework only, 2 = same framework, different scale, 3 = same framework and similar codebase.
- Ownership: 1 = "we" throughout, 2 = owned parts of features, 3 = owned features end to end, including the hard parts.
- Accessibility: 1 = automated score only, 2 = knows keyboard and labels, 3 = builds and tests with keyboard and screen reader.
- Performance: 1 = never measured, 2 = measured once, 3 = measured, fixed and kept it fixed.
- Collaboration: 1 = works around design and review, 2 = responsive, 3 = raises gaps early and handles disagreement well.
Legal cautions
Front-end screens often drift to age through "digital native" language or graduation dates. Ask about experience with specific tools and projects instead. Do not ask about citizenship or where the candidate is from; ask the sponsorship question the same way for every candidate. If you use a coding test, give every candidate the same one and offer accommodations on request. The full list of questions to avoid is in illegal interview questions, and if you are not technical yourself, how to interview for technical roles as a non-technical recruiter covers how to follow up on answers you cannot judge.
Questions people ask
Does a front-end developer need a certification?
No. There is no license or required certification for front-end development. Framework or cloud certificates show training, but the screen should test what the candidate built, which parts they owned, and how they handled accessibility, performance and testing.
Which accessibility standard should a front-end developer know?
The Web Content Accessibility Guidelines. WCAG 2.2 became a W3C Recommendation in October 2023, and the Justice Department's ADA Title II rule for state and local government websites points to WCAG 2.1 Level AA. A developer should be able to describe how they build and test to one of these levels.
What is INP, and why would a front-end candidate mention it?
Interaction to Next Paint is Google's responsiveness metric. It replaced First Input Delay as a Core Web Vital on March 12, 2024, alongside Largest Contentful Paint and Cumulative Layout Shift. A candidate who has worked on performance should be able to say which of these they improved and how.
Should I send a take-home test to front-end candidates?
Only if it is short, relevant to the job and assessed the same way for everyone. A small UI task with an accessibility and performance requirement tells you more than an algorithm puzzle. Tell candidates the time limit and the criteria in advance.