Recommended preparation

Editorial practice groupings, not verified official interview questions or endorsements.

Public Intuit prep guide

Intuit Frontend Interview Questions

Prepare with five practice prompts shaped by public frontend accounts from 2021 to 2025: a craft demo app built from a brief and extended live, a typeahead implemented inside a codebase received the day before, a promise retry with a Promise.race polyfill, an LLM user story with streaming output, and JavaScript fundamentals under questioning.

This guide uses public, self-reported interview accounts to create realistic constraints. It does not claim access to private interview material, a fixed interview format, or the stack of every Intuit team.

5 practice promptsReact, JavaScript, AI user storiesFull practice set requires Premium

Study priorities

Prepare for product judgment, not Intuit trivia

Every public frontend account describes the same centre of gravity: a hands-on craft round where you build or extend a small application and defend it, surrounded by JavaScript fundamentals, a medium algorithm screen and, since 2024, an AI component. Candidates report that the panel asks why at every line, expects an error fallback and expects tests that check real conditions rather than coverage. Each prompt below starts with the clarifying questions a strong candidate asks, then the behaviours a strong answer covers, then the miss that usually ends the round.

Two lessons repeat across years. A 2022 account says level 2 and above are expected to have unit testing experience, and a 2023 account lost the loop partly on tests that proved nothing. A 2025 account stalled on a streaming user story by building the transport by hand instead of using the primitive the interviewer expected. Practise tests and streaming until they are routine.

Role lenses

Two product contexts for practising transferable frontend judgment

These are preparation lenses derived from the public prompts and the kinds of screens a financial software product runs, not claimed team assignments. Choose the lens closest to the role and keep the reasoning framework-neutral.

Data-entry product screens

Forms, lists and detail pages that load from an API, must fail gracefully and must be covered by tests before they ship.

Practice focus: Loading, empty and error states; an error fallback page; tests that assert behaviour rather than coverage; accessible controls.

AI-assisted features

Features that call a language model, stream the result into the page and must handle slow, partial or malformed output.

Practice focus: Server-Sent Events and fetch streams, cancellation, retry with delay, validating model output, and tests for each output case.

Representative practice prompts

Five Intuit frontend interview practice questions

For each prompt, clarify the contract, explain ownership and trade-offs, implement or diagram the smallest credible slice, and test the failure cases. Each prompt links to the public report it is modelled on and to a practice page.

Prompt 1

Build a small app from a brief, then extend it live in the craft demo

You receive a short brief, sometimes the day before and sometimes on the spot: fetch a list from an API, show selected fields, handle failures, add tests. In the session, walk the panel through the code, then add the features they ask for while they question every decision.

Practice version modelled on a reported round: Public report: Intuit SDE2 frontend loop, Bangalore, October 2021

What this measures

Component boundaries and state from a brief, honest loading and error states, tests that check conditions, and the ability to extend code under questioning.

Clarify first

  • Confirm whether the brief arrives in advance, which stack is allowed, and whether the panel wants a presentation before the code.
  • Confirm the one or two features most likely to be requested live, such as sorting the response or adding a detail view.

Strong answer should cover

  • Separate data fetching from rendering so a new field or a new sort is a small change in one place.
  • Show the three states on screen: loading, empty and a visible error fallback, and explain what each does for the user.
  • Write a few tests that assert behaviour, such as the error fallback appearing when the request fails, rather than tests that only raise coverage.
  • Narrate the why behind each choice, and name the next refactor instead of making it under time pressure.

Common miss: Presenting a polished demo with tests that assert nothing, so the first "what is the use of this test" question has no answer.

Work through component and state design from a mock (Premium)

Prompt 2

Implement a typeahead in a codebase you received yesterday, then test it

Inside a repository you set up the day before, implement a typeahead component that queries as the user types, shows suggestions, handles no results and lets the user pick one, then cover it with unit tests.

Practice version modelled on a reported round: Public report: Intuit senior frontend engineer loop, November 2025

What this measures

Reading an unfamiliar codebase quickly, debouncing and cancelling stale requests, keyboard and focus handling, and component tests with Jest and a testing library.

Clarify first

  • Confirm where suggestions come from, how many to show, and whether selection must be keyboard-accessible.
  • Confirm which test runner and utilities the codebase already has before writing the first test.

