Intuit Interview Guide (2026)

1Snapshot, read this first#

The one thing to understand about Intuit: it sells financial confidence to non-technical people, so every round silently asks "do you think about the customer?"

• Technical skill gets you in the room; customer obsession gets you the offer.
• A perfect LRU cache with the word "user" never spoken is a borderline pass at best.
• A decent solution plus "what does the person on the other end actually need here" moves you up a notch in every interviewer's notes.

2Getting the call (the part most guides skip)#

Referrals beat the portal. Recruiters get flooded, so an internal referral is the single most effective move.

• Find Intuit engineers on LinkedIn (search "Intuit" + your location, filter by SWE).
• Send a short, genuine note and ask for a referral with your resume attached.
• One warm referral usually outperforms fifty cold applications.
• Keep the note to three sentences: who you are, one specific thing you built that maps to their team, and the direct ask.
• Busy engineers refer people whose email they can forward to a recruiter in ten seconds. Do not send a wall of text.

Resume rules. Screeners skim for impact, not responsibilities. Every bullet reads: action, then what you built, then measurable result.

• Weak: "Worked on backend APIs."
• Strong:

Built a caching layer (Redis) for the payments service that cut p95 latency from 820ms to 190ms and reduced database load by 40%, serving 2M daily requests.

• Numbers make you credible. No production numbers? Quantify scope: data size, users, latency, test coverage, percentage improvement.
• "Handled 500GB of event data" and "raised coverage from 40% to 85%" are both numbers a reviewer respects.
• A resume with zero numbers reads as someone who never measured their own work. For a company that measures everything, that is a quiet red flag.

ATS keywords. Mirror the job description, do not keyword-stuff.

• Backend roles: Java, Spring Boot, microservices, REST/GraphQL, AWS, Kafka, SQL/NoSQL, CI/CD, Docker/Kubernetes.
• Full-stack: add React/TypeScript.
• Weave keywords into real bullets: "built a Kafka consumer that processed X events," not a blob of forty technologies you touched once.
• If a keyword is on your resume, be ready to be grilled on it. The phone screen will pick one and go three questions deep.

How people actually get shortlisted. Three main doors:

• Campus. Intuit hires heavily from top Indian and US campuses via on-campus OA plus interviews.
• Off-campus / referral. Apply on the careers site with a referral, or respond to a recruiter who found your profile.
• Hiring events / hackathons. Recruiting events and a coding challenge (often HackerRank or CodeSignal) route strong performers straight to interviews.

3The loop at a glance#

How to read the table:

• Not every candidate gets every round; the onsite loop is usually 4-5 back-to-back interviews.
• Senior candidates get heavier design and leadership weighting.
• The "Craft & Culture" round is not a soft throwaway. It carries real veto weight.

4The coding / technical rounds, patterns, not problems#

The coding bar sits at solid LeetCode medium, occasionally touching medium-hard in onsites. Obscure competitive-programming puzzles are rare. A handful of patterns repeat:

• Arrays & strings: two pointers, sliding window (longest substring without repeating, min window), prefix sums, interval merging.
• Hashing: frequency maps, group anagrams, two-sum family, subarray-sum-equals-k.
• Trees & graphs: BFS/DFS, level-order traversal, lowest common ancestor, number of islands, course schedule (topological sort).
• Heaps / intervals: top-k elements, merge k sorted lists, meeting rooms.
• Dynamic programming: coin change, longest increasing subsequence, edit distance, house robber, grid paths. Usually the "medium" tier, not exotic DP.
• Design-flavored coding: LRU cache, rate limiter, parking lot, in-memory key-value store. These bridge into the LLD round.

What you will most likely see:

• Phone screen: a sliding-window or hashing problem.
• Onsite coding: a graph (islands or topological sort) plus a DP or heap problem across the two rounds.
• A design-flavored prompt like LRU cache that quietly tests whether you can structure classes under time pressure.
• Pattern distribution matters more than chasing rare problems.

How to practice:

• Do ~120-150 LeetCode problems focused on the patterns above, not random grinding.
• Use NeetCode's roadmap or Blind 75 / Grind 75 as your spine, then add Intuit-tagged mediums.
• Re-solve problems you miss until the pattern is reflex.
• The goal is not 150 solved once. The goal is that a new problem triggers "this is a sliding window" or "this smells like topological sort" within thirty seconds.

