Intuit Coding Interview Questions & the Craft Bar

Intuit builds software that people use while they are anxious - filing taxes, chasing invoices, running payroll for a small business. That context shapes its interviews more than most candidates expect. The coding problems candidates typically describe are practical rather than exotic, the quality of the code you leave on the screen is weighted heavily, and the behavioral round about customers and values is a real evaluated round, not a warm handshake at the end.

This guide covers the process as candidates commonly report it, what the craft bar means in practice, the data and ML surface area behind products like TurboTax, QuickBooks, Credit Karma, and Mailchimp, and a two-week plan. As always we describe problem types and patterns rather than claiming access to leaked prompts - question sets rotate, and only pattern fluency transfers.

The Intuit software engineer process

The practical consequence: budget real preparation time for the non-algorithm rounds. Candidates who allocate every hour to LeetCode and improvise the values conversation are the ones who report being surprised by the outcome. If you want the general mechanics of how a multi-round loop is scored and debriefed, see our full-loop interview guide.

Practical coding, not puzzles

The recurring theme in candidate reports is that Intuit problems look like work. Instead of an abstract trick, you are more likely to get something with a plausible product shape: clean up and aggregate a set of records, reconcile two lists, apply a tiered rule to an amount, or build a small in-memory structure that answers a question quickly.

The underlying skills are still standard, and the useful ones to have automatic are:

• Arrays, strings, and hash maps. Parsing, grouping, deduplication, and counting - the backbone of most practical prompts.
• Sorting and custom comparators. Ordering records by several keys, and stability when it matters.
• Two pointers and sliding window. Range and subarray questions, often dressed as date ranges or billing periods.
• Trees and graphs. BFS and DFS, hierarchy traversal - a category tree, an org chart, a dependency graph.
• Light dynamic programming. Recognize and set up a recurrence; the classics are enough.
• Object-oriented design. Model a small domain with clean class boundaries; a common alternative to a pure algorithm round.
• SQL and data modeling. Joins, group-by, and window-function basics, plus how you would lay out the tables. Our SQL interview help guide covers the query patterns that come up most.

Money and dates are a quiet theme worth preparing deliberately. Financial products make rounding, precision, currency, and time-zone handling into correctness questions rather than nitpicks, and mentioning them unprompted is a genuine differentiator.

from decimal import Decimal, ROUND_HALF_UP

def apply_tiered_rate(amount, tiers):
    """Apply progressive tiers to `amount`.
    tiers: [(upper_bound or None, rate)] in ascending order.
    Amounts are Decimal, never float, so cents stay exact."""
    total, lower = Decimal("0"), Decimal("0")
    for upper, rate in tiers:
        cap = amount if upper is None else min(amount, Decimal(upper))
        if cap <= lower:
            break                      # tier not reached
        total += (cap - lower) * Decimal(rate)
        lower = cap
    return total.quantize(Decimal("0.01"), rounding=ROUND_HALF_UP)

The code itself is unremarkable. What earns credit is saying why Decimal replaces float for money, why the rounding mode is chosen explicitly rather than inherited, and which edge cases you would test: a zero amount, an amount below the first tier boundary, and an amount above the final open-ended tier.

The craft bar: what "good code" means here

Craft is the expectation that the code you leave on the screen could plausibly go into a real codebase. Interviewers are looking for habits, and the habits are teachable:

• Name things properly. pending_invoices over arr2. It costs nothing and reads as professional maturity.
• Write a working version, then clean it. Say "that works - let me extract this into a helper and rename it" out loud. Visible iteration is a positive signal, not an admission of weakness.
• Handle errors deliberately. What happens with malformed input, a missing field, or a null? Decide and say so instead of silently assuming a happy path.
• State your tests. Even without writing them, list the cases: empty input, a single element, duplicates, boundary values, and one realistic messy record.
• Name the trade-off. Time and space complexity, and when you would choose the simpler version over the faster one. Willingness to prefer readable-and-sufficient is itself a signal.

The anti-pattern to avoid is declaring victory the instant the sample input passes. The last two minutes - a quick reread, an edge case caught, a rename - often do more for your feedback than a marginally faster algorithm would.

Customer empathy as a technical skill

Intuit's culture is unusually explicit about customer obsession, and it leaks into the technical rounds. Interviewers respond well when you ask who is using the thing you are building and what happens to them when it fails. Concretely, that looks like:

