Study Notes by Niladri & AI

Company-08-Intuit

Properties1
tagscompany-prep, intuit, interview-prep, java

20 min read

Intuit Interview Prep

Interview Profile

  • Format: 4–5 rounds — typically 1 online assessment, 2 coding rounds, 1 system design (financial data pipelines), 1 behavioral
  • Coding focus: Medium difficulty problems with strong emphasis on HashMap/design correctness, DP for financial optimization, and interval/scheduling problems
  • System design focus: Data integrity and idempotency in transaction processing, financial calculation pipelines, TurboTax/QuickBooks product architectures
  • Senior bar: Correctness and data integrity over raw performance. Interviewers expect discussion of edge cases — negative values, zero transactions, overlapping fiscal periods, and idempotency in payment processing
  • What Intuit cares about: Financial domain accuracy, tax rule correctness, TurboTax/QuickBooks/Mint product context, and building systems where an incorrect answer is worse than a slow one

Pattern Frequency Breakdown

PatternEstimated FrequencyWhy Intuit Asks
HashMap / Design30%Account record management, deduplication, O(1) financial lookups
Dynamic Programming25%Tax optimization, investment strategies, budget allocation
Trees / Graphs20%Tax rule dependency ordering, org hierarchy rollups
Greedy / Intervals15%Fiscal period consolidation, audit scheduling, cash flow
Sliding Window10%Rolling financial aggregations, fraud detection windows

Problems From This Repo

The following problems from completed sessions directly map to Intuit interview patterns. Study them with the financial accuracy lens in mind.

ProblemSession LinkWhy Intuit
Insert Delete GetRandom O(1) (LC 380)[[Session-04-HashMap|Insert Delete GetRandom O(1)]]Account record management — O(1) add/remove/sample for transaction records
Top K Frequent Elements (LC 347)[[Session-04-HashMap|Top K Frequent Elements]]Expense category frequency analysis — top spending categories in QuickBooks
House Robber (LC 198)[[Session-09-DP1D|House Robber]]Alternate-period tax optimization — maximize deductions across non-adjacent fiscal periods
Coin Change (LC 322)[[Session-09-DP1D|Coin Change]]Denomination / deduction minimization — fewest tax deduction items to reach a target amount
Edit Distance (LC 72)[[Session-10-DP2D|Edit Distance]]Tax form field reconciliation — minimum edits to align user-entered data with IRS form fields
Course Schedule (LC 207)[[Session-08-Graphs|Course Schedule]]Tax rule dependency ordering — some deductions are only valid if prerequisite schedules are filed
Gas Station (LC 134)[[Session-12-Greedy|Gas Station]]Cash flow analysis — determine if a business can sustain operations through a full fiscal cycle
Meeting Rooms II (LC 253)[[Session-12-Greedy|Meeting Rooms II]]Audit scheduling — minimum number of auditors needed to handle overlapping audit windows
Time-Based Key-Value Store (LC 981)[[Session-03-BinarySearch|Time-Based Key-Value Store]]Versioned tax record lookup — retrieve tax rules valid at a specific effective date
Daily Temperatures (LC 739)[[Session-05-Stack|Daily Temperatures]]Stock / portfolio lookback — days until a position returns to a higher value

New Problems (Intuit-Specific)

The five problems below are not yet in the repo and are high-signal for Intuit interviews. Each includes a brute-force approach and the optimal approach with full Java code.

Problem 1: Merge Intervals (LC 56) — Medium

Link: LeetCode 56

Quick Summary: Given an array of intervals, merge all overlapping intervals and return the non-overlapping result array.

Industry Context: Fiscal period consolidation in TurboTax — when a user has multiple overlapping employment periods, deduction windows, or tax events, they must be merged before applying tax rules. Also applies to overlapping tax rule application windows (e.g., two different deduction rules both active during Q2 and Q3 must be merged into a single active window). The repo has LC 253 (meeting rooms / minimum rooms) and LC 435 (non-overlapping intervals / remove minimum) but not the canonical merge operation itself — this is the foundation both of those build on.

Approach 1: Brute Force — Pairwise merge with repeated passes

// Time: O(n²)  Space: O(n)
import java.util.*;
 
