Representative practice prompts
Seven Google frontend interview practice questions
Use each prompt to practice clarifying the contract, explaining trade-offs, implementing a focused slice, and testing failure paths. The details below are public evaluation guidance, not paid solutions.
Prompt 1
Traverse and transform a nested navigation tree
Given nested navigation data, find or transform matching nodes while preserving the required order and returning a predictable result for missing paths.
What this measures
Tree traversal, complexity analysis, JavaScript data modeling, and care around mutation and unusually deep input.
Clarify first
- Ask whether the tree can be empty, malformed, extremely deep, or cyclic, and whether order must be preserved.
- Confirm whether the transformation should mutate the input or return new objects along changed paths.
Strong answer should cover
- Choose depth-first or breadth-first traversal deliberately and explain the trade-off.
- State O(n) time and account for recursion depth or an explicit stack.
- Preserve stable ordering and define the missing-node result.
- Test empty, single-node, deeply nested, duplicate-id, and malformed inputs.
Common miss: Assuming a fixed nesting depth or mutating shared input without making that contract explicit.
Practice safe nested-path traversal in JavaScript Prompt 2
Implement debounce with cancel and flush
Implement a debounce utility that preserves arguments and context, and add cancel and flush behavior with a clear return-value contract.
What this measures
Closures, timers, function context, API design, cleanup, and deterministic testing of asynchronous utilities.
Clarify first
- Confirm leading versus trailing invocation, the return value, and what flush returns when nothing is pending.
- Ask how cancel affects retained arguments, context, and any previously returned result.
Strong answer should cover
- Keep one timer and replace it on each qualifying call.
- Preserve the latest arguments and this context without retaining them after completion.
- Make cancel and flush idempotent and define leading/trailing interaction.
- Use fake timers to test rapid calls, cancellation, flushing, and cleanup.
Common miss: Creating a double invocation around flush or leaving timers and captured values alive after cancel.
Practice implementing debounce Prompt 3
Build an accessible autocomplete
Build a typeahead that requests suggestions, exposes clear loading and empty states, and remains fully operable by keyboard and assistive technology.
What this measures
Accessible UI implementation, browser events, async state, focus management, and clear component boundaries.
Clarify first
- Confirm the data source, minimum query length, result limit, selection behavior, and expected browser support.
- Ask whether focus stays in the input and how free-form values, no results, and request failures should behave.
Strong answer should cover
- Use the combobox/listbox pattern with correct expanded, controls, and active-descendant relationships.
- Support Arrow keys, Enter, Escape, pointer input, and visible focus without trapping the user.
- Model loading, empty, error, cancelled, and stale outcomes explicitly.
- Debounce requests and protect the UI from out-of-order responses.
- Test keyboard flow and accessible names as well as successful selection.
Common miss: Building a mouse-only suggestion list or announcing every network update through an overly noisy live region.
Try an optional React autocomplete implementation drill Prompt 4
Keep only the latest async result
Coordinate overlapping requests so only the newest result can update the view, even when older work resolves or rejects later.
What this measures
Race-condition reasoning, cancellation, ownership of UI state, and tests that control promise ordering.
Clarify first
- Ask whether the underlying work can be aborted or only ignored after it settles.
- Define which request owns loading, error, and cleanup state when calls overlap.
Strong answer should cover
- Cancel active work with AbortController where the API supports it.
- Pair cancellation with a monotonically increasing request token or takeLatest guard.
- Guard success, error, and finally writes so stale work cannot clear current state.
- Keep cancellation, stale results, and genuine failures distinguishable.
- Force out-of-order resolution and rejection in tests.
Common miss: Guarding the success path while a late catch or finally block still overwrites the newest request state.
Practice takeLatest request handling Prompt 5
Handle delegated events in a dynamic list
Handle interactions for a changing list through a stable ancestor, while identifying the intended item safely and updating only what changed.
What this measures
DOM event propagation, delegation, target boundaries, dynamic content, efficient updates, and listener cleanup.
Clarify first
- Confirm which child interactions count, whether controls can be nested, and where the delegation boundary ends.
- Ask how items are inserted or removed and whether keyboard activation must share the same action path.
Strong answer should cover
- Explain capture and bubble phases plus the difference between target and currentTarget.
- Use closest with a containment check so nested elements and outside matches are safe.
- Key updates by stable item identity and avoid rebuilding the whole list.
- Cover keyboard behavior, removed nodes, and listener cleanup.
Common miss: Reading target.dataset directly, which breaks when the click lands on a nested icon or label.
Review DOM event delegation Prompt 6
Reason about frontend performance, networking, and security
Diagnose a slow data-heavy page and propose measured improvements across delivery, rendering, request behavior, and client-side security.
What this measures
Evidence-led performance work, network trade-offs, rendering strategy, safe data handling, and prioritization under constraints.
Clarify first
- Ask for target devices, network conditions, user journeys, performance goals, and the trusted-data boundary.
- Separate initial load, interaction latency, rendering cost, and backend response time before proposing fixes.
Strong answer should cover
- Start with field or lab measurements and identify the dominant bottleneck.
- Discuss caching, compression, code splitting, request deduplication, and pagination where evidence supports them.
- Use batching or virtualization when rendering volume is the constraint.
- Include safe DOM APIs, output handling, and an appropriate Content Security Policy in the threat model.
- Set a budget or metric and explain how the change will be verified.
Common miss: Listing optimizations without measurement, or improving speed while ignoring unsafe rendering and data exposure.
Review web load-time optimization trade-offs Prompt 7
Design search suggestions for a large interactive list
Design the frontend for ranked search suggestions and a large result list that stays responsive, accessible, and correct as data changes.
What this measures
Frontend system design, API and state boundaries, caching, rendering scale, accessibility, resilience, and observability.
Clarify first
- Confirm data size, server versus client search, ranking and freshness needs, target latency, and offline expectations.
- Ask which devices, assistive technologies, and failure modes the design must support.
Strong answer should cover
- Define component, state, and API boundaries, including cursor or pagination contracts.
- Combine debounce, cancellation, takeLatest guards, caching, and explicit error states.
- Use windowing or incremental rendering without breaking focus or result semantics.
- Plan keyboard interaction, announcements, observability, and recovery from partial failures.
- Explain how trade-offs change for junior, mid-level, and senior design scope.
Common miss: Drawing component boxes without defining state ownership, stale-data behavior, accessibility, or failure recovery.
Practice designing an infinite-scrolling list