Guided interview warm-up
Frontend interview questions and answers, beginner to advanced, with Essential 60, JavaScript, HTML, CSS, React, Angular, Vue, UI coding, debugging, testing, accessibility, performance, and system design paths.
On this page
Technology hubs
Popular clusters
Essential answers
Frontend interviews test whether you can build usable UI, explain browser and framework behavior, and debug trade-offs under time pressure. The core loop is usually implementation, concept explanation, follow-up constraints, and a short discussion of tests or edge cases. A good answer connects user behavior, data flow, rendering, accessibility, and performance instead of treating each topic as separate trivia.
Start by clarifying requirements, inputs, output states, and user interactions before writing code. Then build the smallest working version, cover edge cases, and explain how you would test failure states. This prevents overbuilding and makes trade-offs visible while there is still time to adjust.
The highest-signal JavaScript topics are execution order, closures, equality, array methods, object references, async code, and DOM interaction. These topics show up inside UI prompts because they decide when state changes, which callback runs, and whether data is copied or mutated. Weak fundamentals usually surface as stale UI, race conditions, sorting bugs, or confusing event behavior.
The event loop coordinates synchronous code, queued tasks, microtasks, rendering, and timers. Promise callbacks run as microtasks before timer callbacks from the task queue, which is why output-prediction questions often surprise people. In UI code, this affects loading states, chained async updates, and when the browser can paint.
A closure lets a function keep access to variables from the scope where it was created. That is useful for callbacks, event handlers, and debounced functions, but it can also preserve old values when the UI has moved on. Stale closures are common in delayed callbacks, effects, subscriptions, and retry logic.
Debounce waits until events stop for a delay, so it fits search boxes, validation, and resize handling where only the final value matters. Throttle limits how often a function runs, so it fits scroll, drag, and high-frequency progress updates. The edge case is cancellation: pending timers should be cleared when a component unmounts or when input becomes invalid.
A good UI coding answer renders the required states first: empty, loading, success, error, disabled, and interaction feedback. It keeps state ownership clear and avoids hiding important behavior in unexplained helpers. The strongest implementation is easy to test because each user action produces a visible, predictable result.
Reusable components should have a small public API, clear ownership of state, and predictable rendering for loading, error, and empty states. Inputs should describe behavior rather than internal implementation details. If a component needs many flags that conflict with each other, splitting it into smaller components is usually safer.
Keep state as close as possible to the UI that owns it, then lift it only when multiple parts of the tree need the same source of truth. Derived values should be computed from existing state instead of stored twice. Server data, form state, URL state, and client-only UI state usually deserve different handling because they fail and refresh differently.
Controlled inputs keep the displayed value and validation logic tied to explicit state. They are useful when the UI must show errors, disable submit, format values, or synchronize several fields. The trade-off is extra state management, so simple one-off inputs can still be uncontrolled when validation is minimal.
Keys define item identity when a UI library compares one render with the next. Stable keys preserve the right local state when rows are inserted, removed, filtered, or reordered. Index keys can be safe for static lists, but they often break forms, animations, and editable rows when order changes.
Semantic HTML uses elements that describe the meaning and structure of content, such as nav, main, button, form, label, and table. It improves accessibility, browser defaults, keyboard behavior, and search understanding before extra JavaScript is added. A div can render the same pixels, but it usually loses built-in meaning and behavior.
Labels connect visible text to an input so users, screen readers, and click targets all understand the field. Placeholders are not a replacement because they disappear during typing and often lack persistent context. Good form answers also cover error text, required fields, focus order, and submit behavior.
Start with semantic elements, keyboard support, visible focus, labels, contrast, and meaningful text alternatives. ARIA should fill gaps only when native HTML cannot express the interaction. The practical check is whether a keyboard and screen reader user can complete the same workflow as a mouse user.
Specificity decides which CSS rule wins when multiple selectors target the same property. Bugs appear when a broad selector, utility class, inline style, or later rule overrides the intended style. Debugging should inspect the winning rule first, then reduce selector complexity instead of adding more force.
Flexbox is strongest for one-dimensional layout where items flow in a row or column. Grid is better for two-dimensional layout where rows and columns need to align together. Many UI layouts use both: Grid for the page or card structure, Flexbox for alignment inside each region.
Start by checking the box model, computed styles, containing block, overflow, and the rule that actually wins. Then isolate whether the problem is sizing, positioning, stacking, alignment, or content overflow. Good debugging avoids random CSS changes and uses devtools to prove which constraint is failing.
Responsive UI uses flexible layout, fluid sizing, sensible min and max constraints, and breakpoints based on content needs. It should handle long text, narrow screens, zoom, touch targets, and images without layout shifts. A strong answer tests the awkward states, not just the default desktop design.
Prevent XSS by treating user-controlled HTML, URLs, and DOM sinks as unsafe unless they are sanitized or encoded for the exact context. Prefer textContent, safe template binding, trusted rendering pipelines, and server-side validation. The dangerous edge case is bypassing framework protections with raw HTML APIs or trusted-value escape hatches.
Cookies are sent with requests and can support server sessions, while localStorage and sessionStorage are browser-only key-value stores. Sensitive tokens should not be casually stored in JavaScript-accessible storage because XSS can read them. Storage choices should consider expiration, cross-tab behavior, request needs, and security boundaries.
Frontend tests should protect user-visible behavior and critical data flow instead of private implementation details. Good tests cover rendering states, user events, async loading, validation, accessibility expectations, and regressions around previous bugs. Brittle tests usually assert component internals that can change without breaking the user experience.
Async UI bugs often come from stale responses, missing cancellation, loading state races, or state updates after a component is gone. Reproduce the order of events first, then decide whether the latest request wins, all responses accumulate, or cancellation is required. Tests should include slow response, fast response, error, retry, and unmount cases.
Frontend memory leaks happen when listeners, timers, subscriptions, observers, detached DOM references, or unbounded caches stay alive after the UI no longer needs them. The symptom may be slower interactions, duplicate events, growing memory, or stale network work. Cleanup should be tied to component lifecycle, route changes, and cache eviction rules.
Common performance topics include bundle size, render cost, layout shift, image loading, network waterfalls, memoization, virtualization, caching, and Core Web Vitals. The best answer starts with measurement before optimization. Trade-offs matter because a faster first render can still create worse interactivity or maintainability if the fix is poorly chosen.
Hydration issues happen when the server-rendered HTML does not match what the client renders on startup. Common causes are time-dependent values, browser-only APIs, random IDs, locale differences, and conditional rendering that changes before hydration finishes. Fixes usually move unstable logic to the client boundary or make the initial server and client output deterministic.
Frontend system design is the design of a client-side experience: UI architecture, data flow, API contracts, state ownership, performance, accessibility, recovery, and observability. It is not only choosing a framework or drawing components. A strong answer explains constraints first, then connects architecture decisions to user-visible behavior.
Autocomplete needs input state, debouncing, async search, loading and empty states, keyboard navigation, selection, and stale-response protection. The data model should distinguish query text, highlighted option, selected value, and result list. Advanced follow-ups usually add caching, cancellation, accessibility roles, and latency recovery.
Pagination gives users stable pages, clearer URLs, and easier recovery, while infinite scroll favors continuous browsing and lower-friction discovery. Infinite scroll needs careful loading, virtualization, scroll restoration, footer access, and duplicate prevention. The right choice depends on task completion, SEO needs, accessibility, analytics, and data consistency.
React interviews often focus on state ownership, hooks, rendering, effects, and component boundaries. Angular interviews often emphasize RxJS, dependency injection, change detection, forms, testing, and architecture. Vue interviews often focus on reactivity, Composition API, component contracts, Router, Pinia or Vuex, and update timing.
Common mistakes include coding before clarifying requirements, ignoring accessibility, mutating shared state, skipping loading and error states, and explaining fixes without tests. Another common miss is optimizing too early before proving where the bottleneck is. A safer pattern is to state assumptions, build the core behavior, test edge cases, then discuss trade-offs.
Core shortlist
Debounce, throttle, array transforms, async flow, equality, references, and browser behavior that appear inside UI prompts.
Open Essential 60 →Autocomplete, tables, forms, widgets, stateful components, keyboard behavior, and accessible interaction details.
Start UI essentials →Event loop, closures, DOM events, storage, XSS, semantic HTML, cascade, responsive layout, and rendering behavior.
Review core concepts →Frontend architecture prompts around data flow, caching, pagination, performance, accessibility, and failure recovery.
Practice trade-offs →Practice paths
Timed widget and product-slice prompts where visible behavior, interaction details, and accessible states matter most.
Focused implementation and explanation prompts for async, closures, arrays, DOM behavior, and utility functions.
React, Angular, and Vue paths for state, rendering, lifecycle, reactivity, forms, testing, and architecture boundaries.
Root-cause scenarios for stale state, async races, rendering bugs, regressions, and production-style failure analysis.
Frontend architecture prompts for requirements, data, interfaces, optimizations, accessibility, and failure modes.
Short explanation checks for JavaScript, CSS, browser APIs, HTTP, accessibility, and framework fundamentals.
Critical for coding rounds and edge-case discussion.
Implement uniqueArray(arr) that removes duplicates while preserving order. Use a Set for O(n) time and clarify how to treat objects by reference, NaN, and mixed types so behavior is explicit and predictable. Concepts: a…
Open JavaScript coding interview challenge →Critical for coding rounds and edge-case discussion.
Create a shallow copy of an array or object. Copy top-level properties but keep nested references intact, and document that limitation clearly. This clarifies the difference between shallow and deep cloning and helps av…
Open JavaScript coding interview challenge →Critical for coding rounds and edge-case discussion.
Implement sleep(ms) that returns a Promise resolving after ms milliseconds. Use it to pause async flows like retries, exponential backoff, UI delays, or test helpers without blocking the event loop or freezing the UI th…
Open JavaScript coding interview challenge →Critical for coding rounds and edge-case discussion.
Implement a function `sortNumbers(arr, ascending = true)` that returns a **new array** of numbers sorted numerically in ascending or descending order. The original array must not be mutated, and you should use `Array.pr…
Open JavaScript coding interview challenge →Critical for coding rounds and edge-case discussion.
Return a new array with one index updated, leaving the original array untouched. This is the core immutable update pattern used in reducers, React state updates, and UI list editing, and it prevents accidental mutation.
Open JavaScript coding interview challenge →Critical for coding rounds and edge-case discussion.
Implement createDeferred() to build a controllable Promise: { promise, resolve, reject }. This is a common testing tool to make async flows deterministic (you decide exactly when something resolves/rejects).
Open JavaScript coding interview challenge →Need more implementation reps? Open the full coding list or follow a study plan.
Frequently tested in explanation-heavy rounds.
Callbacks are the original control-flow hook in JavaScript. Strong answers explain inversion of control, callback hell, legacy async debugging, and why callbacks still fit repeated-notification APIs like DOM events.
Open JavaScript interview question →Frequently tested in explanation-heavy rounds.
Arrow and regular functions look similar but behave differently for callbacks, methods, constructors, arguments, and class-field memory cost. Strong answers explain lexical vs dynamic this and when each style is safer i…
Open JavaScript interview question →Frequently tested in explanation-heavy rounds.
Debug the production bug where async requests resolve out of order and overwrite newer UI state. The fix is cancellation, request identity, shared-controller ownership, or takeLatest-style guards that stop stale results…
Open JavaScript interview question →Frequently tested in explanation-heavy rounds.
Security-focused frontend interview guide to DOM XSS: attacker-controlled sources like location.hash or postMessage, dangerous DOM sinks, safe rendering patterns, URL validation, and defense in depth with CSP and Truste…
Open JavaScript interview question →Frequently tested in explanation-heavy rounds.
Hoisting is JavaScript declaration processing before execution. The practical debug value is mapping symptoms: `undefined` reads, early callable function declarations, and ReferenceError or TypeError when the wrong cons…
Open JavaScript interview question →Frequently tested in explanation-heavy rounds.
Closures keep outer variables alive after the outer function returns. The real frontend debug value is explaining stale async callbacks, loop-capture bugs, and long-lived listeners that keep old objects alive in memory.
Open JavaScript interview question →Need more concept coverage? Open the full concepts list or browse company packs.
Interview prep context
Questions are curated from FrontendAtlas metadata, editorial review checks, and shipped practice routes rather than scraped generic lists.
Quick answers
Yes. The master hub starts with beginner-friendly frontend fundamentals, then points experienced developers toward architecture, debugging, performance, framework, and system-design practice.
Yes. The Essential 60 preview and coding sections route into UI coding and machine-coding style prompts such as forms, autocomplete, tables, widgets, stateful components, and interaction details.
Yes. The hub gives cross-topic answers first, then links into JavaScript, HTML, CSS, React, Angular, Vue, browser API, and HTML/CSS interview question paths for deeper practice.
Yes. The master answers and format cards cover async UI bugs, behavior tests, regressions, rendering cost, hydration, layout shifts, and performance trade-offs.
Yes. This page introduces frontend system design as part of the broad interview loop and links to the dedicated system-design practice area for deeper architecture prompts.
Start with the essential answers, use Essential 60 as a compact baseline, then pick one format: UI coding, JavaScript utilities, framework depth, debugging, concept quiz, or system design.
Start with one route first. Then expand into Question Library, Study Plans, and Company Prep only when you need them.
Recommended preparation
Start with the interview preparation guide, use Essential 60 as the core practice block, then broaden by format, stack, and final-round coverage.