public static int[][] mergeIntervalsBrute(int[][] intervals) {
    // Repeatedly scan for any overlapping pair and merge until none remain
    List<int[]> list = new ArrayList<>(Arrays.asList(intervals));
    boolean merged = true;
    while (merged) {
        merged = false;
        for (int i = 0; i < list.size() && !merged; i++) {
            for (int j = i + 1; j < list.size() && !merged; j++) {
                int[] a = list.get(i), b = list.get(j);
                // Overlapping: a.start <= b.end && b.start <= a.end
                if (a[0] <= b[1] && b[0] <= a[1]) {
                    list.set(i, new int[]{Math.min(a[0], b[0]), Math.max(a[1], b[1])});
                    list.remove(j);
                    merged = true;  // restart scan
                }
            }
        }
    }
    return list.toArray(new int[0][]);
}
  • Time: O(n²) — up to n passes, each scanning the remaining list
  • Space: O(n) for the working list
  • Tradeoff: Correct but quadratic. Each “merge” may create a new overlap with a previously non-overlapping interval, requiring another full pass. In practice this is fine for small n (a single user’s tax events) but unacceptable for batch processing millions of accounts.

Approach 2: Optimal — Sort then single-pass greedy merge

// Time: O(n log n)  Space: O(n) output
import java.util.*;
 
public static int[][] mergeIntervalsOptimal(int[][] intervals) {
    if (intervals.length <= 1) return intervals;
 
    // Sort by start time — after sorting, any interval that overlaps with the
    // previous one must have start <= previous end (no need to look further back)
    Arrays.sort(intervals, (a, b) -> a[0] - b[0]);
 
    List<int[]> merged = new ArrayList<>();
    merged.add(intervals[0]);
 
    for (int i = 1; i < intervals.length; i++) {
        int[] last = merged.get(merged.size() - 1);
        int[] curr = intervals[i];
 
        if (curr[0] <= last[1]) {
            // Overlap — extend the last interval's end if needed
            last[1] = Math.max(last[1], curr[1]);
        } else {
            // Gap — no overlap, start a new interval
            merged.add(curr);
        }
    }
 
    return merged.toArray(new int[0][]);
}
  • Time: O(n log n) — dominated by sort; the merge pass is O(n)
  • Space: O(n) for the output list (output space, unavoidable)
  • Key Insight: After sorting by start time, a new interval can only overlap with the last interval in the merged list (not any earlier one), because all earlier intervals start before the current one and were already merged with everything overlapping them. This reduces the overlap check from O(n) per interval (brute force) to O(1) — just compare curr[0] <= last[1]. The greedy choice is always to extend the last interval as far as possible (Math.max(last[1], curr[1])), since extending it cannot cause us to miss a valid separation point — any future interval starting within the extended range would have overlapped with the original range too (after sorting).

Problem 2: Car Pooling (LC 1094) — Medium

Link: LeetCode 1094

Quick Summary: Given a list of trips [numPassengers, from, to] and a vehicle capacity, determine if all trips can be completed without exceeding capacity at any point.

Industry Context: Resource capacity sweep across pay periods at Intuit Payroll — given a list of employee payroll runs [headcount, periodStart, periodEnd] and a processing capacity, determine if the payroll batch processor can handle all runs without exceeding concurrency limits. Also models tax filing slots during peak season (April rush) where TurboTax must validate that concurrent active sessions never exceed server capacity. The difference array technique is not explicitly covered in the repo and is a senior-level signal: it processes point events rather than scanning all points in the range.

Approach 1: Brute Force — Simulate each location point

// Time: O(n * maxLocation)  Space: O(maxLocation)
import java.util.*;
 
public static boolean canFinishTripsBrute(int[][] trips, int capacity) {
    // Find the maximum location to know our sweep range
    int maxLoc = 0;
    for (int[] trip : trips) maxLoc = Math.max(maxLoc, trip[2]);
 
    int[] occupancy = new int[maxLoc + 1];
    for (int[] trip : trips) {
        // Add passengers from trip[1] up to (but not including) trip[2]
        for (int loc = trip[1]; loc < trip[2]; loc++) {
            occupancy[loc] += trip[1];  // Bug bait: add numPassengers, not trip[1]
        }
    }
    // Correctly: add trip[0] (numPassengers)
    Arrays.fill(occupancy, 0);
    for (int[] trip : trips) {
        for (int loc = trip[1]; loc < trip[2]; loc++) {
            occupancy[loc] += trip[0];
            if (occupancy[loc] > capacity) return false;
        }
    }
    return true;
}
  • Time: O(n * maxLocation) — for each trip, update every location in the range
  • Space: O(maxLocation)
  • Tradeoff: Correct. Works fine when locations span a small range. Degrades badly when locations are large integers (e.g., fiscal day 1 to day 365 — still acceptable) or when ranges are large (payroll period spanning years). The inner loop over the full range is the bottleneck.

