Front End Developer interview questions and how to answer them
A front end interview tests two things at once: whether you understand how the browser really works, and whether you can build something usable while someone watches. The questions below are the ones that come up again and again, with what the interviewer is listening for. Expect to write code in most rounds, so practice out loud.
What happens in each round
- 1
Recruiter screen
What happens
Whether your stack matches the posting, which frameworks you've shipped with, and whether your expectations on level and location line up with the role.
- 2
Take-home or online coding exercise
What happens
Clean, readable code in JavaScript or TypeScript, sensible component structure, and whether you handled loading, empty and error states without being told to.
- 3
Live coding with an engineer
What happens
How you think under light pressure. Usually a small UI like an autocomplete or a tabbed panel, built in a shared editor or CodeSandbox while you talk through your choices.
- 4
Front end system design
What happens
For mid-level and senior roles: how you'd structure a larger feature such as a news feed or a chat window, including state, data fetching, caching and performance.
- 5
Behavioral and team fit
What happens
How you work with designers and back end engineers, how you handle pushback in code review, and how you talk about mistakes you've made.
Questions you're likely to get
1.Explain the JavaScript event loop and what happens when a promise resolves.
Why they ask
Async bugs are some of the hardest to track down in a UI. They want to know you understand why a state update lands after you expected it to.
How to answer
- Describe the call stack, the task queue and the microtask queue in plain terms
- Explain that promise callbacks run as microtasks before the next task, like a setTimeout callback
- Give a short example where the order of console logs surprises people
- Connect it to a real bug, such as a stale value read inside an async handler
2.Walk me through what happens between typing a URL and seeing the page.
Why they ask
It's a broad question that shows how much of the stack you understand, and it opens the door to performance follow-ups.
How to answer
- Cover DNS lookup, the connection, and the HTTP request and response briefly
- Spend most of your time on parsing HTML, building the DOM and CSSOM, layout and paint
- Explain how render-blocking scripts and stylesheets delay first paint
- Mention what you'd do about it: defer or async scripts, preloading key assets, trimming the bundle
3.How would you make this component accessible?
Why they ask
Many teams have been burned by inaccessible releases. They want someone who builds it in from the start, not someone who adds it when legal asks.
How to answer
- Start with semantic HTML: a real button, a real label tied to its input
- Check keyboard use: tab order, visible focus, and Escape closing a modal
- Use ARIA only where native elements can't do the job, and say why
- Name how you test it, such as a screen reader like VoiceOver or NVDA plus axe DevTools
4.A page feels slow. How do you figure out why?
Why they ask
Performance work separates people who guess from people who measure.
How to answer
- Measure first with Lighthouse and the Performance panel in Chrome DevTools
- Separate load problems from runtime problems like janky scrolling or slow typing
- Name specific fixes: code splitting, lazy loading images, memoizing expensive renders, virtualizing long lists
- Say how you'd confirm the fix worked and keep it from coming back
5.When would you reach for a global state library instead of local component state?
Why they ask
Over-engineered state is one of the most common messes in front end codebases. They want judgment, not loyalty to a library.
How to answer
- Default to local state and lifting it up when siblings need it
- Separate server data from UI state, and mention a tool like TanStack Query or SWR for the first
- Reach for Redux, Zustand or context when many distant parts of the app read and write the same data
- Mention the cost: boilerplate, harder debugging, and re-renders if context is misused
6.Why does this React component re-render so often, and how would you fix it?
Why they ask
It checks whether you understand how the framework you'll use every day actually decides to update.
How to answer
- Explain what triggers a render: state change, parent render, context change
- Point to common causes like new object or function references created on every render
- Talk about useMemo, useCallback and React.memo, and when they're not worth the complexity
- Mention using the React DevTools profiler to confirm before changing anything
7.Build an autocomplete search box that calls an API as the user types.
Why they ask
It's small enough for a live session but hides several real problems: request timing, stale results and keyboard use.
How to answer
- Debounce input so you don't fire a request on every keystroke
- Handle out-of-order responses, for example with AbortController or by ignoring stale results
- Show loading, empty and error states
- Support arrow keys and Enter, and talk through what you'd add with more time
8.How do you approach CSS layout for a page that has to work from a small phone to a wide monitor?
Why they ask
Plenty of candidates are strong in JavaScript and shaky in CSS. Layout bugs are what users notice first.
How to answer
- Start mobile first and add breakpoints where the design actually breaks
- Choose Flexbox for one direction and Grid for two, with an example of each
- Mention fluid sizing with relative units and clamp
- Talk about how you'd check it: device mode in DevTools and at least one real phone
9.How do you test front end code?
Why they ask
They want to know whether your tests catch real bugs or just raise a coverage number.
How to answer
- Unit test logic with Jest or Vitest
- Test components the way a user sees them, with React Testing Library queries by role and label
- Keep a small set of end-to-end tests in Playwright or Cypress for the flows that matter most
- Say what you don't test and why
10.Tell me about a time you disagreed with a designer about a UI decision.
Why they ask
Front end developers sit between design and engineering. How you handle that seam says a lot about how you'll fit.
How to answer
- Describe the specific decision and why it mattered, such as a pattern that failed keyboard users
- Explain how you raised it: a prototype, a quick screen recording, or a comment in Figma
- Show that you listened and changed your mind on part of it
- End with what shipped and what you'd do the same way again
11.Tell me about a bug you shipped to production.
Why they ask
Everyone ships bugs. They're checking whether you own them and learn something that sticks.
How to answer
- Pick a real one with a clear user impact
- Explain how it was found and how you fixed it quickly
- Name the gap that let it through, like a missing test or an untested browser
- Say what changed afterward so it didn't happen again
Mistakes that sink good candidates
Going silent during live coding
Talk through what you're trying, even when you're stuck.
Naming frameworks you've only followed a tutorial for
A single follow-up question will expose it.
Ignoring error and loading states in a take-home because the brief didn't mention them
Dismissing CSS or accessibility as someone else's job
Need more Front End Developer interviews to prep for?
HeroApply applies to Front End Developer jobs that match you, every day. 391 jobs are open today.