Frontend Engineer interview questions, and how to answer them
Frontend engineer loops test whether you can build a working UI under pressure and whether you understand why the browser behaves the way it does. Expect live coding in plain JavaScript, a system design round built around a real screen, and questions about how you've kept an app fast and accessible. The rounds below are the usual order, though smaller companies squeeze them together.
What happens in each round
- 1
Recruiter screen
What happens
Whether your framework experience matches their stack, what level you're aiming for, and whether you can explain a past project in plain words.
- 2
Technical phone screen
What happens
JavaScript fundamentals in a shared editor: closures, promises, the event loop, array methods. Often a small utility like debounce or a deep clone.
- 3
UI coding round
What happens
Building a real component live, such as an autocomplete or a tabbed panel, with sensible state, keyboard support and clean markup.
- 4
Frontend system design
What happens
How you'd architect something like a news feed or a collaborative editor: data fetching, caching, rendering strategy, performance and failure states.
- 5
Behavioral and team fit
What happens
How you handle disagreement with designers and backend engineers, how you review code, and how you own a bug that reached users.
Questions you're likely to get
1.Build an autocomplete input that fetches suggestions as the user types.
Why they ask
It packs debouncing, async state, race conditions, keyboard handling and accessibility into one small component. Most loops include some version of it.
How to answer
- Debounce the input and cancel stale requests with an AbortController so an old response can't overwrite a newer one
- Model loading, empty, error and results states explicitly instead of guessing from null checks
- Support arrow keys, Enter and Escape, and use the combobox and listbox roles with aria-activedescendant
- Mention caching recent queries and what you'd test first if you had more time
2.Walk me through what happens between typing a URL and seeing a rendered page.
Why they ask
It shows whether you know the pipeline your code runs inside, which is what separates engineers from people who only know a framework.
How to answer
- DNS lookup, TCP and TLS connection, the HTTP request and response
- Parsing HTML into the DOM, CSS into the CSSOM, and how render-blocking scripts and stylesheets delay the first paint
- Layout, paint and compositing, and what triggers each one again
- Tie it back to a real fix, like deferring a script or preloading a font
3.How would you design the frontend for an infinite-scrolling feed?
Why they ask
This is the classic frontend system design prompt. They want structure, tradeoffs and awareness of scale on the client.
How to answer
- Clarify requirements first: media types, real-time updates, offline, how deep people scroll
- Cursor-based pagination and a normalized client cache with something like TanStack Query or Apollo
- List virtualization so the DOM doesn't grow forever, and placeholders to stop layout shift
- Error and retry states, scroll position restore on back navigation, and how you'd measure it in production
4.Explain the event loop, and predict the output of this snippet with setTimeout and a resolved promise.
Why they ask
Async ordering bugs are common in UI code, and this checks whether you can reason about them without running the code.
How to answer
- Synchronous code runs first on the call stack
- Microtasks like promise callbacks drain before the next macrotask
- Timers and events queue as macrotasks, and rendering can happen between them
- Give the correct order and say where you've seen this cause a real bug
5.When would you choose server rendering, static generation or client rendering for a page?
Why they ask
Engineers at this level often own that choice in Next.js, Remix or Nuxt, and the wrong call costs speed or search traffic.
How to answer
- Static generation for content that rarely changes, like marketing and docs pages
- Server rendering for personalized or fresh pages that still need fast first paint and indexing
- Client rendering for dashboards behind a login where search doesn't matter
- Mention hydration cost, streaming and caching headers, and that one app usually mixes all three
6.A key page got slower after a release. How do you find out why?
Why they ask
Performance work is a core part of the engineer title, and they want a method rather than a list of tips.
How to answer
- Confirm it with field data from real users, not only a Lighthouse run on a fast laptop
- Compare bundle analyzer output between the two builds to spot new dependencies
- Use the DevTools Performance panel to find long tasks, layout thrashing or extra renders
- Fix the biggest cause, then add a performance budget in CI so it can't sneak back
7.How do you decide where state should live in a React app?
Why they ask
State sprawl is the most common reason frontend codebases rot, and they want to see restraint.
How to answer
- Keep state as local as possible and lift it only when siblings genuinely share it
- Treat server data as a cache managed by a data-fetching library, not global state
- Put shareable UI state like filters in the URL
- Reach for Redux, Zustand or context only for truly global client state, and say why
8.How do you make a custom dropdown or modal accessible?
Why they ask
Custom widgets are where accessibility breaks, and many companies have legal or contract reasons to care.
How to answer
- Start from native elements where possible, like a real button or select
- Manage focus: trap it in a modal, return it to the trigger on close
- Use correct ARIA roles and states, and full keyboard support
- Test with a screen reader such as VoiceOver or NVDA and an automated checker like axe
9.What's your approach to testing a frontend feature?
Why they ask
They want to know whether your tests catch real bugs or just pad coverage.
How to answer
- Unit tests for pure logic like formatters and reducers
- Component tests with React Testing Library that query by role and label, like a user would
- A small number of end-to-end tests in Playwright or Cypress for the flows that make money
- Mock the network with something like MSW rather than mocking internal modules
10.Tell me about a time you pushed back on a design or product request.
Why they ask
Frontend engineers sit between design, product and backend, and friction there is daily.
How to answer
- Name the specific request and why it was a problem, such as a pattern that failed keyboard users or doubled load time
- Show that you offered an alternative, not just a no
- Explain how you brought evidence, like a prototype or a performance trace
- Say what shipped and what you'd do differently
11.Tell me about a bug you shipped to production.
Why they ask
Everyone ships bugs. They're checking ownership and whether you fixed the cause, not just the symptom.
How to answer
- What broke and how it was spotted, ideally through Sentry or monitoring rather than a customer
- How you stopped the bleeding, such as a feature flag or rollback
- The root cause and the change that prevents a repeat, like a new test or lint rule
- What the team changed afterward
Mistakes that sink good candidates
Talking only about React APIs and going quiet when asked how the browser itself works
Coding the UI round in silence instead of narrating your choices and asking about edge cases
Dismissing accessibility or testing as something another team handles
Trashing a previous codebase or framework without explaining the tradeoffs that led there
Need more Frontend Engineer interviews to prep for?
HeroApply applies to Frontend Engineer jobs that match you, every day. 500 jobs are open today.