Approach 2: Optimal — Difference array sweep line

// Time: O(n + maxLocation)  Space: O(maxLocation)
import java.util.*;
 
public static boolean canFinishTripsOptimal(int[][] trips, int capacity) {
    // Difference array: diff[i] represents the change in occupancy at location i.
    // Adding trip[0] passengers at trip[1] and removing them at trip[2]:
    //   diff[trip[1]] += trip[0]
    //   diff[trip[2]] -= trip[0]   (passengers exit AT trip[2], so decrement here)
    int maxLoc = 0;
    for (int[] trip : trips) maxLoc = Math.max(maxLoc, trip[2]);
 
    int[] diff = new int[maxLoc + 1];
    for (int[] trip : trips) {
        diff[trip[1]] += trip[0];   // passengers board at from
        diff[trip[2]] -= trip[0];   // passengers exit at to (half-open interval)
    }
 
    // Prefix sum of diff gives actual occupancy at each location
    int current = 0;
    for (int loc = 0; loc <= maxLoc; loc++) {
        current += diff[loc];
        if (current > capacity) return false;
    }
    return true;
}
  • Time: O(n) to fill diff array + O(maxLocation) to sweep = O(n + maxLocation)
  • Space: O(maxLocation) for the difference array
  • Key Insight: The difference array encodes events (board/exit) rather than continuous occupancy. diff[i] += delta means “occupancy increases by delta at point i”; diff[j] -= delta means “it decreases at point j”. The prefix sum reconstructs actual occupancy at every point in a single O(maxLocation) pass. This is strictly better than range-update + point-query (brute force) which is O(range) per update. In Java, the half-open interval semantics are critical: passengers exit AT trip[2], so decrement at diff[trip[2]] (not trip[2]-1) — they are not in the vehicle during the destination segment.

Problem 3: Best Time to Buy and Sell Stock IV (LC 188) — Hard

Link: LeetCode 188

Quick Summary: Given a stock price array and integer k, find the maximum profit from at most k transactions (buy then sell counts as one transaction).

Industry Context: Investment portfolio optimization for TurboTax’s tax-loss harvesting advisor — given k rebalancing opportunities per year, find the schedule that maximizes after-tax gain. This is the capstone of the stock problem family (LC 121 → 122 → 123 → 188) and is explicitly a hard problem that Intuit asks senior candidates who claim deep DP experience. The state-machine framing (holding vs. not-holding × transactions-used) is the senior signal — candidates who try to solve it ad-hoc without the state machine typically produce a solution that fails edge cases.

Approach 1: Brute Force — Recursive with memoization (top-down DP)

// Time: O(n * k)  Space: O(n * k) memo table + O(n) recursion stack
import java.util.*;
 
public static int maxProfitMemo(int k, int[] prices) {
    int n = prices.length;
    int[][] memo = new int[n][k + 1];
    for (int[] row : memo) Arrays.fill(row, -1);
    return solve(prices, 0, k, false, memo);  // Note: need 3D memo for holding state
}
 
// Full top-down DP (3D: day × transactionsLeft × holdingStock)
public static int maxProfitTopDown(int k, int[] prices) {
    int n = prices.length;
    // memo[day][transLeft][holding]: 0=no, 1=yes
    int[][][] memo = new int[n][k + 1][2];
    for (int[][] a : memo) for (int[] b : a) Arrays.fill(b, Integer.MIN_VALUE);
    return dp(prices, 0, k, 0, memo);
}
 
private static int dp(int[] prices, int day, int transLeft, int holding, int[][][] memo) {
    if (day == prices.length || transLeft == 0) return 0;
    if (memo[day][transLeft][holding] != Integer.MIN_VALUE) return memo[day][transLeft][holding];
 
    int doNothing = dp(prices, day + 1, transLeft, holding, memo);
    int doSomething;
    if (holding == 1) {
        // Sell: gain prices[day], transaction consumed
        doSomething = prices[day] + dp(prices, day + 1, transLeft - 1, 0, memo);
    } else {
        // Buy: pay prices[day]
        doSomething = -prices[day] + dp(prices, day + 1, transLeft, 1, memo);
    }
    return memo[day][transLeft][holding] = Math.max(doNothing, doSomething);
}
  • Time: O(n * k) — n * k * 2 states, each computed once
  • Space: O(n * k) memo + O(n) recursion stack
  • Tradeoff: Correct and readable for interviews. The recursion can hit stack limits for large n. Bottom-up DP avoids the stack and is typically what interviewers expect for the optimal solution.