• Clarifying the user before the algorithm. "Is this for an accountant handling hundreds of clients, or a sole proprietor with twelve transactions?" changes the right answer.
• Treating failure as a product event. A failed import is not just an exception; it is a person staring at a screen near a deadline. Say what they would see.
• Weighing correctness against speed honestly. In financial software, being right is usually worth latency, and saying that shows domain judgment.
• Scoping like an engineer with a roadmap. What you would ship first, and what you would deliberately defer.

Data and ML relevance

Intuit's products are data products underneath: transaction categorization, anomaly and fraud signals, document extraction, forecasting, and increasingly assistive AI features. Even for a general software engineering role, being comfortable one step into that territory helps.

• SQL and data modeling - joins, aggregation, window functions, and schema design for transactional data.
• Pipeline basics - batch versus streaming, idempotency, reprocessing after a bad run, and late-arriving data.
• Data quality - deduplication, reconciliation between two sources, and handling records that disagree.
• For data science and ML roles - feature construction, class imbalance, evaluation metrics beyond accuracy (precision and recall on an imbalanced fraud-like problem), and how you would monitor a model after launch. Our machine learning interview help guide goes deeper.

The values and behavioral round

Prepare this round as seriously as the coding rounds. Build four or five STAR stories that cover customer impact, ownership of something that went wrong, learning and adapting, cross-functional collaboration, and a time you influenced a decision without authority. For each, be able to state the user or stakeholder, what you personally did, and what measurably changed.

Two details that consistently improve these answers: name a real metric or outcome instead of saying "it went well", and be willing to describe a failure honestly, including what you would do differently. Our STAR examples guide has templates you can adapt.

What interviewers actually score

• Clarifying first. Constraints, input format, and who the user is - before any code.
• Code quality under time pressure. Readable, named, and cleaned up rather than merely passing.
• Edge-case instinct. Especially around money, dates, nulls, and duplicates.
• Communication. A narrated thought process, including the dead ends you rejected and why.
• Customer framing. Connecting a technical choice to what a real user experiences.

A note on integrity: prepare thoroughly and reason honestly in the room. Interviewers are experienced at telling genuine problem solving from a memorized script, and the craft and values rounds in particular reward real understanding over a rehearsed surface.

A realistic two-week prep plan

1. Days 1-4: Core patterns - arrays, strings, hash maps, sorting, two pointers - from our LeetCode patterns post. Prioritize easy-to-medium fluency and clean code over hard problems.
2. Days 5-7: Trees, graphs (BFS/DFS), recursion, and light dynamic programming. Add one object-oriented design exercise: model invoices, customers, and payments.
3. Days 8-9: SQL and data modeling practice - joins, group-by, window functions - plus one money-and-dates exercise where you write out rounding and time-zone decisions explicitly.
4. Days 10-11: Craft drills. Re-solve three earlier problems and spend the last five minutes of each refactoring, naming, and listing test cases out loud.
5. Days 12-14: Values stories in STAR form, each with a user and an outcome, plus a timed solo mock that pairs one practical coding problem with two behavioral questions.

FAQ

How hard are Intuit coding interview questions?

Candidates typically describe a practical, moderate bar rather than a puzzle gauntlet: mostly easy-to-medium data structures and algorithms, often framed around realistic data handling such as parsing records, aggregating transactions, or modeling a small feature. Readable, well-tested code and clear reasoning usually count for more than squeezing out the cleverest possible solution.

What is the craft bar in an Intuit interview?

Craft is the expectation that your code would survive contact with a real codebase: sensible naming, small functions, handled edge cases, deliberate error handling, and a stated testing approach. In practice it means narrating trade-offs, cleaning up after a working first pass, and saying what you would test rather than declaring done the moment the sample input works.

Does Intuit ask behavioral questions about its values?

Yes. Intuit is known for a strong values and customer-obsession culture, and the behavioral portion is a real evaluated round rather than a formality. Prepare STAR-format stories that show customer empathy, ownership, learning from a failure, and collaboration across functions, and make sure at least one story explains who the user was and what changed for them.

Do I need data or machine learning knowledge to interview at Intuit?

It depends on the role. Intuit's financial products lean heavily on data, so backend and platform candidates benefit from comfort with SQL, data modeling, and pipeline basics, while data science and ML roles go deeper into features, evaluation metrics, and model behavior. For a general software engineering role, solid SQL and data-modeling fluency is usually enough.

What does the Intuit software engineer interview process look like?

Candidates commonly describe a recruiter screen, an online assessment or technical phone screen, and then a virtual or onsite loop of several rounds covering coding, design or a practical technical discussion, and behavioral questions tied to Intuit's values. Structure varies by team, level, and location and changes over time, so confirm your specific schedule with your recruiter.