Interview experience
Intuit Interview Questions and Answers (2026)
Overview
Section titled “Overview”Intuit’s engineering interviews pair standard DSA rounds with a live Craft Demo on real code, evaluated through its Design for Delight framework.
Intuit interview process at a glance
Section titled “Intuit interview process at a glance”| 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 |
Recruiter screen
Section titled “Recruiter screen”A 30-40 minute call to confirm background, work authorization, location, and current comp/notice period. It’s a logistics filter more than a technical bar - be direct about timeline and expectations.
Common questions
- Walk me through your resume/current role
- Why are you interested in Intuit right now?
- What are your compensation and location preferences?
- What’s your notice period / earliest start date?
Full behavioral frameworks are on the Intuit HR interview questions page.
Online Assessment
Section titled “Online Assessment”A 60-90 minute timed test, usually on the Glider platform: typically 2-4 coding problems spanning easy to hard difficulty. Candidates report that clean, fully-passing solutions on the easier problems weigh more than a partial attempt at the hardest one.
Common questions
- Matrix traversal: find a path/target in a grid of 0s and 1s
- Data structure design: O(1) insert, delete, and getRandom
- Tree/graph problems: e.g. delete a node and return the remaining forest as an array
- String/array problems in the “decode string” or “unique email addresses” family
See how real candidates handled this stage on the Intuit interview experience page.
Technical interviews
Section titled “Technical interviews”One or two rounds of 30-60 minutes each, usually with one or two interviewers. Expect a mix of live coding, core CS fundamentals, and a genuine deep-dive into a project from your resume - not just a listed-skills recap.
Common questions
- OOPs: polymorphism (compile-time vs runtime), inheritance, and where you’ve used them
- DBMS: ACID properties, indexing, normalization
- Operating systems: deadlocks, process vs thread
- Resume project deep-dive: architecture choices, the hardest bug, what you’d rebuild
Round-by-round breakdowns are on the Intuit interview experience page.
Craft Demo: Intuit’s distinctive round
Section titled “Craft Demo: Intuit’s distinctive round”This is the round most candidate reports single out as unusual to Intuit. Roughly 24-48 hours before the interview, you’re emailed access to a small GitHub repository with a partially-built application. In the ~90-minute session itself, 2-4 interviewers watch you implement one or two new user stories live inside that existing codebase - not a fresh whiteboard problem. The bar isn’t just “does it run”: interviewers are explicitly watching for test coverage, error handling, and whether you narrate your reasoning as you extend someone else’s code, since that’s closer to day-one engineering work than a LeetCode round.
Common questions
- Implement a new feature/user story inside the provided repo, matching existing code style
- Add unit tests and handle edge cases for the feature you just wrote
- Explain why you structured the change the way you did, and what you’d refactor with more time
- Follow-up questions tied to Design for Delight: how would you validate this feature actually solves the user’s problem?
Design for Delight and Intuit’s operating values
Section titled “Design for Delight and Intuit’s operating values”Intuit’s own innovation methodology - Design for Delight (D4D) - shows up as an evaluation lens in the Craft Demo and behavioral rounds, not just as company trivia. Its three principles are Deep Customer Empathy (understand the real problem before proposing a fix), Go Broad to Go Narrow (consider more than one option before committing), and Rapid Experimentation (test cheaply before building the whole thing). Layered on top are Intuit’s five operating values: Integrity without Compromise, Courage, Customer Obsession, Stronger Together, and We Care and Give Back. Interviewers use both as a shared vocabulary, so naming which principle or value a story maps to - briefly, not as a buzzword drop - tends to land better than a generic answer.
Common questions
- Tell me about a time you validated an idea with real users before building it (Deep Customer Empathy / Rapid Experimentation)
- Describe a time you considered multiple approaches before picking one (Go Broad to Go Narrow)
- Tell me about a time you did the right thing even when it was inconvenient (Integrity without Compromise)
- Why Intuit, specifically, over other fintech/SaaS companies?
System design (SDE-2 and above)
Section titled “System design (SDE-2 and above)”A 45-60 minute round for more senior candidates, focused on a concrete, scoped system rather than an open-ended “design Google” prompt. Interviewers probe estimation, trade-offs, and failure modes as much as the final diagram.
Common questions
- Design a photo/file storage service - upload, download, sharing at scale
- Design a notification or alerting service
- Design a roles-and-permissions system for a multi-tenant product
- How would you estimate load and storage for the system you just designed?
Hiring manager / HR round
Section titled “Hiring manager / HR round”The closing conversation checks fit against Intuit’s values and logistics: location, compensation band, and a couple of behavioral stories. Prepare those answers on the dedicated page rather than cramming them into this hub.
Common questions
- Tell me about a time you advocated for the customer even when it meant pushing back internally
- Describe a decision you made by relying on data rather than intuition - what was the outcome?
- Are you willing to relocate / what’s your notice period?
- Do you have any questions for us?
Sample answer frameworks for each of these are on the Intuit HR interview questions page.
Common technical interview questions and answers
Section titled “Common technical interview questions and answers”Q: Design a data structure supporting insert, delete, and getRandom in O(1).
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.
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.
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?
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?
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.
Q: What is the difference between a mutex and a semaphore?
A mutex is a locking mechanism with ownership: exactly one thread holds it at a time, and only the thread that locked it may unlock it, which makes it the right tool for guarding a critical section. A semaphore is a signalling mechanism holding a counter: threads call wait to decrement (blocking at zero) and signal to increment, and any thread may signal, including one that never waited. A binary semaphore looks superficially like a mutex but lacks ownership, so it cannot support priority inheritance and is easier to misuse. Use a counting semaphore when you are limiting access to N interchangeable resources, such as a pool of ten database connections, and a mutex when you are protecting one shared piece of state.
Q: How would you design a notification service?
Start with an ingestion API that accepts a notification request and immediately writes it to a durable queue such as Kafka, so the caller is not blocked by delivery latency. Workers consume from that queue, look up the user’s channel preferences and quiet hours, apply rate limiting and deduplication (a hash of user, template, and time bucket held in Redis), and then fan out to channel-specific senders for push, email, and SMS. Each sender needs retries with exponential backoff and a dead-letter queue for permanent failures, since third-party providers fail transiently. Make delivery idempotent using a notification ID, because at-least-once queue semantics guarantee some messages get replayed - without that, users receive duplicates. For estimation, state your assumptions out loud: notifications per day divided by 86400 gives average writes per second, and you should size for a peak several times that.
Q: How would you find the shortest path through a grid of 0s and 1s?
Use BFS from the start cell, because BFS on an unweighted graph reaches every cell by the fewest moves the first time it arrives there - so the moment you dequeue the target, the distance recorded is optimal. Push the start into a queue with distance 0, mark it visited, and on each pop expand the four neighbours that are in bounds, are passable, and are unvisited. Time and space are both O(rows x cols) since each cell is enqueued at most once. DFS is the wrong choice here: it will find a path but not necessarily the shortest one. If the cells carry different traversal costs, upgrade to Dijkstra with a priority queue, and if a good heuristic exists such as Manhattan distance, A-star prunes the search further.
Frequently asked questions about Intuit interviews
Section titled “Frequently asked questions about Intuit interviews”What is the Intuit interview process for engineers?
Intuit’s engineering loop typically runs: 1. Recruiter screen (30-40 min) - background, motivation, logistics. 2. Online Assessment (60-90 min on the Glider platform) - 2-4 DSA problems. 3. One or two Technical interviews (30-60 min each) - coding, OOPs/CS fundamentals, and a project deep-dive. 4. Craft Demo (around 90 min, common on SDE-2+ and senior loops) - live coding on a codebase shared 24-48 hours in advance. 5. System design (SDE-2+) and a closing Hiring Manager/HR conversation (20-30 min). Community-reported timelines put the full process at roughly 3-6 weeks.
What is Intuit’s Craft Demo round?
The Craft Demo is Intuit’s most distinctive round, reported mainly on SDE-2 and senior loops. Candidates get access to a small GitHub repository 24-48 hours ahead of time and are asked to implement 1-2 new user stories live in front of 2-4 interviewers, roughly 90 minutes total. It’s scored on working code, but also on test coverage, error handling, and how clearly you explain trade-offs while you build - closer to a real code review than a whiteboard problem.
What is Design for Delight (D4D) and why does it come up in interviews?
Design for Delight is Intuit’s internal innovation framework, built on three principles: Deep Customer Empathy, Go Broad to Go Narrow, and Rapid Experimentation. Interviewers - especially in the Craft Demo and behavioral rounds - often use it as a lens: they want to hear how you understood a user’s real problem, considered more than one option, and tested an idea cheaply before committing, not just that you shipped something.
What questions are asked in Intuit interviews?
Coding rounds lean on arrays/strings, matrix traversal, tree/graph problems (e.g. delete a node and return the remaining forest), and data-structure design questions (O(1) insert/delete/getRandom). CS fundamentals cover OOPs, DBMS (ACID, indexing), and operating systems basics. System design rounds (mostly SDE-2+) ask for things like a photo-storage or notification service. Behavioral and Craft Demo rounds probe Intuit’s five operating values and its Design for Delight framework.
How many rounds are there in the Intuit interview?
Most community-reported loops describe 4-6 stages: recruiter screen, Online Assessment, one or two technical interviews, an optional Craft Demo (common at SDE-2+), and a closing hiring-manager/HR round. Exact composition varies by level and team, so treat this as a range, not a fixed script.
Does Intuit hire at TCS/Infosys-style campus scale?
No. Intuit’s Bengaluru office does hire new graduates, but candidate reports describe a smaller, more selective funnel - a targeted early-career program plus off-campus and referral hiring - not a multi-thousand-seat placement drive. Verify any specific college-drive or headcount claim with your placement cell or Intuit’s own careers page.
How should I prepare for Intuit interviews?
Drill medium DSA (arrays, trees, graphs, and O(1) data-structure design), revise OOPs/DBMS/OS fundamentals, and practice reading and extending someone else’s codebase quickly and cleanly - that’s exactly what the Craft Demo tests. For behavioral rounds, prepare STAR stories mapped to Intuit’s operating values (Customer Obsession, Courage, Integrity without Compromise) and be ready to describe a time you validated an idea with real users before building it (Design for Delight).