Approach 2: Optimal — Bottom-up state-machine DP

// Time: O(n * k)  Space: O(k) rolling arrays
import java.util.*;
 
public static int maxProfitOptimal(int k, int[] prices) {
    int n = prices.length;
    if (n == 0 || k == 0) return 0;
 
    // If k >= n/2, we can make unlimited transactions (every profitable move)
    if (k >= n / 2) {
        int profit = 0;
        for (int i = 1; i < n; i++) profit += Math.max(0, prices[i] - prices[i - 1]);
        return profit;
    }
 
    // buy[j]  = max profit after at most j complete transactions, currently holding stock
    // sell[j] = max profit after at most j complete transactions, not holding stock
    int[] buy = new int[k + 1];
    int[] sell = new int[k + 1];
    Arrays.fill(buy, Integer.MIN_VALUE);  // can't hold stock we haven't bought
 
    for (int price : prices) {
        // Iterate transactions in reverse to avoid using the same day's update twice
        for (int j = k; j >= 1; j--) {
            // sell[j]: best of (keep sold state) vs (sell today from buy[j] state)
            sell[j] = Math.max(sell[j], buy[j] + price);
            // buy[j]:  best of (keep holding) vs (buy today from sell[j-1] state)
            buy[j]  = Math.max(buy[j],  sell[j - 1] - price);
        }
    }
    return sell[k];
}
  • Time: O(n * k) — outer loop over prices, inner loop over k transactions
  • Space: O(k) — only two arrays of size k+1 needed (rolling)
  • Key Insight: The state machine has two states per transaction count j: buy[j] (holding stock, having used at most j transactions so far) and sell[j] (not holding, having completed at most j transactions). The transition equations encode buy and sell decisions. The k >= n/2 short-circuit is critical for correctness at k = 10^9 — without it, allocating an array of size k+1 causes OOM. When k is large enough that we can transact every profitable day, this reduces to the unlimited-transactions greedy. The reverse iteration over j prevents a within-day “buy then sell” error (using the same day’s updated sell[j-1] to compute buy[j]).

Problem 4: My Calendar I (LC 729) — Medium

Link: LeetCode 729

Quick Summary: Implement a calendar that accepts book(start, end) requests. Return true if the event can be added without double-booking (no overlap with any existing event), false otherwise.

Industry Context: TurboTax appointment booking — tax advisors have calendars and clients book slots; no two client sessions can overlap. Also models fiscal year scheduling (a company’s fiscal year events must not overlap with blackout periods), and audit window management in QuickBooks (audit review windows for a client cannot overlap with data import windows). This problem tests depth of knowledge of Java’s TreeMap API — specifically floorKey and ceilingKey — which provides O(log n) booking vs. O(n) linear scan.

Approach 1: Brute Force — Linear scan of all booked events

// Time: book O(n)  Space: O(n)
import java.util.*;
 
class MyCalendarBrute {
    private final List<int[]> booked = new ArrayList<>();
 
    public boolean book(int start, int end) {
        for (int[] event : booked) {
            // Overlap condition: NOT (end <= event[0] || start >= event[1])
            if (end > event[0] && start < event[1]) return false;
        }
        booked.add(new int[]{start, end});
        return true;
    }
}
  • Time: O(n) per book call — scan all n existing events
  • Space: O(n) total for stored events
  • Tradeoff: Simple and correct. For a single user’s calendar with hundreds of events, O(n) per booking is fine. For Intuit at scale — millions of advisor calendars, thousands of bookings per second — this is too slow. O(log n) is required.

Approach 2: Optimal — TreeMap floorKey / ceilingKey

// Time: book O(log n)  Space: O(n)
import java.util.*;
 
class MyCalendarOptimal {
    // TreeMap: key = event start time, value = event end time
    // Invariant: no two stored events overlap
    private final TreeMap<Integer, Integer> calendar = new TreeMap<>();
 
