Frontend Developer Interview Questions (2026) and How to Answer
By FindAJobAI team Updated How we wrote this page
Frontend interviews usually mix a JavaScript or TypeScript exercise, a UI task (build a component in React or plain DOM), questions on performance and accessibility, and a behavioural round with design and product partners.
Interviewers look for someone who understands the browser, not just one framework, and who cares about the person using the page: speed, keyboard and screen reader access, and the loading, empty and error states.
Below: 30 questions with what each one really asks and an answer outline, full sample answers to the 10 most asked, red flags to avoid and a 7-day plan.
Answering with STAR
Tell each story in four steps: the situation in a sentence, your task, the actions you took (most of the answer) and the result, with a number if you have one. Aim for about two minutes; the outlines show what to include, the details must be yours.
Behavioural questions (1–10)
How you've handled real situations. Answer each with one true story, in STAR order.
1.Tell me about a UI you rebuilt that users noticed.
What they're really asking: Do you connect frontend work to outcomes for users, not just to cleaner code?
Answer outline (STAR)
- SituationA slow, confusing or inconsistent screen or flow.
- TaskImprove it without breaking things for existing users.
- ActionMeasure first (Web Vitals, analytics), rebuild in steps, check with users or support data.
- ResultThe number that moved: load time, conversion or support tickets.
Full sample answer (fictional example)
Our signup form lost 62 percent of people at step two. I watched ten session recordings and saw people typing their phone number in three formats and getting one generic error. I rebuilt the form as a single page with inline validation, kept the old one live for a tenth of traffic, shipped in two weeks and measured. Completion rose from 38 to 51 percent, and tickets about the phone field almost stopped. I shared the recordings with the team, so they could see why the change worked.
2.Describe a time you worked with a designer on something hard to build.
What they're really asking: Can you work through trade-offs together instead of saying no, or shipping it slightly wrong?
Answer outline (STAR)
- SituationA design with complex animation, responsive layouts or many edge cases.
- TaskShip it faithfully within the deadline.
- ActionPrototype the hard part early, show options, agree the states and breakpoints.
- ResultWhat shipped, and what you changed in how you work with designers.
3.Tell me about an accessibility problem you fixed.
What they're really asking: Is accessibility part of your normal work, or an afterthought?
Answer outline (STAR)
- SituationA component that failed keyboard, screen reader or contrast checks.
- TaskMake it usable for everyone, ideally to WCAG 2.1 AA.
- ActionSemantic HTML first, ARIA only where needed, proper focus management, a screen reader test.
- ResultThe audit result, and the lint rule or test that stops regressions.
Full sample answer (fictional example)
A custom dropdown on our checkout page couldn't be used by keyboard, and a screen reader announced it as plain text. I replaced it with a native select where the design allowed and, for the searchable one, built the combobox pattern with proper roles, focus handling and arrow-key support. I tested with VoiceOver and keyboard only. A later external audit found no blocking issues on checkout. I added an axe check to CI and a lint rule against clickable divs, so the problem wouldn't return.
4.Tell me about a frontend bug that only happened for some users.
What they're really asking: Can you debug across browsers, devices and data you can't see directly?
Answer outline (STAR)
- SituationA bug tied to one browser, device, locale or account state.
- TaskReproduce it without access to the user's machine.
- ActionUse error monitoring, session details and cross-browser testing to narrow it down.
- ResultThe fix, and the monitoring that now catches similar issues.
Full sample answer (fictional example)
Support reported a blank invoice page for a few customers, and I couldn't reproduce it. Error monitoring showed the errors came from one Safari version and from customers whose names contained accented characters. The cause was a regular expression with a lookbehind that older Safari didn't support. I replaced it, tested on that Safari version in a cloud browser, and added the browser to our test matrix. Errors from the page dropped to zero, and I set an alert for error spikes by browser version.
5.Tell me about a time you improved how your team builds UI.
What they're really asking: Do you think beyond your own tickets: shared components, tooling and standards?
Answer outline (STAR)
- SituationDuplicated components and inconsistent styles across the app.
- TaskMake building UI faster and more consistent.
- ActionStart a shared component library with design tokens, document it in Storybook, migrate gradually.
- ResultAdoption across teams and the time saved per feature.
6.Tell me about migrating a codebase to a new framework or language version.
What they're really asking: Can you change a live codebase gradually, without freezing delivery?
Answer outline (STAR)
- SituationA legacy app moving to TypeScript, hooks or a new router.
- TaskMigrate without stopping feature work.
- ActionGo file by file, add a lint rule blocking new legacy code, track progress.
- ResultMigration finished, bugs avoided, and the time it took.
7.Describe a time you pushed back on a design for usability reasons.
What they're really asking: Can you defend users politely, with evidence rather than taste?
Answer outline (STAR)
- SituationA design with tiny tap targets or low contrast.
- TaskChange it without souring the relationship.
- ActionShow a quick test or recording, cite a guideline, propose an alternative.
- ResultThe revised design, and how you worked together after.
Full sample answer (fictional example)
A new design used light grey text on white for secondary labels, below the accessibility contrast minimum. I didn't want to just say no. I built the screen both ways, ran a contrast checker, and showed the designer a screenshot simulating low vision. I proposed a slightly darker grey that kept the look. She agreed, and we added approved colour pairs to the design tokens, so later designs started from values that already passed. She now sends me early drafts for a quick check.
8.Tell me about a bug you shipped that users noticed.
What they're really asking: Do you own the mistake and add a safeguard?
Answer outline (STAR)
- SituationA release that broke a flow, such as checkout in one browser.
- TaskFix it fast and stop it recurring.
- ActionRevert or switch the flag off, reproduce, fix, add a regression test.
- ResultTime to recovery, and the check you now run before release.
9.Tell me about a UI decision you changed after looking at user data.
What they're really asking: Do you test your own assumptions instead of defending them?
Answer outline (STAR)
- SituationA feature people ignored or misused.
- TaskUnderstand why before changing it.
- ActionCheck analytics and recordings, form a hypothesis, A/B test a variant.
- ResultThe metric that moved, and what you learned about users.
10.Tell me about delivering UI while the design kept changing.
What they're really asking: Can you stay productive when requirements move?
Answer outline (STAR)
- SituationA sprint where designs changed twice midway.
- TaskShip something coherent anyway.
- ActionBuild around stable parts, isolate volatile bits, confirm changes in writing.
- ResultWhat shipped, and how you reduced churn next time.
Technical and role-skill questions (11–22)
Can you do the work itself? Think out loud and name the trade-offs.
11.Explain the JavaScript event loop.
What they're really asking: Core knowledge: why asynchronous code runs in the order it does.
Answer outline
- One call stack; callbacks wait in queues until the stack is empty.
- Microtasks (promise callbacks) run before the next macrotask (timers, I/O, events).
- Walk through the classic setTimeout-versus-Promise ordering, and why long tasks freeze the UI.
Full sample answer (fictional example)
JavaScript runs on one thread with one call stack. When I call setTimeout or fetch, the browser handles it outside the stack and later puts the callback into a queue. The event loop waits until the stack is empty, then takes the next task. Promise callbacks go in a microtask queue that is emptied before the next task, so a resolved promise runs before a timer set to zero. That is why a long synchronous loop freezes the page. I'd break heavy work into chunks or move it to a worker.
12.How do you make a slow page fast?
What they're really asking: Do you know the Core Web Vitals, and do you measure before optimising?
Answer outline
- Measure with Lighthouse and real-user data: LCP, INP and CLS.
- Fixes: code splitting, optimised images, fewer render-blocking resources, better caching.
- In React, avoid needless re-renders and virtualise long lists.
Full sample answer (fictional example)
I start by measuring, with Lighthouse for a lab view and real-user data for what customers see, focusing on Largest Contentful Paint, Interaction to Next Paint and layout shift. Then I fix the biggest cost first. Usually that's images, so I resize and serve modern formats; then JavaScript size, so I split bundles by route and remove unused libraries; then render-blocking resources. In React I'd also look for needless re-renders and virtualise long lists. After each change I measure again, and add a performance budget to CI.
13.When does a React component re-render, and how do you prevent unnecessary renders?
What they're really asking: Depth in the framework most frontend job ads ask for.
Answer outline
- It re-renders when its state, its props or a context it reads changes, or when its parent re-renders.
- Use memo, useMemo and useCallback where profiling shows a cost, not everywhere.
- Keep state close to where it's used, and split contexts that change often.
Full sample answer (fictional example)
A component re-renders when its own state changes, when its parent re-renders and passes new props, or when a context it reads changes. Re-renders are cheap by default, so I don't prevent them everywhere. When the profiler shows a slow component, I use memo for pure components, and useMemo or useCallback where a stable reference matters. Often the better fix is structural: move state down to the component that uses it, or split a context that changes often in two. I measure with the React profiler before and after.
14.How do you manage state in a large frontend app?
What they're really asking: Architecture judgement: local, global and server state are different problems.
Answer outline
- Keep UI state local, and lift it only when siblings need it.
- Server data belongs in a fetching cache such as React Query or SWR, not a global store.
- Use a global store like Redux or Zustand only for truly app-wide state, such as the session.
15.How do you test frontend code?
What they're really asking: Do you test the behaviour users see, at the right level?
Answer outline
- Unit tests for logic, and component tests with Testing Library that act like a user.
- A few end-to-end tests in Playwright or Cypress for critical flows such as signup and checkout.
- Visual regression checks for the shared component library.
16.What does semantic HTML give you, and when do you need ARIA?
What they're really asking: Accessibility fundamentals, which many job ads now list explicitly.
Answer outline
- Native elements such as button, nav and label bring keyboard support and screen reader roles for free.
- ARIA adds meaning only where HTML has no element, such as tabs or a combobox.
- Bad ARIA is worse than none, so test with a keyboard and a screen reader.
17.How would you build an autocomplete search box?
What they're really asking: A UI coding classic that tests async handling, performance and accessibility at once.
Answer outline
- Debounce the input, cancel stale requests and cache recent results.
- Handle the loading, empty and error states, and highlight the matched text.
- Support arrow keys and Escape, using the ARIA combobox pattern.
18.Explain closures, and a bug they can cause in a loop.
What they're really asking: Core JavaScript that surfaces in event handlers and async code.
Answer outline
- A closure is a function that remembers the variables of the scope that created it.
- With var in a loop all callbacks share one variable; let gives each iteration its own.
- Closures give private state, and can leak memory if they hold large objects.
19.How do the CSS cascade and specificity work, and when do you pick Grid or Flexbox?
What they're really asking: Do you understand CSS as a system, not trial and error?
Answer outline
- Rules win by origin, specificity, then order; avoid fighting it with !important.
- Flexbox lays out one dimension, such as a toolbar; Grid handles rows and columns.
- Design tokens and a naming convention keep styles predictable.
20.How does the browser turn HTML into pixels?
What they're really asking: Depth on the rendering pipeline behind most performance advice.
Answer outline
- Parse HTML into the DOM and CSS into the CSSOM, then build the render tree.
- Layout computes sizes, paint draws, and compositing assembles layers.
- Render-blocking CSS and scripts delay first paint; layout changes are the costly ones.
21.How do you protect a frontend app from XSS and CSRF?
What they're really asking: Security awareness where users meet the product.
Answer outline
- XSS: escape output, avoid injecting raw HTML, and set a Content Security Policy.
- CSRF: SameSite cookies and anti-forgery tokens on state-changing requests.
- Keep tokens out of localStorage where you can, and distrust URL and API data.
22.How do you design a reusable component other teams can use?
What they're really asking: Can you build an API for developers that is hard to misuse?
Answer outline
- Start from three real uses, keep props few, and prefer composition to flags.
- Build in accessibility, keyboard support and theming, with sensible defaults.
- Document with Storybook examples and test it, so changes don't break consumers.
Take-home or live exercise: tips
Frontend rounds often ask you to build a small UI, such as a typeahead or tabbed panel, live or as a take-home.
- Write the semantic HTML first, then style it, and handle loading, empty and error states.
- Try the keyboard path yourself before you say you're done; interviewers often check it.
- Say what you'd add with more time, such as tests or virtualisation, instead of over-building.
Skills employers test for
Technical rounds follow the job ad. These skills are named most often in the 453 newest frontend developer job ads we analysed (out of 1,222 live postings), shown as the share of ads that mention each. Expect questions on the top few.
- 1React70%
- 2TypeScript65%
- 3JavaScript53%
- 4CSS49%
- 5HTML43%
- 6CI/CD32%
- 7Code review31%
- 8Git29%
Full list: Frontend Developer resume keywords.
From live job ads · computed November 2, 2026 · refreshed daily
Situational questions (23–30)
Scenarios that test judgement: say what you'd do first, and why.
23.A designer hands you a mockup that ignores mobile. What do you do?
What they're really asking: Do you raise gaps early and propose solutions instead of guessing?
Answer outline
- Flag it before building and ask how they see it on small screens.
- Bring a quick proposal or prototype to speed up the decision.
- Agree the breakpoints and states together, then write them down.
Full sample answer (fictional example)
I'd flag it before building, in the design channel or on the ticket, with a short question: how do you see this on a 360-pixel screen? Designers often have an answer in mind, or a second frame I haven't seen. If not, I'd sketch a quick proposal, such as stacking columns and turning the table into cards, and bring it as a suggestion to speed things up. We'd agree the breakpoints and states together, and I'd write the decision on the ticket so it isn't lost.
24.Your JavaScript bundle has doubled in a year and the page is slow. Where do you start?
What they're really asking: Practical performance work in a real codebase.
Answer outline
- Run a bundle analyser to find the heaviest dependencies.
- Replace or lazy-load heavy libraries, split by route and remove dead code.
- Add a size budget to CI so it can't creep back.
Full sample answer (fictional example)
I'd run a bundle analyser to see what grew: usually one or two libraries, such as a date or charting package, or code duplicated across chunks. Then I'd replace heavy libraries with lighter ones, lazy-load anything below the fold or behind a click, split code by route, and remove dead code. I'd check each change against the analyser and a Lighthouse run. To stop it creeping back, I'd add a bundle size budget to CI that fails the build, so growth becomes a conscious decision.
25.Product wants a feature live tomorrow that fails accessibility checks. How do you respond?
What they're really asking: Can you balance speed against legal and ethical risk?
Answer outline
- Explain the risk: users locked out, and legal exposure in many markets.
- Offer the smallest accessible version that still meets the deadline.
- If you're overruled, log the gap with a fix date and an owner.
26.Users say the app is broken, but it works on your machine. What do you do?
What they're really asking: Can you find a bug that only exists on someone else's device?
Answer outline
- Ask for the browser, device, account and steps, and check error monitoring.
- Reproduce with the same browser version, a slow network or an empty cache.
- Check what differs: feature flags, an old cached bundle, a CDN or an ad blocker.
Full sample answer (fictional example)
I'd get the facts first: browser and version, device, account, the steps, and a screenshot or recording. Then I'd check error monitoring for that session. I'd try to reproduce with the same browser version, a slow network, an empty cache and the same account state. If it still works for me, I'd look at what differs: a feature flag, an old cached bundle, a CDN edge, an ad blocker or an extension. I'd keep the user informed, and if I can't reproduce it, add logging so the next occurrence tells us more.
27.Your site is broken on Safari, but the team never tests it. What do you do?
What they're really asking: Do you fix the issue and the gap in coverage?
Answer outline
- Reproduce on a real device or cloud browser, and fix the cause, not with a hack.
- Check analytics for the Safari share to judge urgency.
- Add Safari to the CI browser matrix so it can't regress.
28.A design system component doesn't fit a new design. Do you fork it?
What they're really asking: Judgement: when does consistency beat speed, and when not?
Answer outline
- First ask the design system team whether a variant or prop could cover it.
- If it can't wait, build a local wrapper, not a copy, and file the request.
- Record the gap and revisit it, so the divergence doesn't become permanent.
29.A third-party script is slowing the page. How do you handle it?
What they're really asking: Can you challenge a business tool with data?
Answer outline
- Measure its cost in load time and blocking time with a performance trace.
- Load it after the main content, with async or defer, or on interaction.
- Show the owner the numbers and agree a budget so it can go if it doesn't pay back.
30.A stakeholder wants a heavy animation that stutters on cheap phones. What do you say?
What they're really asking: Can you explain trade-offs in terms of users and outcomes?
Answer outline
- Test on a low-end device and show a recording, not an opinion.
- Offer options: simpler motion, transform and opacity only, or a reduced-motion fallback.
- Respect the prefers-reduced-motion setting whatever is decided.
Red flags to avoid in your answers
Each one is quick to fix before the day.
Treating accessibility as a bonus.
Mention keyboard use, focus and labels as part of building a component, not a later pass.
Naming a framework with no browser fundamentals behind it.
Explain the idea in plain JavaScript or CSS first, then say what the framework adds.
Optimising before measuring.
Name the tool you'd measure with and the metric you'd move before you describe any fix.
Blaming designers or the API team for rough edges.
Describe how you worked through the gap together and what you changed in your handoff.
How to prepare for a frontend developer interview in 7 days
An hour or two a day is enough; the order matters more than the length.
Day 1: Scan the stack
List the framework, testing and build tools named in the ad, then open the company's site with a screen reader and Lighthouse.
Day 2: JavaScript core
Explain the event loop, closures, promises and this out loud for two minutes each, then fix the gaps.
Day 3: Build a component
Build a typeahead without a framework in 60 minutes, covering states, keyboard use and cancelled requests.
Day 4: React and state
Review rendering, effects and state options, and write a short answer on where each kind of state should live.
Day 5: Speed and access
Audit one page with Lighthouse and a screen reader, and write three fixes in order of impact.
Day 6: Stories, then mock
Prepare five STAR stories, then run a mock with a friend: one UI exercise and three behavioural questions.
Day 7: Portfolio and rest
Open the project you'll demo and rehearse a five-minute tour, prepare three questions, then rest.
Questions to ask the interviewer
Pick two or three; the answers tell you whether you want the job.
- Which framework and build tools do you use, and are any migrations planned?
- How do designers and frontend developers hand work over here?
- How do you measure frontend performance and accessibility today?
- Is there a shared component library, and who maintains it?
- How often do you ship, and how is a bad release rolled back?
Preparation tips
- Practise building a small component without a framework, since some interviews don't allow one.
- Be ready to explain closures, this, promises and the event loop in plain words.
- Bring a project you can open live and walk through: structure, state, tests and trade-offs.
- Run Lighthouse and a screen reader on the company's own site first; one specific observation goes a long way.
Prepare the general questions too: tell me about yourself, why do you want to work here? and why are you leaving? Afterwards, send a thank-you email; when the offer comes, negotiate the salary.
How we wrote this page
The FindAJobAI team wrote the questions, outlines and sample answers for frontend developer interviews. The people, employers and numbers in the samples are invented: copy the structure, and use details from your own work.
The live skills section is based on 453 frontend developer job ads analysed, the newest we track, with the same deterministic skill matcher as our in-demand skills report: no AI model reads the postings. It was last computed on November 2, 2026 and refreshes daily.
Last reviewed on November 1, 2026.