Intuit India Interview Preparation 2026: Craft Demo, DSA, Design and Salary

Intuit is one of the more distinctive interview loops among product companies in India. Alongside the usual coding and design rounds, it is known for the craft demo: instead of only solving puzzles on a whiteboard, you build a small piece of working software and present it to engineers who question every decision. Candidates who prepare only LeetCode often find this round the hardest. Candidates who build real software every day often find it the most comfortable.

This guide explains how the Intuit India loop commonly runs, takes the craft demo apart with a worked example, covers the DSA, design and values rounds, and lists levels and approximate pay. A standing caveat: Intuit's process differs by team, level and hiring season. What follows is the commonly reported process from candidate experiences and public sources. Confirm the specific format with your recruiter, who will usually describe it in detail if you ask.

Intuit India at a Glance

Intuit is a US financial software company. Its India development centre in Bengaluru is one of its largest engineering sites outside the US, and Indian teams work on core products as well as platform engineering. Context that helps in interviews:

Intuit consistently appears in lists of good workplaces, and many engineers describe its culture as customer-focused and design-thinking oriented. Its "Design for Delight" approach comes up in conversation. When researching, check recent reviews for your specific team, because experiences vary more by team than by company (see how to research a company before joining).

The Intuit India Interview Process (Commonly Reported)

The full process is often scheduled as a "loop day", with the craft demo presentation and the other rounds held on the same day or across two days, virtually or in the Bengaluru office. From application to offer typically takes a few weeks, depending on how quickly you finish the craft demo. Some teams skip the OA for experienced hires with referrals, and some fold the coding round into the craft demo.

How the loop changes by level

The Craft Demo, Explained

The craft demo tests whether you can build software the way you would on the job: understand a fuzzy requirement, make sensible scoping decisions, write clean and tested code, and explain your choices to peers. It is close to the machine coding rounds at Flipkart and Swiggy, with more emphasis on the presentation and discussion.

Typical format

• The brief: a short problem statement, often a small full-stack app or backend service with a few features, sometimes with a finance or productivity flavour. Requirements are deliberately a little open-ended.
• Build time: commonly reported as a take-home spanning a few days up to about a week, though some teams use a shorter timed build. Expect to spend several focused hours, not days of polishing.
• Presentation: typically around an hour with 2–3 engineers. A short demo, a code walkthrough, then questions on decisions, trade-offs, testing, scale and "how would you add X?". Sometimes the panel asks you to make a small live change.

What the panel evaluates

Worked Craft Demo Example: Expense Splitter API

Here is an illustrative brief in the style of commonly reported craft demos. It is not an actual Intuit prompt. It shows how to approach one.

Brief: Build a service that lets a group of users record shared expenses and see who owes whom. Users can create a group, add expenses (paid by one member, split equally or by exact amounts among some members), and view simplified balances. Provide an API, and a minimal UI if you wish.

Step 1: Clarify and write down assumptions (30 minutes)

• Single currency (INR); amounts stored in paise as integers to avoid floating-point rounding errors. Mention this explicitly in the demo; it is a finance company.
• Equal split remainder: when ₹100 is split three ways, distribute the leftover paise deterministically (e.g. the first members get 3,334, 3,333, 3,333 paise).
• Authentication is out of scope; a user ID header stands in for it. Say this in the README.
• Out of scope: multi-currency, recurring expenses, notifications. Each one is listed as a possible extension.

Step 2: Design (45 minutes)

Key decision: store expense shares, compute balances on read. Balances are derived data. Storing them separately risks inconsistency, while computing them from shares is O(number of shares) per group, which is fine at this scale. In the demo, say what you would change at scale: maintain a per-member running net balance, updated in the same transaction as each expense insert.

Step 3: Core logic with tests first

The interesting algorithm is simplifying debts: compute each member's net balance, then repeatedly settle the largest creditor against the largest debtor. This greedy approach produces at most n−1 transactions. Finding the true minimum number of transactions is NP-hard in general, which is worth saying if asked.

import java.util.*;

public final class DebtSimplifier {

    public record Transfer(String from, String to, long amountPaise) {}

    /** netPaise: positive = is owed money, negative = owes money. Must sum to zero. */
    public static List<Transfer> simplify(Map<String, Long> netPaise) {
        long total = netPaise.values().stream().mapToLong(Long::longValue).sum();
        if (total != 0) throw new IllegalArgumentException("Balances must sum to zero");

        // max-heaps by absolute amount
        PriorityQueue<Map.Entry<String, Long>> creditors =
            new PriorityQueue<>((a, b) -> Long.compare(b.getValue(), a.getValue()));
        PriorityQueue<Map.Entry<String, Long>> debtors =
            new PriorityQueue<>((a, b) -> Long.compare(a.getValue(), b.getValue()));
        for (var e : netPaise.entrySet()) {
            if (e.getValue() > 0) creditors.add(new AbstractMap.SimpleEntry<>(e));
            else if (e.getValue() < 0) debtors.add(new AbstractMap.SimpleEntry<>(e));
        }

        List<Transfer> result = new ArrayList<>();
        while (!creditors.isEmpty() && !debtors.isEmpty()) {
            var c = creditors.poll();
            var d = debtors.poll();
            long amount = Math.min(c.getValue(), -d.getValue());
            result.add(new Transfer(d.getKey(), c.getKey(), amount));
            long cLeft = c.getValue() - amount;
            long dLeft = d.getValue() + amount;
            if (cLeft > 0) creditors.add(new AbstractMap.SimpleEntry<>(c.getKey(), cLeft));
            if (dLeft < 0) debtors.add(new AbstractMap.SimpleEntry<>(d.getKey(), dLeft));
        }
        return result;
    }
}

