Frontend developer mock interview — practice with AI

Frontend interviews probe two things at once: whether you ship UI, and whether you understand what's actually happening when a browser renders a page. The questions that decide offers usually sit at the seam — "why is this slow?", "why is this inaccessible?", "why doesn't this state update?". This guide shows how to use AI mocks to drill the answers until they're automatic.

The shape of a modern frontend interview

A typical frontend loop has four stages: a screening call with the recruiter, a technical screening (45–60 minutes, one engineer asking you about your stack and shipping experience), a take-home or live coding exercise, and an on-site or virtual loop with 3–5 rounds (coding, system design for UI, behavioral, sometimes a design critique). Senior loops add an architecture round where you have to defend a UI system from someone trying to break it.

AI mocks help most with the technical screening and the UI system design round. Both are mostly conversation. The coding exercises you should practice in a real editor — AI mocks are bad at giving you the feedback loop of "did this actually run?". For interview rounds where the answer is paragraphs ("describe how React reconciles a list" or "walk me through making this page faster"), AI mocks reproduce the format almost perfectly.

JavaScript and TypeScript: what interviewers actually probe

The classic JS questions still show up because they still work as filters. Closures, hoisting, this binding, the event loop, micro vs macro tasks, promises vs async/await, the difference between == and === — all reasonable expectations. But the interesting questions are one layer deeper. Not "what is a closure", but "why does this setTimeout inside a for loop log the wrong number, and how do you fix it three different ways?".

TypeScript questions you should be able to answer

• Difference between interface and type, and when each is right.
• What unknown gives you that any doesn't.
• How discriminated unions narrow types in practice.
• When generics help and when they make code unreadable.
• What as const does, and why you'd reach for it.

The trap to avoid: don't quote the docs verbatim. Interviewers can tell. Talk about real code — "I used a discriminated union last quarter for our payment status types because the compiler caught a bug where we forgot to handle the refunded case".

React and Vue: framework-level questions

React

Expect reconciliation, the rules of hooks, what causes a re-render, why useEffect with the wrong dependency array breaks things, how useMemo vs useCallback differ in practice, when to lift state and when to colocate, server components vs client components if you're interviewing for a Next.js role. The most common failure mode: candidates explain hooks rules but can't say why the rules exist. The reason is React uses call order to associate hook calls with state — break the order, you break the association.

Senior-level React questions push into perf and architecture. How would you make a list of 10,000 items scrollable without dropping frames? When does virtualization help and when does it hurt? How do you measure if a memo is actually helping or just adding overhead? The AI mock will follow up — if you say "I'd use virtualization", expect "with what library, why that one, and what does it cost you?".

Vue

Vue 3 specific topics: the composition API vs options API, when reactivity breaks (assigning to an index, replacing the whole array), ref vs reactive, how the proxy-based reactivity differs from React's. Vue interviewers love to ask about reactivity gotchas because the model is more "magical" than React's, and magical models have more edges.

Browser internals, performance, accessibility

Browser internals

The DOM is a tree, the CSSOM is a tree, the render tree is what you actually paint. Style invalidation, layout (reflow), paint, composite — know the pipeline and what triggers each stage. A reliable interview question: "why is animating top bad and animating transform good?". Answer: transform skips layout and paint, runs on the compositor thread.

Performance

Core Web Vitals matter to anyone running a public site. LCP, INP (which replaced FID in early 2024), CLS — be ready to define each, say which user behavior it correlates with, and name one or two ways to improve each. Bundle splitting, lazy loading routes, image format choice (AVIF/WebP), fetchpriority, the resource hints (preload, preconnect, dns-prefetch). If you've ever shipped a perf improvement and have the before/after metric, lead with it.

Accessibility

Keyboard navigation order, focus traps for modals, ARIA roles vs semantic HTML (prefer semantic), color contrast ratios (4.5:1 for body text, 3:1 for large), screen reader behavior with dynamic content (aria-live), accessible names for icon-only buttons. A common trick question: "is a div with onclick accessible?" — answer no, you need tabindex, keyboard handlers, and a role, or just use a button.

Behavioral rounds: don't underestimate them

Frontend candidates routinely lose offers in the behavioral round because they treat it as small talk. It isn't. Expect: a story about a hard technical decision, a story about cross-functional conflict (designer vs engineer is the canonical frontend scenario), a story about shipping something with a tight deadline, a story about a production incident. Have three or four stories ready that you can adapt — STAR format (Situation, Task, Action, Result), with the Result being a metric or concrete outcome.

One specific frontend pitfall: when asked "tell me about a tough technical decision", candidates often pick a framework migration (React to Vue, Webpack to Vite). Those are fine but generic. A stronger story is a specific UI/UX tradeoff — "we shipped a feature with optimistic updates and accepted occasional reconciliation flicker because the latency win was worth more than the visual polish". Real, specific, and reveals judgment. See our behavioral interview practice guide for the full STAR framework.

Frequently asked questions