1. Clarify first. Restate the problem; ask about input size, duplicates, empty/null, sorted or not. Two or three sharp questions save you from coding the wrong thing for fifteen minutes.
2. Talk through your approach before coding. State a brute force, then optimize. Say the complexity out loud: "This is O(n log n) because of the sort." Get a nod before you type.
3. Narrate while coding. Silence reads as "stuck." A good interviewer wants to steer you back on track, but only if they can hear your reasoning.
4. Write clean code. Good names, small helpers, no magic numbers. Name the variable remainingBudget, not r. They are imagining your pull request.
5. Test. Walk a small example, then edge cases (empty, single element, duplicates, overflow). Ask "does this handle an empty array?" yourself, out loud, then handle it.
6. State final complexity in time and space, and whether you would trade memory for speed: "O(n) time and O(n) space; I could drop to O(1) space but I would lose the path, so I kept the map."

5System design (HLD for senior, LLD for junior)#

Senior candidates get a High-Level Design round. Expect open-ended prompts tied to Intuit's domain:

• Design a tax-filing or document-upload service that scales to seasonal spikes (the April tax rush).
• Design a notifications service (email/push/SMS) for millions of users.
• Design a payments / transactions ledger with correctness and idempotency.
• Design a URL shortener, rate limiter, or news feed as warm-ups.

The seasonal-spike angle is genuinely Intuit-specific.

• TurboTax load in mid-April can be an order of magnitude above a quiet November.
• Reason out loud about autoscaling, queue-based load leveling (so you do not drop filings at peak), and graceful degradation.
• Graceful degradation example: accept the filing into a durable queue and process asynchronously, rather than failing the user when downstream is saturated.
• On payments and ledger prompts, the word they want is idempotency: a retried "submit payment" must not double-charge. Talk about idempotency keys and exactly-once effects even when delivery is at-least-once.

Use a repeatable framework:

1. Clarify requirements: functional (what it does) and non-functional (scale, latency, consistency, availability). Ask about read/write ratio and QPS.
2. Estimate scale: back-of-envelope users, requests/sec, storage. Intuit spikes seasonally, so mention elasticity.
3. Define APIs: a few core endpoints with inputs/outputs.
4. High-level diagram: client to load balancer to services to data stores to queues/caches.
5. Deep-dive on data: SQL vs NoSQL and why, schema, partitioning/sharding, indexing.
6. Address bottlenecks: caching (Redis), async processing (Kafka/SQS), replication, CDN.
7. Tradeoffs: consistency vs availability (CAP), cost, failure modes, monitoring. Name the tradeoffs out loud; that is the whole point.

A minimal diagram you can reproduce on a whiteboard for most of these prompts:

Junior candidates get LLD / object-oriented design.

• Prompts: design a parking lot, elevator system, library, or a QuickBooks-style invoice module.
• They evaluate clean class design, correct OOP (encapsulation, inheritance, composition), SOLID principles, and the right pattern (factory, strategy, observer, singleton).
• Start with core entities, define relationships, then flesh out methods.
• Verbalize why you chose composition over inheritance.
• Concrete win: for an invoice module, a TaxStrategy interface with per-region implementations beats a giant if region == ... block. Saying so out loud shows you know the strategy pattern and why it exists, not just its name.

Freshers / CS fundamentals. Be ready for crisp answers with examples:

• OS: processes vs threads, deadlock, scheduling, paging.
• DBMS: normalization, ACID, indexing, joins, transactions, isolation levels.
• Networks: TCP vs UDP, HTTP/HTTPS, DNS, what happens when you type a URL.
• OOP: four pillars, abstraction vs encapsulation.
• For "what happens when you type a URL," go DNS resolution, TCP handshake, TLS, HTTP request, server response, browser render, without skipping a layer. Depth on one layer beats a shallow sprint through all of them.

6Behavioral & culture fit#

Intuit interviews hard on values. Its leadership operating values center on:

• Customer-obsessed.
• Bold (think big, take smart risks).
• Driving values of integrity and inclusion.
• The internal philosophy: "fall in love with the customer's problem, not your solution."
• The practices Design for Delight and Follow Me Home (literally observing customers to understand pain).

How to show the mindset without having worked there:

• Frame stories around understanding users, questioning assumptions, and owning outcomes.
• Lead with the problem the user had, not the stack you picked.
• "Users were abandoning at checkout" beats "I built a microservice in Spring Boot" as an opening line. The stack can be sentence two.

Write 6 to 8 STAR stories in advance, covering a conflict, a failure you owned, a time you improved something for users, a time you influenced without authority, a tight deadline, and a disagreement with a manager or teammate.

• Keep each to 90 seconds spoken.
• Practice out loud, not in your head. A story that reads clean on paper often rambles when you say it.
• Rehearse the first two sentences until they are tight. That is where the interviewer decides whether this is a crisp answer or a five-minute meander.

One full worked STAR example (customer obsession):

