Frontend Engineer Interview Questions and Answers

What Frontend Engineer interviewers assess

This is the real work sitting behind the questions. They are checking whether you have actually done it, not whether you can describe it.

• JavaScript fundamentals: Closures, the event loop, promises and async/await, prototypes, equality. You will get at least one question aimed straight at the language itself.
• React and component architecture: Hooks, state management, rendering behavior, memoisation, and how you break a messy UI into components you can actually test.
• CSS, layout, and design systems: Flexbox, grid, responsive design, design tokens, and turning a Figma file into styles that are pixel-accurate and still readable in a year.
• Performance and Web Vitals: Bundle size, code splitting, image optimization, LCP, CLS, INP. You should be able to diagnose all of it with Lighthouse and DevTools.
• Accessibility: Semantic HTML, ARIA only where it earns its place, keyboard navigation, focus management, and actually testing with a screen reader on.
• Tooling and DX: Bundlers, TypeScript, testing libraries, monorepo trade-offs, and how you set a project up so a whole team can ship into it without fear.

Common Frontend Engineer interview questions with answer guidance

1. Explain how the JavaScript event loop works.

Start with the call stack and the single-threaded execution model. Bring in the task queue (macrotasks) and the microtask queue, and say that microtasks (Promises, queueMicrotask) drain between every macrotask. Walk a tiny example with setTimeout and Promise.resolve so the ordering is visible. Finish with why it matters in real life: block the main thread and you starve the UI.

2. Build a debounce function from scratch.

Ask whether the caller wants leading, trailing, or both edges to fire. Build the trailing case first: store a timeout id, clear it on every call, schedule a new one. Show how this/arguments get forwarded. Talk through the test cases: rapid calls, a single call, a cancel method. Mention throttle as the cousin and when each one fits.

3. How do you decide between server-side rendering, client-side rendering, and static generation?

Split it by content type and traffic pattern. Static for content that rarely changes and has to rank in search. SSR for personalised, SEO-critical pages where freshness matters. CSR for app-shell experiences behind auth. Bring in the hybrid patterns (ISR, streaming, RSCs) and name the trade-offs out loud: TTFB, hydration cost, infra complexity.

4. A page is slow to load. How would you investigate?

Reproduce it first on the same network and device profile. Open the Performance and Network tabs and look at LCP, blocking resources, render-blocking CSS, fat JS bundles. Use Lighthouse and Web Vitals. Take one hypothesis at a time and prove it with a measurement before you change a line. Talk about performance budgets and how you stop the regression coming back.

5. How would you make a complex dropdown accessible?

Say you would reach for a tested primitive (Radix, React Aria) before hand-rolling anything. If you have to build it, cover keyboard nav (arrow keys, Home/End, type-ahead), the focus trap while it is open, aria-expanded, aria-activedescendant or roving tabindex, escape to close, and screen reader announcements. Say you test with VoiceOver/NVDA and keyboard only.

6. Tell me about a UI you built that you are proud of.

Pick something with real users and an outcome you can measure. Walk through the problem, your design and engineering decisions, and the one constraint that forced a trade-off. Say how you worked with designers or PMs. Close with the metric that moved or the qualitative signal you saw. Match the technical depth to whoever is in the room.

7. Implement a custom React hook that fetches data with loading and error states.

Sketch the API before you type: useFetch(url) returns { data, error, loading }. Walk through useState for the three flags, useEffect to fire the fetch, and the cleanup pattern (AbortController) so you never set state on an unmounted component. Talk about memoising the URL, handling re-fetches, and why a library like React Query usually wins in production anyway.

8. How do you keep a large component library consistent across teams?

Treat design tokens as the contract, keep one source of truth for components, and version it clearly. Cover docs (Storybook), visual regression tests, lint rules that stop people bypassing tokens, and an intake process for new components. Say how you balance flexibility against consistency, and how you move every consumer along when a primitive changes.

9. Describe a time you pushed back on a design.

Pick a time the push-back was about user impact or feasibility, not personal taste. Show that you got the designer’s intent first, then named the concrete cost (performance, accessibility, complexity) and offered an alternative. Say whether you got the change or met in the middle. Make it obvious you respect design as a craft.

10. How would you architect state in a large React app?

Keep server state (React Query, SWR) apart from client state (UI, form state). Use local component state by default, lift it only when you must, and reach for a global store (Zustand, Redux Toolkit, Context) rarely. Explain why colocation keeps complexity down. Name the pitfalls: prop drilling, over-globalising, stale cache invalidation. Tie it to a real codebase you have lived in.

11. Why are you interested in frontend specifically rather than full-stack?

Be honest about what energises you: the craft of UI, the empathy it takes, the visible impact, working across disciplines. Never frame frontend as the easier option, because that ages badly in the room. Tie your motivation to this role: the kind of frontend work the company does and why it fits you.

12. Walk me through how you would refactor a 2000-line React component.

Do not rewrite it. Read it first, write characterisation tests for the current behavior, then pull out leaf components and pure functions from the outside in. Push state down. Swap inline effects for named hooks. Keep it reviewable: lots of small PRs beats one monster. Finish with how you prove the refactor paid off (bundle size, render count, dev velocity).

How to prepare

Say each answer out loud, keep it short, and swap in an example from the job you are actually chasing.

• Build one small project using Suspense, streaming or RSCs so you are talking from experience, not from a blog post.
• Run Lighthouse and Axe over your own portfolio site and fix the top three findings before anyone else looks.
• Get a 60-second tour of one production UI you shipped down cold, with a clear before and after.
• Skim the latest React release notes. Interviewers often poke at whether you keep up.
• Practise live-coding in a shared editor so the lag and the screen-share awkwardness do not throw you on the day.