Strong answer should cover

  • Follow the existing patterns in the repository for data access and state rather than importing a new approach.
  • Debounce input, ignore responses that arrive out of order, and show empty and error states.
  • Expose the list with proper roles and arrow-key navigation, and close it on selection and on outside click.
  • Write tests for typing, suggestion rendering, selection and the empty state before polishing styles.

Common miss: Finishing the component quickly and then running out of time on tests because the testing utilities were never practised.

Practice the autocomplete search starter

Prompt 3

Implement a promise retry with delay, then a Promise.race polyfill

Write a function that takes a promise-returning function, retries it a given number of times with a delay between attempts and rejects with the last error. Then explain Promise.race versus Promise.any and implement race without the built-in.

Practice version modelled on a reported round: Public report: Intuit senior frontend engineer loop, November 2025

What this measures

Promise mechanics, timers inside promise chains, settling exactly once, and the difference between first-settled and first-fulfilled semantics.

Clarify first

  • Confirm whether the delay is fixed or grows, and whether a retry should stop on specific errors.
  • Confirm the expected behaviour for an empty iterable and for non-promise values in the race polyfill.

Strong answer should cover

  • Resolve on the first success and reject only after the last attempt, passing the final error through.
  • Use a single outer promise and a recursive attempt function so each retry waits for the delay.
  • Explain that race settles with the first settled promise while any resolves with the first fulfilled one and rejects only when all reject.
  • In the polyfill, wrap each value with Promise.resolve and rely on the fact that a promise settles once.

Common miss: Calling resolve and reject on the same attempt path, or forgetting that race never resolves for an empty iterable.

Practice the Promise.any sibling drill

Prompt 4

Deliver an LLM user story with streaming output, error handling and tests

As a user, I want to generate a text description for my project and see it on the details page. Use the provided model endpoint, stream the output into the page, handle errors and unexpected output, and add unit tests for the different output cases.

Practice version modelled on a reported round: Public report: Intuit senior frontend engineer loop, November 2025

What this measures

Choosing a streaming primitive the codebase supports, rendering partial output, cancelling and retrying, validating model output before showing it, and testing each branch.

Clarify first

  • Confirm the endpoint contract: Server-Sent Events, a fetch stream or a single response, and what an error looks like on the wire.
  • Confirm what the page should show for empty, truncated or malformed output.

Strong answer should cover

  • Use the streaming primitive the codebase or interviewer expects, such as EventSource for Server-Sent Events, instead of hand-rolling a parser.
  • Append chunks to visible text as they arrive, keep a cancel control, and show a clear state when the stream ends early.
  • Validate and sanitise the final output before rendering it, and fall back to a message the user can act on.
  • Write tests for a normal stream, an error mid-stream and malformed output, mocking the transport.

Common miss: Building the transport by hand, running out of time, and never reaching the error handling or the tests the story asked for.

Practice the chat UI with a streaming response (Premium)

Prompt 5

Answer JavaScript fundamentals under questioning: currying, memoization, output prediction, DOM comparison

In a conversational round, write a currying function and a memoization function, predict the output of hoisting and promise snippets, explain closures and their uses, and implement a function that decides whether two DOM trees are identical.

Practice version modelled on a reported round: Public report: Intuit SE2 frontend loop, October 2023

What this measures

Scope and the temporal dead zone, microtask ordering, closures as a design tool, pure recursion over trees, and the ability to explain while coding.

Clarify first

  • Confirm whether currying must support any arity and whether memoization should key on all arguments.
  • Confirm whether the DOM comparison must include attributes and text nodes or only tags.

Strong answer should cover

  • Walk through hoisting by separating declaration from initialisation, and through promise snippets by separating synchronous executor code from then callbacks.
  • Implement currying by collecting arguments until the original length is met, and memoization with a cache keyed on serialised arguments.
  • Compare DOM trees recursively: node type, tag, attributes, text content, then children in order.
  • Name the trade-off in each answer, such as memory growth in the memoization cache.

Common miss: Predicting output by intuition instead of ordering the synchronous code, the microtasks and the timers explicitly.

Practice the curry function (Premium)

Public mini walkthrough

Scope the craft demo app before the panel joins

