What the frontend engineer interview looks like

Frontend engineer interviews test a mix of JavaScript fundamentals, UI implementation skills, and frontend-specific system design. Most processes take 2–4 weeks across 3–5 rounds. Here’s what each stage looks like and what they’re testing.

  • Recruiter screen
    30 minutes. Background overview, framework experience, and salary expectations. They’re checking for basic role fit and confirming your frontend focus.
  • Technical phone screen
    45–60 minutes. Live coding focused on JavaScript fundamentals: DOM manipulation, async patterns, or building a small UI component. Usually on CodeSandbox or CoderPad.
  • Onsite (virtual or in-person)
    4–5 hours across 3–4 sessions. Typically includes a JavaScript/algorithm round, a UI component build (often in React or vanilla JS), a frontend system design round, and a behavioral round.
  • Hiring manager chat
    30 minutes. Team fit, career goals, and collaboration style. Often the final signal before an offer decision.

Technical questions you should expect

Frontend interviews blend traditional coding questions with UI-specific challenges. You’ll need to demonstrate deep JavaScript knowledge, CSS proficiency, and the ability to build real UI components under time pressure.

Explain the difference between the event capturing and bubbling phases. How would you use event delegation?
Tests core DOM knowledge that separates frontend specialists from generalists.
When an event fires, it first travels down from the document root to the target element (capturing phase), then back up (bubbling phase). Event delegation leverages bubbling: instead of attaching a listener to every list item, attach one to the parent ul and check event.target to identify which item was clicked. This reduces memory usage and handles dynamically added elements automatically. Mention stopPropagation() and when you’d actually need capturing (rare, but useful for intercepting events before children see them).
Build an auto-complete search input that fetches suggestions from an API.
This is the classic frontend system design question — they want to see debouncing, caching, error handling, and accessibility.
Start with requirements: debounce the input (300ms typical) so you don’t fire a request on every keystroke. Use an AbortController to cancel in-flight requests when the user types again. Cache recent results in a Map so repeated queries don’t hit the API. For the UI: use an aria-combobox pattern with aria-activedescendant for keyboard navigation. Handle loading, error, and empty states. Mention that you’d add a minimum character threshold (usually 2–3 characters) before triggering requests.
What causes layout thrashing, and how do you avoid it?
Tests performance optimization knowledge that matters in real production apps.
Layout thrashing happens when you read a layout property (like offsetHeight), then write to the DOM (change a style), then read again — forcing the browser to recalculate layout multiple times in a single frame. To avoid it: batch all reads together, then batch all writes. Use requestAnimationFrame to schedule DOM writes. For complex cases, use the will-change CSS property to promote elements to their own compositing layer. Tools like Chrome DevTools’ Performance tab can identify forced reflows.
Explain how React’s reconciliation algorithm works and why keys matter in lists.
They’re testing whether you understand the framework deeply, not just use it.
React maintains a virtual DOM and diffs it against the previous version to compute the minimum set of real DOM updates. For lists, React uses keys to identify which items changed, moved, or were removed. Without stable keys, React falls back to index-based comparison, which can cause incorrect reuse of component state when items are reordered or deleted. Keys should be stable, unique identifiers (database IDs), not array indices. Mention that this is why using Math.random() as a key defeats the purpose entirely.
Design the frontend architecture for a real-time collaborative document editor.
Frontend system design question testing your ability to think about state management, syncing, and user experience at scale.
Start with the core challenge: conflict resolution when multiple users edit simultaneously. Discuss Operational Transforms (OT) or CRDTs as the syncing mechanism. For the frontend: use WebSockets for real-time updates, an immutable state model for undo/redo, and optimistic UI updates for responsiveness. Address cursor presence (showing where other users are editing), offline support (queue operations and replay on reconnect), and how you’d chunk the document for large files. Mention the tradeoff between simplicity (polling) and real-time feel (WebSockets).
How does the CSS specificity system work? Walk through how the browser resolves conflicting styles.
Foundational CSS knowledge that many frontend candidates can’t explain clearly.
Specificity is calculated as a tuple: (inline styles, IDs, classes/attributes/pseudo-classes, elements/pseudo-elements). An ID selector (#nav) beats any number of class selectors. !important overrides everything except other !important rules with higher specificity. When specificity is equal, the last rule in source order wins. Mention the cascade layers (@layer) feature in modern CSS, which gives you explicit control over the cascade order. Explain that * has zero specificity and that combinators (>, +) don’t affect specificity.

Behavioral and situational questions

Behavioral questions in frontend interviews often focus on collaboration with designers, handling ambiguous requirements, and making tradeoff decisions about user experience. Use the STAR method (Situation, Task, Action, Result) for every answer.

Tell me about a time you had to push back on a design that was technically impractical.
What they’re testing: Collaboration with designers, communication skills, ability to propose alternatives.
Use STAR: describe the Situation (what the design called for and why it was problematic), your Task (your responsibility to flag the issue), the Action you took (how you communicated the constraint and proposed an alternative that preserved the design intent), and the Result (what shipped and how the designer responded). The best answers show partnership, not adversarial pushback.
Describe a time you improved the performance of a web application significantly.
What they’re testing: Performance optimization skills, measurement-driven approach, technical depth.
Start with the metric — what was slow and how did you measure it? (Lighthouse score, Core Web Vitals, user-reported latency.) Then describe your investigation (profiling, network waterfall analysis, bundle analysis). Walk through the specific optimizations you made: code splitting, lazy loading, image optimization, reducing render-blocking resources. End with the measurable result: “LCP improved from 4.2s to 1.8s, and bounce rate dropped 12%.”
Tell me about a time you had to ship a feature with incomplete requirements.
What they’re testing: Comfort with ambiguity, ability to make reasonable assumptions, iterative thinking.
Explain the ambiguity clearly: what was missing and why. Describe how you unblocked yourself: did you build a prototype to get feedback? Make reasonable defaults and document your assumptions? Ship an MVP and iterate? Show that you communicated proactively with product and design rather than waiting for perfect specifications. The Result should show that your approach led to a good outcome despite the uncertainty.
Give an example of a time you mentored another engineer or helped someone on your team grow.
What they’re testing: Teamwork, knowledge sharing, leadership potential beyond your own output.
Pick a specific example with a clear arc. Describe what the person was struggling with, how you identified the gap, what approach you took (pair programming, code reviews with detailed explanations, recommending specific resources), and the outcome (they shipped a feature independently, got promoted, or became the team’s go-to person for that area). Show that you invested time because it made the whole team stronger.

How to prepare (a 2-week plan)

Week 1: Build your foundation

  • Days 1–2: Review core JavaScript concepts: closures, prototypal inheritance, event loop, promises and async/await, the this keyword. Use MDN or javascript.info as your reference.
  • Days 3–4: Practice building UI components from scratch: a debounced search input, a modal with focus trapping, an infinite scroll list, a drag-and-drop interface. Build in vanilla JS first, then in your framework of choice.
  • Days 5–6: Study frontend system design: how to architect a news feed, a chat application, or an image gallery. Focus on data flow, state management, API design, caching, and performance considerations.
  • Day 7: Rest. Burnout before the interview helps no one.

Week 2: Simulate and refine

  • Days 8–9: Do mock interviews focused on live component building. Practice talking through your decisions out loud: “I’m using a ref here because I need to access the DOM node directly for focus management.”
  • Days 10–11: Prepare 4–5 STAR stories from your resume. Map each story to common themes: performance optimization, design collaboration, shipping under pressure, and handling technical debt.
  • Days 12–13: Research the specific company. Inspect their website’s frontend (open DevTools!), read their engineering blog, and understand their tech stack. Prepare 3–4 specific questions about their frontend architecture.
  • Day 14: Light review only. Skim your notes, build one small component to stay sharp, and get a good night’s sleep.

Your resume is the foundation of your interview story. Make sure it sets up the right talking points. Our free scorer evaluates your resume specifically for frontend engineer roles — with actionable feedback on what to fix.

Score my resume →

What interviewers are actually evaluating

Frontend interviews evaluate a specific blend of skills that combine engineering fundamentals with UI expertise. Here’s what interviewers score on.

  • JavaScript depth: Do you truly understand the language — closures, the event loop, async patterns — or do you rely on framework abstractions? Can you solve problems in vanilla JS when needed?
  • UI implementation quality: Can you build components that are accessible, performant, and handle edge cases (loading states, errors, empty states, keyboard navigation)? Do you think about the user, not just the code?
  • Performance awareness: Do you understand Core Web Vitals, rendering pipeline, bundle size, and how your code affects perceived load time? Can you identify and fix performance bottlenecks?
  • Communication and collaboration: Can you discuss tradeoffs with designers and product managers? Can you explain your technical decisions in terms non-engineers understand?
  • System thinking: Can you architect a frontend system that scales — component structure, state management, API integration, error boundaries — not just build isolated widgets?

Mistakes that sink frontend engineer candidates

  1. Ignoring accessibility entirely. If you build a dropdown menu without keyboard navigation or ARIA attributes, that’s a significant miss. Accessibility is table stakes for senior frontend roles.
  2. Not talking about performance. Every UI decision has performance implications. Mention them proactively: “I’m debouncing this because firing on every keystroke would be wasteful.”
  3. Only knowing framework APIs, not underlying concepts. If you can’t explain how React’s virtual DOM works, or what problem state management libraries solve, you’ll struggle with deeper questions.
  4. Writing CSS as an afterthought. Frontend interviews test CSS. Know flexbox, grid, specificity, responsive design patterns, and CSS custom properties. “I’m not really a CSS person” is a red flag for frontend roles.
  5. Skipping error and edge case handling. The difference between a good and great frontend candidate is handling what happens when the API is slow, the response is empty, the user double-clicks, or the network drops mid-action.
  6. Not preparing for frontend system design. Many candidates only practice algorithms and miss the frontend-specific design round entirely. This round tests your real-world architecture skills.

How your resume sets up your interview

Your resume is not just a document that gets you the interview — it’s what the interviewer will reference when asking about your experience. Every project or metric you list is a potential deep-dive question.

Before the interview, review each bullet on your resume and prepare to go deeper:

  • What was the UI challenge, and why was it technically difficult?
  • What performance trade-offs did you make, and how did you measure the impact?
  • How did you collaborate with designers or backend engineers?
  • What would you improve about the implementation if you rebuilt it today?

A well-tailored frontend resume highlights specific technologies (React, TypeScript, performance optimization) and measurable outcomes (“Reduced bundle size by 35%, improving LCP from 3.8s to 2.1s”). These create natural interview talking points.

If your resume doesn’t set up these conversations well, our frontend engineer resume template can help you restructure it before the interview.

Day-of checklist

Before you walk in (or log on), run through this list:

  • Review the job description one more time — note the specific frameworks, tools, and UI expectations mentioned
  • Prepare 3–4 STAR stories from your resume that demonstrate frontend-specific impact
  • Practice building at least one UI component from scratch with accessibility and edge case handling
  • Test your development environment and screen sharing setup if the interview is virtual
  • Prepare 2–3 thoughtful questions about the company’s frontend architecture and design process
  • Review your knowledge of CSS layout (flexbox, grid) and responsive design patterns
  • Have water and a notepad nearby
  • Plan to log on or arrive 5 minutes early