Skip to content

Intuit Interview Experience 2026

Overview

Intuit’s loop mixes a Glider-based online assessment with standard technical rounds, then adds a live Craft Demo where SDE-2+ candidates extend a real codebase instead of solving a fresh whiteboard problem.

Round-wise process

Round Duration What it tests
Recruiter screen 30-40 min Background, motivation, location/comp, logistics
Online Assessment 60-90 min 2-4 DSA problems on the Glider platform
Technical interview(s) 30-60 min each Coding, OOPs/DBMS/OS fundamentals, project deep-dive
Craft Demo (SDE-2+ / senior) ~90 min Live coding on a shared codebase - tests, error handling, communication
System design (SDE-2+) 45-60 min Scalable design and trade-offs (storage, notifications, etc.)
Hiring manager / HR 20-30 min Values fit, Design for Delight thinking, closing logistics

Real interview experiences

Experience 1: SDE-2, backend (2025)

Profile: B.Tech CSE, ~4 years experience, applied off-campus after a referral, comfortable with mid-level DSA

Recruiter screen

  • 30-minute call: current role, why Intuit, comp band, and notice period. No coding.

Online Assessment

  • Glider platform, 75 minutes, 3 problems: a matrix traversal, an O(1) insert/delete/getRandom data-structure design question, and a string-decoding problem.
  • Fully-passing solutions on the two easier problems mattered more than a half-finished attempt at the hardest one.

Technical rounds

  • Round 1: delete a node from a binary tree and return the remaining forest as an array - DFS with a visited set.
  • Round 2: OOPs (runtime vs compile-time polymorphism with a real example) and DBMS (ACID properties, when to add an index).
  • Project deep-dive: architecture choices, the hardest production bug, and what they’d rebuild.

Craft Demo

  • Emailed a small GitHub repo 48 hours ahead: a partially built expense-tracking service.
  • In the session, implemented one new user story (a filter endpoint) live in front of three interviewers, then added unit tests and handled a null-input edge case they raised on the spot.
  • Follow-up: “How would you check that this feature actually solves the user’s problem?” - answered with a Design for Delight framing (small experiment before full rollout).

Hiring manager / HR

  • A time they advocated for the customer even when it meant pushing back internally.
  • Notice period and relocation flexibility.

Result: Selected What helped: Narrating trade-offs out loud during the Craft Demo instead of coding in silence, and tying the follow-up answer explicitly to Design for Delight.

Takeaways

  • What decided it: Live Craft Demo with narrated trade-offs, tests/null handling, and an explicit Design for Delight answer on user validation
  • Common fail: Coding the filter endpoint silently, or generic customer answers without Delight framing
  • How to practise: Extend a small GitHub service under 90 min with tests; rehearse one Delight experiment story

Experience 2: SDE-1, new grad (2024-2025)

Profile: B.Tech IT, Bengaluru-based early-career program, one internship, average contest rating

What differed

  • No Craft Demo at this level - the loop was recruiter screen, Online Assessment, two technical rounds, and HR.
  • Online Assessment felt tighter on time; one matrix problem needed an optimised BFS pass to finish inside the limit.
  • Second technical round leaned harder into operating-systems basics (process vs thread, deadlock conditions) than DSA.

Mistakes that hurt other candidates in the same cycle

  • Jumping into code before clarifying the OA’s edge cases (empty grid, duplicate values)
  • Treating the HR round as a formality rather than a real evaluation of values fit
  • Answering “why Intuit” with a generic tax-software line instead of anything about Design for Delight or the operating values

Result: Selected after HR Takeaway: At Intuit, a clean OA plus a values-specific HR story usually beat strong DSA with a generic “why us” answer.

Takeaways

  • What decided it: Clean Glider OA plus OS fundamentals and a values-specific Why Intuit / Design for Delight HR story
  • Common fail: Strong DSA with generic tax-software motivation, or skipping edge cases on matrix OA
  • How to practise: Timed Glider-style matrices; process vs thread flashcards; draft a Delight-specific Why Intuit

Experience 3: SDE-2, Bengaluru (Dec 2024)

Profile: ~4+ YOE, recruiter outreach on LinkedIn, strong OA score (~94% reported)