Treat this as a representative exercise, not a description of the reported one. Work from the brief toward the three states and the tests, and say each decision out loud.

  1. Pin the brief

    Which fields to show, which API to call, what counts as done, and which stack the panel expects.

  2. Separate fetch from render

    One data module with a typed result, one component that renders loading, empty, error and data.

  3. Make failure visible

    An error fallback with a retry, not a blank screen, and a log line that would help in production.

  4. Write the tests that matter

    The fallback appears on failure, the list renders the fields, a sort changes the order; nothing that only raises coverage.

Actionable preparation

A 7-day Intuit frontend interview preparation plan

Every day ends with code, a test, a design artifact, or a question you can use in the real process.

  1. Day 1

    Algorithm screen: balanced brackets with extra characters, connected components, 3Sum and kSum, with stated complexity.

    Deliverable: Four solved problems with tests.

  2. Day 2

    JavaScript fundamentals: hoisting and promise output prediction, closures, currying, memoization.

    Deliverable: Six predicted snippets and two implemented helpers.

  3. Day 3

    Craft demo: build a fetch-and-display app with loading, empty and error states and three behavioural tests.

    Deliverable: A small app you can extend on request.

  4. Day 4

    Unfamiliar codebase: clone an open-source app, add a typeahead following its patterns, write component tests.

    Deliverable: A pull request against the sample app.

  5. Day 5

    Promises and DOM: retry with delay, Promise.race and any, identical DOM tree comparison.

    Deliverable: Three drills with edge-case tests.

  6. Day 6

    AI user story: stream a model response with Server-Sent Events, handle errors and malformed output, test each branch.

    Deliverable: A streaming component with mocked transport tests.

  7. Day 7

    Mock loop: craft demo, technical round, AI discussion, hiring manager, each narrated, plus web security, web vitals and accessibility questions.

    Deliverable: A list of the questions you will ask the recruiter about format, stack and tools.

Preparation FAQ

Common Intuit frontend interview preparation questions

Are these the real Intuit questions?

No. They are FrontendAtlas practice versions modelled on round types described in public, self-reported accounts. The wording, the data and the test cases are ours.

How much of a frontend loop is about AI?

Accounts from 2024 and 2025 describe a 30-minute AI assessor round, an AI tooling question in the phone screen and one AI-focused user story in the coding round. Expect to explain retrieval-augmented generation, prompts and model output handling, and to code against a model endpoint.

Do I really need unit tests in the craft demo?

A 2022 account says level 2 and above are expected to have unit testing experience, and a 2023 account was challenged on tests that checked nothing. Write a few tests that assert behaviour.

Does the craft prompt arrive in advance?

Both happen in the accounts: a design document the day before in 2021 and 2025, a week-long task in 2023, and an on-the-spot prompt in 2022. Ask the recruiter which applies to your loop.

Free public practice

Build the underlying skills with free practice

These public pages cover the promise, streaming, typeahead and fundamentals skills used by the practice prompts. They are supporting drills, not claimed Intuit questions.

Promise.any (first fulfilled)The sibling of the Promise.race polyfill.Stream to textRead a ReadableStream into a string, the base of streaming output.Sleep or delay promiseThe delay primitive inside a retry.React autocomplete search starterA typeahead with debouncing and stale-response handling.Hoisting and the temporal dead zoneWhy var logs undefined while let throws.DOM XSS preventionDangerous sinks and safe APIs for the web security questions.useMemo vs useCallbackWhen memoising makes a component slower.

Public interview reports and official context

Sources and evidence limits

These links support the public context used by the guide. Their notes state what each source can and cannot establish about preparation.

Public report: Intuit senior frontend engineer loop, November 2025

One self-reported senior frontend loop that ended in a lower-level offer. It lists the technical phone interview topics, the two-of-eight user stories in a provided codebase, the promise retry and race polyfill, the DOM tree comparison and the LLM user story; it cannot establish exact wording or the current format.

Intuit careers

Official roles and offices for product context only, not evidence of interview content or format.

Full company practice

Continue with the full Intuit practice set

This public guide is complete enough to plan a focused week. Premium unlocks the streaming chat UI, the curry and memoization drills, the twin DOM tree exercise, the component-and-state design case and the broader company-tagged editorial set.

Unlock the full Intuit practice set