    public boolean book(int start, int end) {
        // Find the closest event that starts BEFORE or AT 'start'
        Map.Entry<Integer, Integer> prev = calendar.floorEntry(start);
        // Find the closest event that starts AT or AFTER 'start'
        Map.Entry<Integer, Integer> next = calendar.ceilingEntry(start);
 
        // Check prev event: it overlaps if its END is after our START
        if (prev != null && prev.getValue() > start) return false;
        // Check next event: it overlaps if its START is before our END
        if (next != null && next.getKey() < end) return false;
 
        calendar.put(start, end);
        return true;
    }
}
  • Time: O(log n) per book — floorEntry and ceilingEntry are both O(log n) on a TreeMap (backed by a Red-Black Tree)
  • Space: O(n) for the TreeMap
  • Key Insight: The TreeMap keeps events sorted by start time. For a new event [start, end), there are only two events that could possibly overlap it: the nearest predecessor (closest start before start) and the nearest successor (closest start at or after start). All other events start either far before (and their end must be before start by the no-overlap invariant) or far after (and their start must be after end). So two O(log n) lookups — floorEntry and ceilingEntry — are sufficient. No iteration needed. This is the O(n) → O(log n) transformation interviewers are looking for. Know the full TreeMap API: floorKey, ceilingKey, floorEntry, ceilingEntry, lowerKey, higherKey. At Intuit, TreeMap appears naturally in versioned lookups (LC 981 is already in the repo using this API for time-based key-value store).

Problem 5: Maximum Difference Between Increasing Elements (LC 2016) — Easy-Medium

Link: LeetCode 2016

Quick Summary: Given an integer array nums, find the maximum value of nums[j] - nums[i] where i < j and nums[i] < nums[j]. Return -1 if no valid pair exists.

Industry Context: Investment return calculations in Intuit’s Mint and TurboTax — given a sequence of portfolio values over time, find the maximum gain from any buy-before-sell pair where the sell price strictly exceeds the buy price. P&L analysis in QuickBooks: find the maximum period-over-period improvement in a revenue sequence. Despite being the simplest stock problem (LC 121 variant with strict inequality), Intuit uses it specifically in financial contexts where the business framing enriches the solution discussion — candidates who explain the running-minimum intuition in financial terms (“track the lowest price seen so far as your cost basis”) stand out.

Approach 1: Brute Force — All pairs

// Time: O(n²)  Space: O(1)
public static int maximumDifferenceBrute(int[] nums) {
    int maxDiff = -1;
    for (int i = 0; i < nums.length; i++) {
        for (int j = i + 1; j < nums.length; j++) {
            if (nums[j] > nums[i]) {
                maxDiff = Math.max(maxDiff, nums[j] - nums[i]);
            }
        }
    }
    return maxDiff;
}
  • Time: O(n²) — check every pair (i, j) with i < j
  • Space: O(1)
  • Tradeoff: Correct and readable. Directly mirrors the problem statement. For small arrays (a single client’s annual transaction history — maybe 12 monthly snapshots) this is perfectly fine. For large arrays (daily portfolio values over decades) the O(n²) cost becomes a concern.

Approach 2: Optimal — Running minimum single-pass

// Time: O(n)  Space: O(1)
public static int maximumDifferenceOptimal(int[] nums) {
    int minSoFar = nums[0];   // lowest "buy price" seen to the left of current position
    int maxDiff = -1;
 
    for (int j = 1; j < nums.length; j++) {
        if (nums[j] > minSoFar) {
            // Valid pair: current value strictly exceeds our best buy price
            maxDiff = Math.max(maxDiff, nums[j] - minSoFar);
        } else {
            // Current value is a better (lower) buy price for future positions
            minSoFar = nums[j];
        }
    }
    return maxDiff;
}
  • Time: O(n) — single pass, constant work per element
  • Space: O(1) — only two variables
  • Key Insight: At each position j, the best possible profit using j as the “sell day” is nums[j] - min(nums[0..j-1]). Maintaining minSoFar as a running minimum accumulates this optimal buy price as we scan left to right. The strict inequality guard (nums[j] > minSoFar) is what makes this LC 2016 instead of LC 121 — equal values do not count as a valid pair, so we must not update maxDiff when nums[j] == minSoFar. In the financial context: the “cost basis” is tracked as the running minimum; we update the maximum realized gain each time we see a price strictly above cost basis. This pattern extends to LC 121 (remove the strict inequality for the standard stock problem) and the difference array / DP formulations in LC 122–188.

Financial Domain Connections

The table below maps algorithmic patterns to specific Intuit product contexts. Use this during system design rounds to anchor technical answers in business impact.