Online Assessment

  • Two medium DSA problems (linked list + arrays) plus five MCQs on core CS topics; two-day completion window.

Phone / onsite Craft loop

  • Craft Demo on a shared Java/Spring repo: new POST API to persist player details - discuss payload, logging, errors; demo in Postman.
  • Follow-up task: wrap an external LLM URI - prompt in, model JSON out - with basic error handling.
  • Later round: DSA similar to next permutation; fundamentals on engineering best practices, then pagination on the GET API built earlier.

Result: Rejected - feedback emphasized wrong HTTP status codes and weak exception handling on APIs, not algorithm failure.

Takeaway: Intuit’s Craft loop treats API robustness as binary signal; practise @ControllerAdvice, validation errors, and idempotent retries before the onsite.

Experience 4: SDE-2, multi-day Craft onsite (2024)

Profile: Lateral with competing offer; four back-to-back craft interviews after eliminator OA

Craft Demo (90 min)

  • Slide intro, then add API + service layer + unit tests on Java/H2 REST project; 15 minutes of system-design grilling on high load and large datasets before coding allowed - candidate discussed pagination upfront.
  • DSA eliminator included grid path counting and edit distance DP.

Result: Offer received (declined for remote preference) - recruiter noted strong craft round when tests and Postman demo were crisp.

Takeaway: Requirements discussion and scalability talk are part of the score; silent coding after a vague prompt is risky.

Experience 5: SDE-2 via referral (BookMyShow-style design)

Profile: Referral, phone screen then two-week craft project prep

Phone screen (60 min)

  • HLD of current team work on whiteboard; API design for ticketing-style flows; LRU Cache with complexity follow-ups.

Craft round (60 min, four-person panel)

  • Presented assumptions, FR/NFR, stack, HLD/LLD, Postman collection, schema; Q&A on edge cases and caching.

Team member rounds

  • Design patterns, caching mechanisms, behavioral on leaving current employer and production debugging approach.

Result: Rejected after team rounds - craft presentation strong but behavioral/team fit did not clear.

Takeaway: Intuit referral loops still demand concise HLD narration and production-debug stories, not only the craft repo.

Questions that come up often

Coding / technical

  1. Matrix traversal - find a path or target in a grid of 0s and 1s
  2. O(1) insert, delete, and getRandom data-structure design
  3. Delete a node from a tree/graph and return the remaining forest as an array
  4. Decode string / unique email addresses style string-parsing problems
  5. OOPs: polymorphism, inheritance, with a real example from a project
  6. DBMS: ACID properties, indexing, normalization
  7. Operating systems: deadlocks, process vs thread
  8. Craft Demo: implement a user story in a shared repo, add tests, handle edge cases live

System design (SDE-2+)

  1. Design a photo/file storage service - upload, download, sharing at scale
  2. Design a notification or alerting service
  3. Design a roles-and-permissions system for a multi-tenant product
  4. Estimate load and storage for the system you just designed

Behavioural

  1. Tell me about a time you validated an idea with real users before building it (Design for Delight)
  2. Describe a time you considered multiple approaches before picking one
  3. Tell me about a time you did the right thing even when it was inconvenient
  4. Why Intuit, specifically, over other fintech/SaaS companies?

Practical tips for Intuit

  • Treat the Craft Demo like a real code review, not a LeetCode round: read the existing style before you write a line, and narrate why you’re structuring the change the way you are.
  • Have one Design for Delight story ready - a time you tested an idea cheaply with real users before committing to build it.
  • OOPs and DBMS fundamentals still open a lot of Intuit panels. Do not skip the basics assuming they only ask hard DSA.
  • For system design, a scoped, concrete answer (photo storage, notifications) beats an open-ended “design a big platform” pitch.
  • If you do not know something, say so and outline how you would find out - Intuit’s Craft Demo rewards that more than a confident guess.

HR interview

After technical rounds, Intuit closes with a hiring-manager/HR conversation that checks fit against its five operating values - Integrity without Compromise, Courage, Customer Obsession, Stronger Together, and We Care and Give Back - alongside location, compensation, and notice period. Prepare those answers on the dedicated page rather than cramming them into this hub.

