Use this frontend UI interview questions practice map to prioritize common component prompts, model strong answers, score your solution with a rubric, and drill accessibility, keyboard support, and React/HTML/CSS execution under time pressure.
In frontend UI interviews, the fastest way to score well is to ship a small component that works, then harden it with keyboard support, accessible semantics, responsive styling, and edge-case tests.
Short answer for this page
Use this page as a frontend UI interview practice map for a frontend UI coding interview. It keeps broad machine coding strategy out of scope and focuses on component interview questions, accessibility checks, and direct drills. If your round is a React UI coding interview, the same state, keyboard, and a11y signals still decide the score.
These prompts show up because they reveal the same signals: state ownership, keyboard behavior, ARIA semantics, responsive layout, and whether you can test a component before time runs out.
Requirement: build an accessible modal that opens, confirms, cancels, closes, and restores focus.
Test focus: accessible name, Escape, outside click policy, focus trap modal behavior.
Requirement: build autocomplete with filtering, debounce, and mouse or keyboard selection.
Test focus: debounce, loading, empty results, stale response policy.
Requirement: solve an accessible form validation interview prompt with fields, submit, and feedback.
Test focus: labels, required fields, disabled submit, error recovery.
Requirement: build tabs that switch panels and preserve active state.
Test focus: roving tabindex, ARIA tabs linkage, Home/End keys.
Requirement: practice a Flexbox navbar coding challenge with brand, links, CTA, and mobile behavior.
Test focus: readable links, visible focus, flex-wrap, gap, and no hidden navigation.
Requirement: build a responsive CSS Grid card gallery with exact 2-to-4 column behavior.
Test focus: repeat(), minmax(), gap, long titles, extra cards, and no horizontal overflow.
Requirement: build an accordion with predictable expand and collapse state.
Test focus: single vs multi-open policy, button semantics, keyboard toggles.
Requirement: build table rows, page controls, and derived visible data.
Test focus: page bounds, derived rows, disabled controls, table semantics.
Requirement: render changing columns and rows from structured data.
Test focus: stable keys, missing values, header mapping, sort follow-up.
Requirement: sync parent and child checkbox states in a tree.
Test focus: indeterminate state, DFS updates, partial selection, reset.
Requirement: render reply trees with one active input at a time.
Test focus: recursion depth, active state, empty replies, stable IDs.
Requirement: build rating preview, select, reset, and announcements.
Test focus: hover vs committed state, keyboard input, accessible labels.
Requirement: add, remove, and suggest tags without duplicate chips.
Test focus: keyboard removal, duplicate prevention, suggestions, empty input.
Requirement: show bounded progress and threshold states clearly.
Test focus: 0/100 bounds, ARIA progressbar, colors, reduced motion.
A strong answer names the behavior contract before code, ships the baseline, and then hardens accessibility and edge cases.
The Confirm Dialog is a useful rehearsal prompt because it touches every scoring surface: markup, state, focus, keyboard behavior, and visual polish. Practice the direct drill here: Modal: Native dialog confirm.
isOpen, lastFocus, and the active confirm/cancel callbacks.role="dialog" or native <dialog> with an accessible name.aria-labelledby and aria-describedby.let isOpen = false;
let lastFocus = null;
function openDialog() {
lastFocus = document.activeElement;
isOpen = true;
dialog.hidden = false;
confirmButton.focus();
}
function closeDialog() {
isOpen = false;
dialog.hidden = true;
lastFocus?.focus();
}
document.addEventListener('keydown', (event) => {
if (isOpen && event.key === 'Escape') closeDialog();
});| Prompt | Junior answer | Senior answer |
|---|---|---|
| Modal | Toggle open state and close on button click. | Define close policy, accessible naming, focus restore, Escape behavior, and test keyboard paths. |
| Autocomplete | Filter options as the user types. | Separate input, highlight, selected value, async state, stale response handling, and keyboard selection. |
| Data Table | Render rows and pagination buttons. | Derive rows from source data, guard page bounds, handle empty states, and preserve stable keys. |
| Form | Show required-field errors. | Choose validation timing, tie errors to fields, support recovery, and account for server-side failures. |
| Tabs | Switch visible content when a tab is clicked. | Use button semantics, connect tabs to panels, support roving tabindex, Home/End keys, and visible focus. |
| Time | Move | Signal |
|---|---|---|
| 0-5 min | Clarify prompt, data shape, interactions, keyboard expectations, and edge cases. | You avoid hidden assumptions. |
| 5-15 min | Ship MVP markup and the smallest visible state path. | You can make progress quickly. |
| 15-30 min | Add state/interactions: open, close, select, reset, submit, or derived rows. | Your component behaves correctly. |
| 30-45 min | Harden keyboard/a11y, responsive styling, loading, empty, and error states. | You know frontend correctness is more than click demos. |
| 45-60 min | Dry run edge cases, explain trade-offs, and state what you would improve next. | You can verify and communicate under pressure. |
Use real buttons, labels, forms, headings, lists, tables, and landmarks before custom roles.
Know label association, validation timing, disabled-submit policy, and server-error recovery.
Track the active element, restore focus after overlays, and keep visible focus states intact.
Understand click and keyboard handlers, propagation, delegation, and when default behavior matters.
Use Flexbox, Grid, intrinsic sizing, overflow handling, and responsive constraints deliberately.
Model loading, empty, error, retry, stale responses, and disabled states as explicit UI states.
| Priority | Do this | Avoid spending time on |
|---|---|---|
| Prioritize | Correct state, keyboard, a11y, empty/error/loading states, and a dry run. | Pixel-perfect mock matching before behavior works. |
| Know lightly | Animations, transitions, theme polish, and microcopy if core behavior is done. | Complex animation systems or custom design systems. |
| Skip unless asked | Heavy abstractions, virtualized rendering, portals, and generic component libraries. | Reusable architecture that slows down the prompt. |
Common frontend UI interview questions include modal dialogs, autocomplete, tabs, accordion, data tables, nested checkboxes, forms, star rating, and nested comments.
Practice one component at a time under 45 to 60 minutes. Ship the MVP first, then add keyboard support, ARIA semantics, responsive styling, edge cases, and a short trade-off explanation.
Start with autocomplete, tabs, accordion, data table pagination, nested checkbox tree, nested comments, star rating, chips autocomplete, and progress bar drills.
Accessibility is core correctness. Interviewers expect labels, semantic controls, focus management, keyboard paths, visible focus, and clear disabled or error states.
A senior answer should state the behavior contract, ship an MVP, explain state ownership, harden keyboard and accessibility, cover failure states, and describe tests or trade-offs out loud.
It overlaps with frontend machine coding interviews, but this page narrows the scope to UI component execution. Broader machine coding rounds can also include data fetching, routing, app state, and larger product workflows.