Frontend Developer Interview Prep Guide

This is the highest-leverage question to rehearse in 2026 because the scoring rubric changed. Per the Google pilot, interviewers evaluate "AI fluency, including prompt engineering, output validation, and debugging skills" — not raw typing speed. Drive the component yourself: controlled input, debounce (~300ms) with a ref-held timer, ARIA combobox/listbox/option roles with aria-activedescendant, ArrowUp/ArrowDown/Enter/Escape handling, and cancellation of stale responses so a slow request can't overwrite a newer one. Use AI for boilerplate, then say out loud what you are checking: "I'm rejecting this generated keydown handler because it doesn't move aria-activedescendant, so a screen-reader user wouldn't hear the active option." Canva's CTO put the bar plainly: "We want to see the interactions with the AI as much as the output of the tool." Treat every AI suggestion like a junior PR you own.

This is the verification round in disguise, and it is where most candidates lose points by trusting clean-looking code. Read it top-to-bottom before reacting. Check the high-frequency AI failure modes for UI code: a useEffect missing a dependency (stale closure), state derived in render that should be memoized, an event listener added without cleanup, a key that uses array index across a reorderable list, an async fetch with no cancellation, or an icon-only button with no accessible name. Reproduce the bug, name it precisely, justify the one-line fix, and add the test that would have caught it. KORE1 frames the underlying question well: "the developer's job is the part AI can't do." In 2026 that part is judgment — proving the output is correct and accessible.

Testing is a genuine elimination filter — per a hiring manager quoted by KORE1, "about 40% of candidates can write a working test without referencing documentation." Use React Testing Library (Enzyme is a red flag in 2026), mock the fetch, and use findBy/waitFor for the async state; test the loading state and the error state, not just the happy path. Then make the synthesis explicit, because it is the senior signal: query with getByRole, not getByTestId. Testing Library's documented priority says getByRole "can be used to query every element that is exposed in the accessibility tree… your top preference for just about everything," and adds "if you can't [find it], it's possible your UI is inaccessible." So a suite written with role-based queries only passes if the markup is accessible — the testing round and the accessibility round are the same skill viewed twice.

The classic machine-coding prompt, still asked at Meta and Google to see your unaided baseline. Structure it: a controlled input with an onChange handler; debounce (~300ms) using a useRef-held timer; suggestion state in useState; keyboard handling for ArrowUp, ArrowDown, Enter, and Escape; ARIA roles (combobox, listbox, option) with aria-activedescendant for screen readers. Handle the race condition where a newer request must cancel a stale response, and render explicit loading and empty states. Narrate trade-offs as you go (controlled vs uncontrolled, debounce vs throttle) — the machine-coding round grades component API design and accessibility as much as whether it works.

KORE1 is blunt about the stakes: "If you're interviewing for a Next.js role in 2026 and you can't explain the difference between a server component and a client component, the interview is effectively over before the system design round starts." Cover it precisely: Server Components render on the server, ship zero JS for themselves, can fetch data directly and access server-only resources, and cannot use state or effects or browser APIs; Client Components (marked 'use client') hydrate in the browser and own interactivity, state, and event handlers. Reach for Server Components for data fetching and static-ish content to cut bundle size; drop to Client Components at the interactivity boundary. Per GreatFrontEnd's ex-interviewers: "Default to function components. Class components are legacy: new APIs like Suspense data fetching, the use hook, Actions, Server Components, and the React Compiler are designed for function components only."

Re-renders fire from setState, a context value change, or a parent re-render. Reconciliation diffs the new tree against the old: same component type updates in place, a different type unmounts and remounts, and keys identify list items across renders. React Fiber replaced the synchronous stack reconciler with an interruptible, time-sliced model that enables concurrent features like useTransition and Suspense. Close the loop to practice: explain why useMemo/useCallback exist, when they actually help versus add noise, and how the React Compiler aims to make most manual memoization unnecessary — a current-as-of-2026 detail interviewers listen for.

Demonstrate real performance debugging. Record the interaction in the Chrome DevTools Performance panel and look for long tasks blocking the main thread, forced synchronous layouts (reading offsetHeight right after a style write), and expensive React re-renders in the flame chart. Fixes: break long tasks with scheduler.yield() or chunking, move heavy work to a Web Worker, debounce input handlers, apply CSS containment, or virtualize long lists. Anchor it in current facts: INP is "the successor metric to First Input Delay (FID)" and "an INP below or at 200 milliseconds means a page has good responsiveness" (web.dev). INP replaced FID as a Core Web Vital on March 12, 2024 — if you still call the metric FID in 2026, that reads as two years stale.

Frontend system design is its own discipline — no backend sharding here. Cover: component hierarchy (FeedContainer, FeedItem, an IntersectionObserver for infinite scroll); a normalized client cache (TanStack Query or Apollo); real-time via a WebSocket with reconnection/backoff; optimistic mutations (update UI immediately, roll back on failure); list virtualization so only visible items render; and a service worker for offline caching. Choose cursor-based pagination over offset for feeds that gain new content at the top, and say why. At senior level, name the accessibility and perf budgets (focus management on newly inserted items, an INP target) — those are the differentiators interviewers probe.

KORE1 notes the wrong answers here are more revealing than the right ones. Two answers fail: "I don't use them" (reads as out-of-touch in 2026) and "I let it write everything" (reads as no judgment). The Shopify framing captures the calibration — leadership there describes wanting engineers to use AI for "90% to 95%" of a task while still owning the last 5-10% of judgment: "I don't want you to use AI 100%. I want you to use it 90-95%." Give the disciplined answer: "Daily Cursor/Copilot user for scaffolding and refactors; I treat generated code as a strong first draft that gets the same review bar as a junior PR — I read every line, I check accessibility and effect cleanup, and I write the test that proves it." The verification clause is the signal.

Be specific. Prefer semantic HTML (nav, main, button) over div soup; add ARIA only when native HTML is insufficient; manage keyboard navigation and focus (tabindex, focus traps for modals/dropdowns); meet WCAG AA contrast (4.5:1 normal text, 3:1 large); provide visible focus indicators; and test with VoiceOver/NVDA plus axe-core in CI. Then connect it to testing, which is the senior move: because Testing Library's getByRole resolves against the accessibility tree, writing your tests with role-based queries forces the accessible markup to exist — accessibility stops being a separate checklist and becomes a property your test suite enforces.

Be specific with defensible numbers, not round inflation. For example: "I cut LCP from 4.2s to 1.8s with route-level code splitting via React.lazy, responsive WebP images with srcset, and a service worker for static assets — Lighthouse went 52 to 89 and bounce dropped over the following month." Tie the frontend change to a business metric; interviewers at Airbnb and Netflix specifically reward candidates who connect UI work to outcomes. Avoid '1000% faster'-style claims — 'LCP 4.2s to 1.8s' is both impressive and verifiable, which is exactly the register hiring managers trust.