Sample answers for high-frequency questions

Use these as frames, not scripts - interviewers probe follow-ups.

Q. Design a data structure supporting insert, delete, and getRandom in O(1).
A. Combine a dynamic array with a hash map from value to that value’s index in the array. Insert appends to the array and records the index in the map. getRandom picks a uniformly random index into the array, which is O(1) precisely because the array is dense with no holes. The trick is delete: instead of removing from the middle and shifting, look up the index of the target, swap in the last element of the array, update that moved element’s index in the map, then pop the last slot and erase the target from the map. All three operations are O(1) average and the structure uses O(n) space. The follow-up variant that allows duplicates replaces the map value with a set of indices per value.

Q. Given a binary tree and a list of values to delete, return the remaining forest.
A. Do a post-order traversal so children are processed before their parent, carrying the deletion values in a hash set for O(1) membership checks. At each node, recurse left and right first, then check whether the node itself is to be deleted: if it is, add its surviving children to the result list as new roots and return null to its parent so the parent unlinks it; if it is not, return the node unchanged. After the traversal, add the original root to the result only if it was not itself deleted. This is O(n) time and O(h) space for the recursion stack. Post-order matters because you must know whether a child survived before you can decide whether it becomes a new root.

Q. Implement decode string - for example, 3[a2[c]] returns accaccacc.
A. Use two stacks, one for repeat counts and one for partial strings, walking the input once. On a digit, accumulate the full multi-digit number. On an opening bracket, push the current count and the current partial string, then reset both. On a closing bracket, pop the count and the previous string, and set the current string to the previous string plus the current string repeated count times. On a letter, append it to the current string. This runs in O(total output length) time and O(depth) stack space. The two details interviewers probe are multi-digit numbers such as 12[ab], and nested brackets, both of which the two-stack approach handles naturally.

Q. What is the difference between compile-time and runtime polymorphism?
A. Compile-time polymorphism, also called static binding, is method overloading and operator overloading: several methods share a name but differ in their parameter lists, and the compiler picks one from the declared argument types. Runtime polymorphism, or dynamic binding, is method overriding: a subclass redefines a parent method with the same signature, and the decision of which implementation runs is deferred to run time based on the object’s actual type, dispatched through a vtable in C++ or by the JVM in Java. The practical consequence Intuit interviewers look for is extensibility - runtime polymorphism lets you add a new subclass without touching the calling code, whereas overloading is only a convenience for the caller. Note that in Java, static, private, and final methods are bound at compile time and therefore cannot be overridden.

Q. Explain normalization, and when would you deliberately denormalize?
A. Normalization decomposes tables so each fact is stored exactly once: 1NF requires atomic columns, 2NF removes partial dependencies on part of a composite key, and 3NF removes transitive dependencies between non-key columns. The payoff is that an update touches one row, so update, insert, and delete anomalies disappear. You denormalize when read performance under a known access pattern matters more than write simplicity - for example, storing a precomputed comment_count on a post rather than running a COUNT join on every page load, or duplicating a product name into an order-line row so historical orders do not change when the catalogue does. The cost is that you now own the consistency: every write path must update both copies, usually via a transaction, a trigger, or an asynchronous job that you must then monitor for drift.

Tips from successful candidates

Assessment tips

  • Confirm the current Intuit pattern from the drive mail before practising old papers
  • Finish one problem or section fully before starting the next
  • Revise the fundamentals listed in the round table on this page

Interview tips

  • Narrate trade-offs; expect “why” after every answer
  • Only list projects you can defend under follow-ups
  • Prepare 3-4 STAR stories for behavioural prompts

HR tips

  • Know why Intuit, not just why the industry
  • Be clear on location / notice period / higher studies
  • Practise answers on the dedicated HR page

Sources

These links are research inputs used to map Intuit Glider OA and Craft Demo loops - not copied page mirrors. We reorganized reports into process tables, outcome notes, and prep takeaways.

Confirm SDE-1 vs SDE-2 Craft expectations against the recruiter screen.

Similar companies

Adobe · Salesforce · Oracle · SAP · Microsoft · Google