Dry run: A paid ₹300 for A, B and C equally, and B paid ₹90 for B and C equally. Nets in rupees: A +200 (paid 300, owes 100); B: paid 90, owes 100 + 45, so −55; C owes 100 + 45, so −145. Sum: 200 − 55 − 145 = 0. Step 1: largest creditor A (200), largest debtor C (−145): C pays A 145. A now has 55 left; C is settled. Step 2: A (55) against B (−55): B pays A 55. That makes two transfers, which is at most n − 1 = 2. Each heap operation is O(log n), and each iteration settles at least one member, so the total is O(n log n).

Tests to write and show: an equal split with a paise remainder, exact splits that don't add up to the total (must be rejected), a single member, everyone already settled, a member in two groups, and the dry-run case above.

Step 4: The presentation (rehearse it)

1. Two minutes on the problem and scope: what you built, what you deliberately left out, your assumptions.
2. Five minutes of live demo of the main flow, including an error case such as an invalid split. Keep a recorded backup in case your local setup fails.
3. Ten minutes of code walkthrough: structure first, then the most interesting logic (debt simplification, the paise handling), then the tests.
4. The rest for Q&A. Common questions: How would you support multiple currencies? What if two people add expenses at the same time? How would this scale to millions of groups? How would you add authentication? What would you monitor in production? What would you refactor with more time?

For practice building and presenting similar problems, the Splitwise LLD guide is a close cousin. For the presenting skills, how to explain projects in interviews covers the follow-up questions in depth.

Online Assessment and DSA Rounds

Commonly reported Intuit coding questions fall in the easy-to-medium range, with standard patterns:

• Arrays, strings and hashing: frequency counting, two pointers, sliding window, anagram and substring problems.
• Trees and graphs: traversals, LCA, BFS on grids, connected components, topological sort.
• Heaps and intervals: top-K, merging intervals, meeting rooms.
• Dynamic programming: occasionally, classic 1-D and 2-D problems.
• Design-flavoured coding: LRU cache, a rate limiter or simple data-structure design, especially for SE2.

Because the craft demo emphasises engineering quality, interviewers in live coding rounds tend to notice clean code, naming and testing more than at puzzle-heavy companies. Narrate, test on examples and handle edge cases (see thinking out loud in coding interviews). For the OA, practise timed sets on HackerRank-style platforms; online assessment tips covers the mechanics.

System Design and LLD

At SE2 and above, expect a design discussion. Finance-flavoured prompts fit naturally: an invoicing service, a payments-reconciliation pipeline, a notification system, a tax-document upload and processing pipeline, or a rate limiter for public APIs. Areas that get extra attention in a financial-software context:

• Correctness and consistency: transactions, idempotency for payments and retries, double-entry style ledgers. Read ACID and isolation levels and payment system design.
• Seasonal peak load: tax filing has sharp deadline peaks. Expect "how does this handle 10× traffic in the last week of filing season?" Discuss autoscaling, queue-based load levelling, and degrading non-critical features.
• Security and privacy: PII and financial data, encryption at rest and in transit, access control, audit logs.
• Observability: what you would measure and alert on.

For LLD, practise class design with SOLID and common patterns (strategy for split types, observer for notifications, factory for document parsers). The system design preparation guide lays out the full framework.

Values and Hiring Manager Round

Intuit publicly lists its values as Integrity Without Compromise, Courage, Customer Obsession, Stronger Together, and We Care and Give Back. Behavioural questions commonly map to these. Prepare one or two STAR stories for each:

The hiring manager will also ask why Intuit and why this team. Specific answers win: mention the product area, a recent AI feature you have read about, or the domain (small-business finance, tax). Use the STAR method guide to structure the stories, and keep two good questions ready for the end (questions to ask your interviewer).

Intuit India Levels and Approximate Salary (2026)

Intuit's engineering ladder commonly includes Software Engineer 1, Software Engineer 2, Senior Software Engineer, Staff Software Engineer, Senior Staff, Principal and Distinguished Engineer. The figures below are approximate 2026 total-compensation ranges (base + bonus + annualised stock) from public sources such as levels.fyi, AmbitionBox and Glassdoor. They vary by team, experience, negotiation and stock price. Use them for orientation only.

Compensation typically combines base pay, an annual bonus tied to company and individual performance, and RSUs, because Intuit is listed in the US. Ask the recruiter for the RSU vesting schedule and refresher practice, and compare offers year by year. Salary hikes on a job switch shows how to do that comparison, and SDE salary bands across India gives market context.

A 4-Week Intuit Prep Plan

If your interview is sooner, prioritise in this order: the craft demo (it is the round most specific to Intuit), then DSA mediums, then values stories, then design. For a compressed DSA plan, use the 30-day coding interview plan.

Frequently Asked Questions

Pranjal Jain

Ex-Microsoft SDE · IIT Kanpur · Founder of Prepflix. Helps engineers crack startup and product company interviews across India.