Algorithm / PatternIntuit Product Context
Merge Intervals (LC 56)TurboTax fiscal period consolidation — overlapping employment or deduction periods merged before tax calculation
Difference Array / Sweep Line (LC 1094)Intuit Payroll — concurrency sweep across overlapping pay periods; peak-load validation
k-Transaction DP State Machine (LC 188)TurboTax tax-loss harvesting advisor — k rebalancing events per year, maximize after-tax portfolio gain
TreeMap floorKey / ceilingKey (LC 729)TurboTax appointment scheduler, QuickBooks audit window manager — O(log n) non-overlap booking
Running Minimum Single-Pass (LC 2016)Mint portfolio P&L analysis, QuickBooks revenue trend analysis — maximum gain from any valid pair
Gas Station / Cash Flow (LC 134)QuickBooks cash flow forecasting — determine if a business survives a full operating cycle
Coin Change DP (LC 322)TurboTax deduction optimizer — fewest line items to reach a target deduction amount
Edit Distance (LC 72)TurboTax form reconciliation — minimum edits to align OCR-scanned form data with IRS schema
Time-Based Key-Value (LC 981)Tax rule versioning — retrieve which tax rule version was active on a given effective date
Course Schedule / Topo Sort (LC 207)Tax schedule dependency ordering — Schedule C must be completed before Form 1040 line 12

2-Week Sprint Plan

DayFocusProblems
1–2Interval foundationLC 253 (repo — Meeting Rooms II), LC 56 (this sheet — Merge Intervals)
3Sweep line / difference arrayLC 1094 (this sheet — Car Pooling)
4–5DP foundationLC 198 (repo — House Robber), LC 322 (repo — Coin Change)
6–7DP stock seriesLC 188 (this sheet — Stock IV); review LC 121→122→123 progression first
8TreeMap and schedulingLC 981 (repo — Time-Based KV), LC 729 (this sheet — My Calendar I)
9Financial P&LLC 2016 (this sheet — Max Difference); connect to LC 121
10Graph / dependency orderingLC 207 (repo — Course Schedule)
11–12Mock interview — 2 problems in 45 minPick 1 DP + 1 interval/greedy
13–14System design deep diveFinancial data pipeline idempotency; versioned tax rule lookup; TurboTax form dependency DAG

Senior-Level Talking Points

These are the answers that separate a senior candidate from a mid-level candidate at Intuit:

  • Financial accuracy first: In every problem, explicitly state what happens with edge cases that have financial impact — negative values (losses, negative deductions), zero transactions (a no-op that must be handled gracefully), overlapping fiscal periods (must merge before processing, never double-count). Interviewers will note whether you surface these without being prompted.
  • Idempotency in transaction processing: Payment and payroll systems must be idempotent — processing the same payroll event twice should produce the same result, not double-pay. When designing any write path, discuss deduplication keys (idempotency keys), exactly-once semantics, and how you’d detect and reject duplicate submissions.
  • Correctness over performance: Intuit explicitly prioritizes a correct-but-slower solution over a fast-but-potentially-incorrect one. An incorrect tax calculation can cause IRS penalties. When given a choice, state this tradeoff explicitly: “I’d rather be 10x slower and correct than fast and occasionally wrong.” Interviewers reward this framing.
  • Versioned data and effective dates: Tax rules change year over year. Any system storing financial rules must support point-in-time queries (“what was the capital gains rate on 2022-04-01?”). Connect this to (Time-Based KV) and binary search on sorted timestamps. This signals maturity with append-only, audit-friendly data models.
  • Strict vs. non-strict inequality matters: In financial calculations, the difference between > and >= can be the difference between a valid deduction and fraud. Always clarify interval semantics (open vs. closed endpoints) before coding. Point out in LC 2016 that nums[j] > minSoFar (not >=) reflects a strict “you must gain to count it as a realized profit” business rule.
  • Overflow in financial arithmetic: Money amounts in cents multiplied across large transaction counts can overflow int. Default to long for any financial accumulation, and mention this upfront. In Java: int overflows at ~2.1 billion (about $21M if in cents), which is a realistic figure for enterprise QuickBooks clients.
  • Difference array technique: The sweep line / difference array pattern (LC 1094) is underrepresented in standard prep but appears naturally in Intuit’s payroll and scheduling domains. Being the candidate who reaches for it immediately — rather than the O(range) simulation — is a strong senior signal.

Graph View