• Situation: Our onboarding flow had a 55% drop-off at the email-verification step; support tickets kept citing "didn't get the code."
• Task: I owned onboarding and was asked to lift activation without a full redesign.
• Action: Instead of guessing, I watched 10 session recordings and interviewed 4 users (my version of a "follow me home"). The codes were arriving but landing in spam, and the UI gave no retry. I moved sending to a warmed-up transactional provider, added a visible "resend code" with a 30-second timer, and instrumented the funnel.
• Result: Drop-off at that step fell from 55% to 18% in three weeks, lifting overall activation by 22% and cutting related support tickets by ~40%.

Why this answer lands:

• Real customer insight, concrete action, a number in the result.
• Notice what is missing: I did not open with "I had a hunch." I opened with evidence I went and gathered.
• For a company built on Follow Me Home, "I watched real users" is close to a magic phrase.
• A failure story works too, as long as you land it on what you changed afterward.

Lead with the customer's problem, not your solution. That one habit colors every behavioral and design answer.

7Your prep plan#

4-week plan

• Week 1: Patterns, arrays, strings, hashing, two pointers, sliding window. ~30 problems. Draft 4 STAR stories.
• Week 2: Trees, graphs, heaps, recursion/backtracking. ~30 problems. Start one mock interview.
• Week 3: DP + LLD/OOP design. Learn the HLD framework; do 3 design walkthroughs. Finish all 8 STAR stories.
• Week 4: Mixed timed mocks (coding + design + behavioral), review weak patterns, polish communication and complexity narration.

2-week plan

• Days 1-5: Blind 75 by category; re-solve misses.
• Days 6-9: Graphs, DP, and one design round per day (LLD if junior, HLD if senior).
• Days 10-12: 3-4 full mock loops; record yourself talking aloud.
• Days 13-14: Behavioral stories, CS fundamentals review, light revision.

2-day crash plan

• Day 1 AM: Grind 75 mediums, arrays, hashing, two pointers, sliding window. PM: trees + graphs (BFS/DFS, topological sort).
• Day 2 AM: One system design walkthrough end-to-end + LRU cache coding. PM: write 5 STAR stories, review complexity talking points, sleep early.

The one activity that pays off most:

• Whichever plan you run, the recorded mock is the highest-return thing you can do.
• Watching yourself code and talk is uncomfortable, and it shows you exactly where you go silent, skip edge cases, and drop your "why."
• Fixing that is worth more than ten extra solved problems.

8Why people get rejected at Intuit#

1. Coding in silence. A correct answer with no narration still reads as a weak signal. Intuit grades your reasoning, not just the output.
2. Skipping edge cases and tests. Not handling empty input, nulls, or overflow signals you would ship bugs.
3. No customer thread in behavioral answers. Pure technical stories with no "who did this help" fall flat against their values.
4. Can't justify tradeoffs in design. Drawing boxes without explaining why SQL vs NoSQL or sync vs async sinks the design round.
5. Over-engineering or over-claiming. Jumping to a clever solution before the brute force, or taking credit for a whole team's work when probed.
6. Weak fundamentals under follow-up. Getting the first answer but crumbling on "why is that O(n)?" or "what if the input is 10x bigger?"

9The offer, comp & negotiation#

Intuit pays competitively, with a meaningful equity (RSU) component and an annual bonus.

• India (Bangalore): SWE 2 total compensation typically ranges ₹28-45 LPA (base + RSUs + bonus); Senior SWE often ₹55-90 LPA+ depending on level and stock. New-grad offers are generally in the lower band.
• US: SWE 2 / E4 total comp commonly lands around $180k-$260k (base roughly $140k-$175k, plus RSUs and ~10-15% target bonus); Senior and Staff go considerably higher.

Negotiation tips for Intuit's context:

1. Negotiate the whole package, not just base. RSUs and the sign-on bonus often have the most give. Base often has a tight band tied to level, so pouring all your effort there leaves the bigger levers untouched. Ask for the breakdown and push on the component with headroom.
2. Use competing offers factually. A written competing offer is your strongest lever; state numbers calmly and let the recruiter close the gap. No bluffing. Recruiters at this level talk to each other and can smell an invented number, and getting caught poisons the whole negotiation.
3. Anchor on level. If your experience justifies a higher level, make the case early. The jump from SWE 2 to Senior moves both the base band and the RSU grant, a far bigger swing than squeezing another few percent inside one level.

Before you sign:

• Always get the final offer in writing.
• Confirm the vesting schedule and refresh/bonus policy.
• Ask specifically how RSUs vest (the shape over four years) and whether there is an annual refresh grant. Two offers with the same headline number can differ by tens of thousands over four years depending on those two details.

Want this turned into a personalized, dated study plan that fits your timeline and target start date? Tell me your interview date and I'll map every week for you.