Problem recap

You’re given an integer array nums and an integer k.
Return the number of contiguous subarrays whose sum is exactly k.

Example

• nums = [1, 2, 3, -2, 5], k = 3

There are 2 valid subarrays: [1, 2], [3].

Approach 1: Brute force, but with a running sum

The naïve approach is “all subarrays, sum each,” which is O(n^3), but you can upgrade that to O(n^2) by carrying a running sum inside the inner loop.

• Fix a start index i.

• Walk j from i to the end, maintaining current_sum += nums[j].

• Each time current_sum == k, increment a counter.

from typing import List

def subarray_sum_bruteforce(nums: List[int], k: int) -> int:
    count = 0
    n = len(nums)
    for i in range(n):
        current_sum = 0
        for j in range(i, n):
            current_sum += nums[j]
            if current_sum == k:
                count += 1
    return count

public int subarraySumBruteForce(int[] nums, int k) {
    int count = 0;
    for (int i = 0; i < nums.length; i++) {
        int currentSum = 0;
        for (int j = i; j < nums.length; j++) {
            currentSum += nums[j];
            if (currentSum == k) {
                count++;
            }
        }
    }
    return count;
}

Talking points:

• Time: O(n^2), space: O(1).

• Works fine with negatives because it does not rely on any ordering property.

Before reading on, can you think of a way to reuse some of this work to get to linear time?

Approach 2: The “expanding–shrinking window” that breaks with negatives

This is the most common incorrect approach.

The sliding window with two pointers works when all numbers are non‑negative:

• Keep start, end, and current_sum over nums[start:end).

• Expand end while current_sum < k.

• Shrink from start while current_sum > k.

• Check for current_sum == k along the way.

This relies critically on the fact that when all numbers are non‑negative:

• Increasing the window (move end right) never decreases the sum.

• Decreasing the window (move start right) never increases the sum.

So you never “miss” a candidate by shrinking or expanding.

Here’s an “only works when all elements are non‑negative” cautionary example:

// WARNING: Only correct if all nums[i] >= 0
public int subarraySumSlidingWindowNonNegative(int[] nums, int k) {
    int start = 0, currentSum = 0, count = 0;

    for (int end = 0; end < nums.length; end++) {
        currentSum += nums[end];

        while (start <= end && currentSum > k) {
            currentSum -= nums[start++];
        }

        if (currentSum == k) {
            count++;
        }
    }
    return count;
}

Why this fails with negatives

Give a concrete counterexample:

• nums = [3, 4, -2], k = 5.

Correct subarray is [3, 4, -2]. The window algorithm may shrink too early when current_sum > k, but the later negative value could have brought it back down to k.

Once you discard elements from the left, you cannot recover that subarray. The key invariant “sum only moves in one direction when expanding or shrinking” is broken by negative numbers.

General rule:

• Any time your algorithm decides ‘I can safely skip all longer windows starting here because the sum is already too big/small,’ it assumes monotonicity. Negatives destroy that.

If sliding window doesn’t work with negatives, what property must the real solution exploit instead?

Approach 3: Prefix sums + hash map (the correct O(n) running-sum solution)

Approach 1 is not wrong, just suboptimal.

You’ve discovered one kind of running sum. The final step is to recognize that you don’t actually need to restart the sum at every i. You can reuse the same running prefix sum for all i simultaneously if you store counts in a map.

• Let prefix[i] be the sum of nums[0..i].

• The sum of subarray nums[l..r] is prefix[r] - prefix[l-1].

• For a subarray ending at index i to have sum k, you need some earlier prefix sum prefix[j] such that:

So as you scan from left to right while maintaining a running prefix sum, you only need to know:

• How many times have you seen the value currentSum - k before?

That count equals the number of subarrays ending at the current index whose sum is k.

This works with negative numbers, positive numbers, and any mix, because it does not rely on monotonicity, only on the algebraic relationship between prefix sums.

Key implementation detail:

• Initialize the map with sum_frequency[0] = 1 so that when currentSum == k, you correctly count subarrays starting at index 0.

Canonical solutions

You can walk through nums = [1, 2, 3, -2, 5], k = 3 step‑by‑step with any of the following solutions to build intuition.

from typing import List
from collections import defaultdict

def subarray_sum(nums: List[int], k: int) -> int:
    freq = defaultdict(int)
    freq[0] = 1  # empty prefix

    current_sum = 0
    count = 0

    for x in nums:
        current_sum += x

        # number of previous prefixes we can pair with current_sum to get k
        need = current_sum - k
        count += freq[need]

        # record current prefix sum for future elements
        freq[current_sum] += 1

    return count 

Java

import java.util.HashMap;
import java.util.Map;

public int subarraySum(int[] nums, int k) {
    Map<Integer, Integer> freq = new HashMap<>();
    freq.put(0, 1);  // empty prefix

    int currentSum = 0;
    int count = 0;

    for (int x : nums) {
        currentSum += x;

        int need = currentSum - k;
        count += freq.getOrDefault(need, 0);

        freq.put(currentSum, freq.getOrDefault(currentSum, 0) + 1);
    }

    return count;
}

C#

using System.Collections.Generic;

public int SubarraySum(int[] nums, int k) {
    var freq = new Dictionary<int, int>();
    freq[0] = 1;  // empty prefix

    int currentSum = 0;
    int count = 0;

    foreach (int x in nums) {
        currentSum += x;

        int need = currentSum - k;
        if (freq.TryGetValue(need, out int occ)) {
            count += occ;
        }

        if (freq.ContainsKey(currentSum)) {
            freq[currentSum]++;
        } else {
            freq[currentSum] = 1;
        }
    }

    return count;
}

TypeScript

export function subarraySum(nums: number[], k: number): number {
    const freq = new Map<number, number>();
    freq.set(0, 1);  // empty prefix

    let currentSum = 0;
    let count = 0;

    for (const x of nums) {
        currentSum += x;

        const need = currentSum - k;
        if (freq.has(need)) {
            count += freq.get(need)!;
        }

        freq.set(currentSum, (freq.get(currentSum) ?? 0) + 1);
    }

    return count;
} 

Complexity talking point: one pass, constant-time hash operations → O(n) time, O(n) space in the worst case.

“Running sum” vs “running window”

• “Running sum” just means you keep a cumulative total as you iterate; both the O(n^2) brute force and the O(n) prefix-sum+map use a running sum.

• The flawed pattern is not “running sum,” it is “sliding window that assumes ‘if my sum is already too big/small, I can discard this start index forever’.”

Other common reader mistakes

Using a set instead of counting frequencies

Some people get to the prefix-sum idea but stop at “I just need to know if currentSum - k exists in some set of previous sums.” That only tells you whether at least one subarray ending here sums to k.

But this problem asks for the count of subarrays. There may be multiple previous indices j1, j2, … with the same prefix sum currentSum - k, and each corresponds to a distinct subarray ending at the current index.

So a common bug is:

seen = set()
seen.add(0)
current_sum = 0
count = 0
for x in nums:
    current_sum += x
    if current_sum - k in seen:
        count += 1          # BUG: only adds 1 even if there are multiple matches
    seen.add(current_sum)

The fix is to store frequencies and add freq[currentSum - k] rather than just 1.

Forgetting to seed sum 0 in the map

Any correct prefix-sum + hash‑map solution needs:

freq = {0: 1}  # or equivalent in Java/C#/TS

right before the loop.

A subtle, off‑by‑one‑ish bug: initialize an empty map and only start recording prefix sums inside the loop.

What goes wrong:

• Consider subarrays that start at index 0.

• For such a subarray ending at index i, you have prefix[i] == k.

• In the map logic, you’re looking for prefix[i] - k == 0.

• If you never seeded sum_frequency[0] = 1, you’ll miss those subarrays entirely.

© The Coding Interview Gym | paulepps.substack.com

Problem recap

Interview question
Given a string s, return the length of the longest substring without repeating characters.

Examples:

• s = "abcabcbb" → 3 (answer is "abc")

• s = "bbbbb" → 1 (answer is "b")

• s = "pwwkew" → 3 (answer is "wke")

Constraints typically look like:

• 1 <= s.length <= 5 * 10^4

• Characters are usually standard ASCII; LeetCode’s version allows spaces, punctuation, etc.

Baseline idea: sliding window over a string

Naive thinking says: enumerate all substrings and check them one by one. That’s O(n^2) substrings and O(n) to check each, which is dead on arrival.

Instead, this problem is a textbook variable-size sliding window:

• Maintain a window [left, right] that always has no duplicates.

• Expand right one character at a time.

• If the new character makes the window invalid (duplicate), move left forward until the window is valid again.

• Track the best window length seen so far.

All of the implementations below share this same mental model; they only differ in how they detect and fix duplicates (array vs. hash map vs. set).

Approach 1: Hash map frequency (clean, general-purpose)

This is the version I’d expect a strong candidate to reach first in an interview: use a hash map from character → count to track what’s inside the window.

Python (hash map)

def length_of_longest_substring(s: str) -> int:
    freq = {}          # char -> count in current window
    left = 0
    best = 0

    for right, ch in enumerate(s):
        freq[ch] = freq.get(ch, 0) + 1

        # If ch is now duplicated, shrink from the left
        while freq[ch] > 1:
            left_ch = s[left]
            freq[left_ch] -= 1
            if freq[left_ch] == 0:
                del freq[left_ch]
            left += 1

        best = max(best, right - left + 1)

    return best

Java (hash map)

public int lengthOfLongestSubstring(String s) {
    Map<Character, Integer> freq = new HashMap<>();
    int left = 0;
    int best = 0;

    for (int right = 0; right < s.length(); right++) {
        char c = s.charAt(right);
        freq.put(c, freq.getOrDefault(c, 0) + 1);

        while (freq.get(c) > 1) {
            char leftChar = s.charAt(left);
            freq.put(leftChar, freq.get(leftChar) - 1);
            if (freq.get(leftChar) == 0) {
                freq.remove(leftChar);
            }
            left++;
        }

        best = Math.max(best, right - left + 1);
    }

    return best;
}

C# (dictionary)

public int LengthOfLongestSubstring(string s) {
    var freq = new Dictionary<char, int>();
    int left = 0;
    int best = 0;

    for (int right = 0; right < s.Length; right++) {
        char c = s[right];
        freq[c] = freq.GetValueOrDefault(c) + 1;

        while (freq[c] > 1) {
            char leftChar = s[left];
            freq[leftChar]--;
            if (freq[leftChar] == 0) {
                freq.Remove(leftChar);
            }
            left++;
        }

        best = Math.Max(best, right - left + 1);
    }

    return best;
}

Complexity

• Time: O(n), each character enters and leaves the window at most once.

• Space: O(k) where k is the number of distinct characters in the window, k≤128 for ASCII.

When this shines

• You want a generic sliding window template that adapts to “at most K occurrences”, “at most K distinct characters”, etc.

• You’re not sure about the character set (could be Unicode, emojis, etc.).

Approach 2: Hash set + left pointer (simpler state)

If all you care about is “no duplicates at all”, you don’t actually need counts—just membership. A hash set stores the characters in the current window.

Python (set)

def length_of_longest_substring_set(s: str) -> int:
    seen = set()
    left = 0
    best = 0

    for right, ch in enumerate(s):
        # If ch is already in the window, move left until it's gone
        while ch in seen:
            seen.remove(s[left])
            left += 1

        seen.add(ch)
        best = max(best, right - left + 1)

    return best

Java (HashSet)

public int lengthOfLongestSubstringSet(String s) {
    Set<Character> seen = new HashSet<>();
    int left = 0;
    int best = 0;

    for (int right = 0; right < s.length(); right++) {
        char c = s.charAt(right);

        while (seen.contains(c)) {
            seen.remove(s.charAt(left));
            left++;
        }

        seen.add(c);
        best = Math.max(best, right - left + 1);
    }

    return best;
}

C# (HashSet)

public int LengthOfLongestSubstringSet(string s) {
    var seen = new HashSet<char>();
    int left = 0;
    int best = 0;

    for (int right = 0; right < s.Length; right++) {
        char c = s[right];

        while (seen.Contains(c)) {
            seen.Remove(s[left]);
            left++;
        }

        seen.Add(c);
        best = Math.Max(best, right - left + 1);
    }

    return best;
}

Complexity

• Time: O(n) average with set operations expected O(1).

• Space: O(k) distinct characters, like the map approach.

When this shines

• You want the simplest readable solution for this specific problem.

• You don’t need frequency counts or more complex constraints.

Approach 3: Character index array (true O(1) space for ASCII)

In many LeetCode-style constraints, the input is restricted to ASCII. When that’s true, you can trade generality for a flat array indexed by character code, which removes hashing overhead and pins space to a constant.

Two common patterns:

1. Last-seen index: lastIndex[c] = last index where c appeared, or -1 if never.

2. Frequency array: Like the map-based sliding window, but with an array of length 128.

I like the last-seen-index version because it eliminates the inner while loop and keeps the window valid by jumping left forward in one step.

Python (last-seen index, ASCII)

def length_of_longest_substring_ascii(s: str) -> int:
    # 128 for standard ASCII; use 256 or 256k if needed
    last_index = [-1] * 128

    left = 0
    best = 0

    for right, ch in enumerate(s):
        code = ord(ch)

        # If we've seen this char inside the current window, move left
        if last_index[code] >= left:
            left = last_index[code] + 1

        last_index[code] = right
        best = max(best, right - left + 1)

    return best

Java (last-seen index, ASCII)

public int lengthOfLongestSubstringAscii(String s) {
    int[] lastIndex = new int[128];
    Arrays.fill(lastIndex, -1);

    int left = 0;
    int best = 0;

    for (int right = 0; right < s.length(); right++) {
        char c = s.charAt(right);
        int code = (int) c;

        if (lastIndex[code] >= left) {
            left = lastIndex[code] + 1;
        }

        lastIndex[code] = right;
        best = Math.max(best, right - left + 1);
    }

    return best;
}

C# (last-seen index, ASCII)

public int LengthOfLongestSubstringAscii(string s) {
    int[] lastIndex = new int[128];
    Array.Fill(lastIndex, -1);

    int left = 0;
    int best = 0;

    for (int right = 0; right < s.Length; right++) {
        char c = s[right];
        int code = (int)c;

        if (lastIndex[code] >= left) {
            left = lastIndex[code] + 1;
        }

        lastIndex[code] = right;
        best = Math.Max(best, right - left + 1);
    }

    return best;
}

Complexity

• Time: O(n).

• Space:

  • Array length is fixed (e.g., 128), so strictly O(1) with respect to input size.

When this shines

• You’re in a tight performance setting (competitive programming, very large number of test cases, strict limits).

• The interviewer has explicitly restricted the alphabet to ASCII or to a small known set.

Comparison: map vs. set vs. array

Here’s how these approaches stack up from an interviewer’s point of view.

Here k is the number of distinct characters, which is bounded by 128 for ASCII but may be larger in Unicode scenarios.

When does “O(1) space” actually matter here?

On paper, all three are “O(n) time, O(1)/O(k) space”, and it’s tempting to optimize preemptively. In actual interviews, I’d bucket it like this:takeuforward+3

1. Most interviews

   • The map or set solution is completely fine.

   • The real evaluation is about:

     • Recognizing the sliding window pattern.

     • Managing indices and invariants cleanly.

     • Explaining why the algorithm is O(n) (each char enters/leaves the window at most once).

2. Performance-obsessed interviewers / follow-up questions

   • They may ask: “Can you do it in O(1) space?”

   • That’s your cue to say:

     • “If we can assume the input is ASCII, we can replace the map with a fixed-size array indexed by character code, which makes the additional space independent of n.”

   • Dropping that shows you can connect constraints to implementation choices.

3. When not to over-optimize

   • If your first attempt with the array is buggy or hard to explain, it’s worse than a clean map-based solution.

   • Most production environments don’t care about the tiny constant-factor improvement here unless you’re processing giant logs in a tight loop.

A good rule you can even say out loud: “I’ll start with the hash map version for clarity, and if we need to squeeze constants or space, we can switch to a fixed-size array given ASCII constraints.”

Paid-only add-on: How interviewers really grade this problem

Read more

Two Sum

View original challenge

Two Sum is the problem interviewers use when they want to see how you think. It looks deceptively simple, but the details separating a clean solution from a buggy one are exactly what senior engineers notice. Today we go beyond the basic answer: one-pass hash map, off-by-one errors and hash collision edge cases.

The One-Pass Hash Map Solution

Most explanations teach a two-pass approach: first scan the array to populate a map, then scan again to find complements. You don’t need two passes. You can build the map and check for complements simultaneously in a single traversal.

The insight: when you reach index i, every element before it has already been added to the map. So if the complement of nums[i] is already in the map, you’ve found your pair. No second pass needed.

TypeScript

function twoSum(nums: number[], target: number): number[] {
  const indexByValue = new Map<number, number>();

  for (let i = 0; i < nums.length; i++) {
    const complement = target - nums[i];

    if (indexByValue.has(complement)) {
      return [indexByValue.get(complement)!, i];
    }

    indexByValue.set(nums[i], i); // store AFTER checking — crucial
  }
}

C#

public class Solution {
    public int[] TwoSum(int[] nums, int target) {
        var indexByValue = new Dictionary<int, int>(); // value -> index

        for (int i = 0; i < nums.length; i++) {
            int complement = target - nums[i];

            if (indexByValue.TryGetValue(complement, out int complementIndex)) {
                return new int[] { complementIndex, i };
            }

            indexByValue[nums[i]] = i; // store AFTER the check
        }
    }
}

Java

import java.util.HashMap;
import java.util.Map;

class Solution {
    public int[] twoSum(int[] nums, int target) {
        Map<Integer, Integer> indexByValue = new HashMap<>();

        for (int i = 0; i < nums.length; i++) {
            int complement = target - nums[i];

            if (indexByValue.containsKey(complement)) {
                return new int[]{ indexByValue.get(complement), i };
            }

            indexByValue.put(nums[i], i); // store AFTER checking
        }
    }
}

Notice the comment on that last line in each snippet: "store AFTER checking." That single ordering decision is where most one-pass bugs are born, and it connects directly to our next section.

Common Off-by-One and Ordering Errors

“Off-by-one” usually makes people think of loop bounds. In Two Sum, the trickier errors are about when you write to the map relative to when you read from it. Here are the two that I saw most often.

Error 1: Storing before checking (same-element reuse)

// BUGGY — stores num[i] before looking for its complement
for (int i = 0; i < nums.length; i++) {
    indexByValue.put(nums[i], i);        // ← stored first

    int complement = target - nums[i];
    if (indexByValue.containsKey(complement)) {
        return new int[]{ indexByValue.get(complement), i };
    }
}

If target = 6 and nums[i] = 3, you store 3 → i, then immediately ask "is 3 in the map?" And find the element you just stored. The problem says you cannot use the same element twice. Storing first breaks that constraint for self-complementary values.

Fix: always check before storing, as shown in the correct solutions above.

Error 2: Off-by-one in loop bounds

// BUGGY — misses the last element
for (let i = 0; i < nums.length - 1; i++) {

This is the classic off-by-one. Subtracting 1 from the upper bound seems harmless — you might reason “I need at least two elements left.” But in a one-pass hash map approach, you only need the current element and whatever is already in the map. The final element could be the one whose complement is already stored.

Fix: iterate to nums.length (TypeScript/Java) or nums.Length (C#), inclusive of the last index.

Hash Collision Edge Cases

This is the section almost nobody covers in Two Sum posts, and it’s the kind of depth that impresses a senior interviewer.

What is a hash collision?

A hash collision happens when two different keys produce the same hash code, causing them to land in the same underlying bucket. All major hash map implementations handle this with either chaining (linked list of entries per bucket) or open addressing (probe for the next empty slot).

In average-case analysis, lookup is O(1). In the worst case, if every key collides into the same bucket, lookup degrades to O(n), turning your elegant O(n) Two Sum into an accidental O(n²).

Does this matter in practice for Two Sum?

For most real inputs: no. Java’s HashMap, C#’s Dictionary, and JavaScript’s Map all use robust hash functions for integers that distribute keys well. But here’s when it does matter:

1. Adversarial inputs in competitive programming

Some judges are designed to generate inputs that maximize collisions for HashMap in Java specifically. The fix is to use a randomized hash function or switch to a TreeMap (which uses a balanced BST and gives O(log n) guaranteed lookup, at the cost of O(n log n) total time).

// Java: TreeMap gives O(log n) guaranteed lookup, no collision risk
import java.util.TreeMap;

Map<Integer, Integer> indexByValue = new TreeMap<>();

2. Integer overflow when computing the complement

Not a hash collision, but a closely related “edge case nobody mentions”:

// nums[i] = Integer.MAX_VALUE = 2,147,483,647
// target   = 0
int complement = target - nums[i]; // = -2,147,483,647 ✓ fine here

// But: target = Integer.MIN_VALUE, nums[i] = 1
int complement = target - nums[i]; // overflows in Java/C# (int arithmetic)

In Java and C#, int arithmetic wraps silently. The fix is to use long for the complement calculation when inputs can be large:

long complement = (long)target - nums[i];

Mentioning this in an interview separates you from candidates who only think about the algorithm and not the data.

Putting It Together: What “Production-Ready” Looks Like

Here’s a C# version that integrates all the guards discussed above:

public class Solution {
    public int[] TwoSum(int[] nums, int target) {
        if (nums == null || nums.Length < 2)
            throw new ArgumentException("Input must contain at least two elements.");

        var indexByValue = new Dictionary<int, int>(nums.Length); // pre-size the dict

        for (int i = 0; i < nums.Length; i++) {
            long complement = (long)target - nums[i]; // guard against overflow

            // complement must fit in int range to be a valid array value
            if (complement >= int.MinValue && complement <= int.MaxValue
                && indexByValue.TryGetValue((int)complement, out int complementIndex)) {
                return new int[] { complementIndex, i };
            }

            indexByValue[nums[i]] = i; // store AFTER checking
        }

        throw new InvalidOperationException("No solution found.");
    }
}

Notice three upgrades from the interview version:

• nums.Length passed to the Dictionary constructor pre-allocates capacity and avoids resize operations.

• long arithmetic guards against integer overflow on the complement.

• Exceptions instead of empty returns give the caller meaningful error signals. (Yes, the challenge guaranteed a unique solution, but that’s not always the case.

Reviewing a Python Solution

A full reader submission:

class Found(Exception): pass
def makesum (target: int, nums: list[int]) :
  try:
    for i in range (len(nums)):
      for j in range (i+1,len(nums)):
        if nums[i]+nums[j] == target :
          raise Found
  except Found :
    return i,j
  return None,None #not reachable as there IS a solution
target = 27
nums = [2,7,11,15,16]
i,j = makesum(target,nums)
print(f"[{i},{j}]")

It works for the given input, but it’s not a good style or interview-quality solution.

What’s good

• Correct brute-force logic: you check all (i, j) with j > i and return the first pair whose sum hits the target, which is the standard O(n^2) approach.

• Clear intent: once a pair is found, you stop searching, so you don’t do unnecessary extra work.

Main issues

• Misuse of exceptions for control flow

  • Using raise Found / except Found just to break out of nested loops is considered unpythonic and harder to read than a simple flag or an extracted helper function.

  • It also makes i and j look “magic”: they are set in the loop, but returned from inside the except block, which depends on subtle scoping rules rather than explicit data flow.

• Incorrect comment about reachability

  • The comment #not reachable as there IS a solution encodes a guarantee into the function rather than its caller.

  • In a real codebase, the function should either:

    • Explicitly document “assumes a solution exists”, or

    • Handle the no-solution case gracefully (e.g., return None or raise a meaningful error).

• Type hints and interface

  • Return type is effectively tuple[int, int] | tuple[None, None] but isn’t annotated.

  • For code clarity, you might either:

    • Annotate def makesum(...) -> tuple[int, int] | None: and return None, or

    • If you truly assume a solution exists, document that in the docstring and not return the (None, None) sentinel.

• Naming and style

  • makesum is vague; something like two_sum_indices or find_two_sum is clearer.

  • PEP 8: spaces after function name before parentheses and around arguments are unusual (def makesum (target: int, nums: list[int]) :).

  • A small thing, but interviewers often care about these details.

How to write a similar brute-force

Here’s a direct, readable O(n^2) brute-force version that keeps the nested-loop idea, without exceptions:

from typing import Optional, Tuple

def two_sum_bruteforce(target: int, nums: list[int]) -> Optional[Tuple[int, int]]:
    for i in range(len(nums)):
        for j in range(i + 1, len(nums)):
            if nums[i] + nums[j] == target:
                return i, j
    return None

Usage:

target = 27
nums = [2, 7, 11, 15, 16]
result = two_sum_bruteforce(target, nums)

if result is not None:
    i, j = result
    print(f"[{i},{j}]")
else:
    print("No solution found")

For interviews: show the hash map version

Most interviewers expect you to move from this brute-force to an O(n) hash-map solution.

from typing import Optional, Tuple

def two_sum(target: int, nums: list[int]) -> Optional[Tuple[int, int]]:
    index_by_value: dict[int, int] = {}
    for i, num in enumerate(nums):
        complement = target - num
        if complement in index_by_value:
            return index_by_value[complement], i
        index_by_value[num] = i
    return None

What to Say in an Interview

Here’s the arc that lands well:

1. Restate the constraints — can we use the same element twice? Exactly one solution?

2. Offer the brute force — O(n²) time, O(1) space, nested loops.

3. Identify the bottleneck — “We recompute the complement search from scratch every iteration.”

4. Propose the hash map — “We can cache what we’ve seen for O(1) lookup.”

5. Do it in one pass — explain the store-after-check ordering.

6. Name the tradeoffs — O(n) space, amortized O(1) per operation, worst-case collision behavior.

7. Handle edge cases unprompted — duplicate values, integer overflow, self-complementary elements.

That arc shows algorithmic thinking, communication skills, and engineering maturity, all in one problem.

Up Next: Sliding Window

Two Sum teaches you to remember what you’ve seen using a hash map. The next pattern takes that idea further: what if instead of a single pair, you need to track a whole subarray as it moves through your data?

That’s Sliding Window, and it shows up everywhere: longest substring without repeating characters, maximum sum subarray of size k, minimum window substring, and more. It’s one of the highest-leverage patterns for medium and hard interview problems, and it’s more nuanced than most posts let on.

Next week’s deep-dive (Wednesday for paid subscribers) will cover fixed-window vs. variable-window variants, when to shrink from the left vs. expand from the right, and the exact questions that trip up candidates who think they understand it.

Subscribe so you don’t miss it.

Found this useful? Share it with someone grinding LeetCode right now — they’ll thank you later.

© The Coding Interview Gym | paulepps.substack.com

If you’ve been prepping for interviews, you’ve probably seen Coin Change. It’s on almost every FAANG short list, and for good reason: it’s deceptively simple to state, easy to solve naively, and a perfect vehicle for understanding the full arc from brute-force recursion → memoization → tabulation.

Let’s walk through the whole thing.

The Problem

Given an array of coins[] of size n and a target value sum, where coins[i] represent the coins of different denominations. You have an infinite supply of each of the coins. The task is to find the minimum number of coins required to make the given value sum. If it is not possible to form the sum using the given coins, return -1.---

Why Greedy Fails Here

Before writing a single line of DP, let’s address why Greedy is not good here.

For [1, 5, 10, 25] and amount 30, greedy works: take the largest coin that fits (25), then take 5. Two coins. Correct.

For [1, 3, 4] and amount 6, greedy fails: it takes 4, then two 1s = three coins. But the optimal answer is two 3s = two coins.

For [1, 20, 25] and amount 40, greedy fails hard: it takes 25, then can’t make 15 with {20, 25}, so falls back to fifteen 1s = sixteen coins. The optimal is two 20s = two coins.

Greedy works for canonical currency systems. The moment denominations are arbitrary, you need DP.

Approach 1: Naive Recursion

The cleanest way to see the subproblem structure is top-down recursion with no optimization.

Recurrence:

For each coin c, try it if c <= amount, and recurse on amount - c. Take the minimum across all choices.

(I’m using Python for all of this week’s code samples because it’s easier to see the progression from recursion → memoization → tabulation with the same language.)

def coin_change_naive(coins: list[int], amount: int) -> int:

    def dp(remaining: int) -> int:

        # Base cases

        if remaining == 0:

            return 0

        if remaining < 0:

            return float(’inf’)

        # Try every coin and take the minimum

        min_coins = float(’inf’)

        for coin in coins:

            result = dp(remaining - coin)

            if result != float(’inf’):

                min_coins = min(min_coins, result + 1)

        return min_coins

    result = dp(amount)

    return result if result != float(’inf’) else -1

Time complexity: Exponential. O(amount^len(coins)). Each call branches into len(coins) subproblems.

Space complexity: O(amount) for the recursion call stack.

Why this is painful: dp(11) will compute dp(10), dp(6), and dp(1) multiple times each. Redundant work piles up fast. For amount = 100 with four denominations, you’ll see millions of calls.

Approach 2: Top-Down DP (Memoization)

The fix is straightforward: cache the result of each subproblem so you never recompute it.

def coin_change_memo(coins: list[int], amount: int) -> int:

    memo = {}

    def dp(remaining: int) -> int:

        # Check cache first

        if remaining in memo:

            return memo[remaining]

        # Base cases

        if remaining == 0:

            return 0

        if remaining < 0:

            return float(’inf’)

        # Try every coin and take the minimum

        min_coins = float(’inf’)

        for coin in coins:

            result = dp(remaining - coin)

            if result != float(’inf’):

                min_coins = min(min_coins, result + 1)

        memo[remaining] = min_coins

        return min_coins

    result = dp(amount)

    return result if result != float(’inf’) else -1

Time complexity: O(amount × len(coins)). Each unique remaining value is computed once, and each computation tries all coins.

Space complexity: O(amount) for the memo table + O(amount) for the call stack = O(amount).

Each entry in the memo table maps a remaining amount to the minimum coins needed. The call stack for dp(11) now only recurses deep once per unique value.

One risk: For very large amount values, Python’s default recursion limit (~1000) can cause a stack overflow. Workaround: sys.setrecursionlimit(amount + 10), or just use tabulation.

Approach 3: Bottom-Up DP (Tabulation)

Instead of recursing top-down and caching, build the answer iteratively from amount = 0 upward.

Key insight: dp[i] = minimum coins to make amount i. Fill the table in order from 0 to amount.

def coin_change_tab(coins: list[int], amount: int) -> int:

    # Initialize table with amount+1 as a sentinel for “impossible”

    # (You can never need more than `amount` coins of denomination 1)

    dp = [amount + 1] * (amount + 1)

    dp[0] = 0  # Base case: 0 coins needed to make amount 0

    for i in range(1, amount + 1):

        for coin in coins:

            if coin <= i:

                dp[i] = min(dp[i], dp[i - coin] + 1)

    return dp[amount] if dp[amount] != amount + 1 else -1

Time complexity: O(amount × len(coins)). Two nested loops.

Space complexity: O(amount) = single 1D array. No call stack overhead.

Complexity Summary

For this problem, tabulation and memoization have identical asymptotic complexity. Tabulation wins in practice for large amount due to no call stack overhead and better cache locality.

Test Cases

def run_tests():

    fn = coin_change_tab  # swap in any implementation

    # Standard cases

    assert fn([1, 5, 10, 25], 11)  == 2   # 10 + 1

    assert fn([1, 5, 10, 25], 30)  == 2   # 25 + 5

    assert fn([1, 5, 10, 25], 0)   == 0   # base case

    assert fn([1, 5, 10, 25], 1)   == 1   # single coin

    assert fn([1, 5, 10, 25], 25)  == 1   # exact denomination

    # Non-canonical denominations (greedy fails)

    assert fn([1, 3, 4], 6)        == 2   # 3 + 3, not 4+1+1

    assert fn([1, 20, 25], 40)     == 2   # 20 + 20, not 25+15x1

    # Impossible case

    assert fn([2], 3)              == -1  # can’t make odd amount with only 2s

    # Large amount

    assert fn([1, 5, 10, 25], 100) == 4   # 25 * 4

    print(”All tests passed.”)

run_tests()

Common Pitfalls

1. Confusing bounded vs. unbounded knapsack

Coin Change is an unbounded problem. You can reuse each denomination any number of times.

Compare with the 0/1 knapsack variant: each coin can only be used once. The iteration order and table structure change significantly.

In the bounded version, you’d typically iterate over items (coins) in the outer loop and amounts in the inner loop, maintaining a 2D table to track whether each item has been used. In the unbounded version (this problem), you iterate amounts in the outer loop and can reference the same row freely.

Interview red flag: Using a 2D table when a 1D table suffices. For unbounded coin change, the 1D bottom-up solution is correct and optimal.

2. Not handling the base case dp[0] = 0

If dp[0] is not explicitly set to 0, the entire table builds on a wrong foundation. Every subsequent entry will be off by one at minimum.

When to Use Each Approach

Use naive recursion only to sketch the recurrence relation and confirm your base cases before optimizing. Never submit it.

Use memoization (top-down) when:

• The recurrence is complex and writing it recursively is more natural than iteratively

• You only need to compute a subset of subproblems (sparse access pattern)

• You’re prototyping and want the recursive structure visible for code review

Use tabulation (bottom-up) when:

• You need all subproblems (dense access pattern, as in Coin Change)

• Stack depth is a concern

• You want the most cache-friendly, predictable memory behavior

• You’re in a systems language where recursion overhead matters

In practice, for most 1D DP interview problems (Coin Change, House Robber, Climbing Stairs), tabulation is the preferred answer unless the problem has a sparse subproblem graph.

If this was useful, forward it to an engineer who’s prepping. Each referral keeps the Gym running.

© The Coding Interview Gym | paulepps.substack.com

Reading time: ~8 minutes | Part of The Coding Interview Gym’s behavioral interview series

Every FAANG interviewer has a version of the same story.

A candidate walks in with a sky-high LeetCode streak, a polished resume, and strong momentum from the coding rounds. Then comes the behavioral interview. Forty-five minutes later, the candidate walks out — no offer.

Not because they couldn’t code. Not because they lacked experience. But because they made one (or more) of three completely fixable mistakes.

I’ve studied interviewer debrief patterns, analyzed feedback from real hiring loops, and coached engineers through these exact pitfalls. What follows are three composite stories, each one recognizable to any engineer who’s ever gone through a FAANG loop.

The good news: every blunder has a clean fix you can practice this week.

The Problem with Behavioral Prep

Most engineers treat behavioral prep as a box to check. They print the Amazon Leadership Principles, build a stack of polished STAR stories, and rehearse until the answers are smooth.

FAANG interviewers, especially Amazon Bar Raisers and Google interview committee members, are trained to detect rehearsed perfection. They’re not looking for a flawless highlight reel. They’re trying to understand how you actually think, decide, and grow. Authenticity consistently outperforms polish.

With that in mind, here are the three blunders that most often separate a “Strong No Hire” debrief from an offer.

Blunder #1: The Polished Story That Had No Soul (Amazon)

The Story

Marcus was methodical. He had 16 STAR stories ready, one for each of Amazon’s Leadership Principles. Each one was tightly scripted: clear situation, sharp task, decisive action, measurable result.

In every story, Marcus had saved the day.

He resolved a production outage before it became a customer incident. He pushed back on a bad architectural decision and turned out to be right. He mentored a junior engineer who went on to crush it at their next review.

The Amazon Bar Raiser listened politely through two answers. Then she leaned forward.

”That’s a great result. Can you walk me through a moment during that project where you weren’t sure if you were making the right call?”

Marcus paused. His script didn’t have that scene.

”I mean… it mostly went according to plan.”

That answer, in an Amazon debrief, is a red flag. Bias for Action and Earn Trust both require judgment under uncertainty, and “it mostly went according to plan” signals that either the project wasn’t genuinely hard, or the candidate hasn’t reflected honestly on it.

Why This Tanks Offers

Amazon’s Leadership Principles aren’t a checklist, they’re a lens. Bar Raisers specifically probe for moments of friction, doubt and tradeoff. A candidate who presents only highlights signals shallow self-awareness.

Amazon’s official interviewer guidance (and publicly documented Bar Raiser training themes) specifically emphasizes ”Dive Deep” and ”Are Right, A Lot” as areas where generic, friction-free stories consistently fail. Interviewers are coached to ask follow-up questions until they find the seams.

The Fix: Trade Perfection for Genuine Reflection

Pick your three or four most genuinely hard projects, the ones with real ambiguity, real tradeoffs or a real failure mode. For each one, map out:

1. The moment of highest uncertainty: what did you not know and how did you decide anyway?

2. The tradeoff you made: what did you optimize for and what did you sacrifice?

3. What you’d do differently: and why the experience changed your thinking.

If your story has no moment of genuine doubt, find a different story. Interviewers aren’t looking for weakness, they’re looking for evidence that you can think clearly when the path isn’t obvious.

A story that includes ”I wasn’t sure this was the right call, but here’s why I made it anyway and here’s what I learned” is dramatically more compelling than a story where everything went according to plan.

Practice prompt: Pull up your most recent hard project. Write down three things that didn’t go exactly as expected. Those are the moments your STAR story should highlight.

Blunder #2: “We Did Everything” (Meta)

The Story

Priya was a strong candidate: five years at a well-regarded mid-size company, solid system design skills, and clear communication in the technical rounds. In the behavioral interview at Meta, she was asked: ”Tell me about a time you drove a significant technical decision under time pressure.”

Priya had a perfect example. Her team had been debating a data pipeline architecture for two weeks with no resolution. She stepped in, evaluated three options, and pushed the team to a decision that shipped on schedule and improved throughput by 40%.

But here’s how she told it:

*”We were under a lot of pressure to ship. We spent two weeks debating the architecture. We eventually decided to go with Option B, and we were able to get it shipped on time. We saw a 40% improvement in throughput and the team was really happy with the outcome.”*

The interviewer wrote in the debrief: ”Unclear what this candidate personally contributed. No sense of individual ownership or decision-making.”

Priya had the right story. She delivered it in a way that erased her own role from it.

Why This Tanks Offers

At Meta (and frankly everywhere in FAANG), behavioral interviews are explicitly designed to assess individual judgment, ownership and impact. When you answer in “we,” you’re doing the equivalent of omitting your name from your own resume.

This is especially critical at Meta, where ”Move Fast,” “Be Bold,” and direct ownership are core cultural values. If an interviewer can’t identify what you specifically did, they can’t advocate for you in the debrief.

This blunder is extremely common among engineers from strong team cultures. The collaborative instinct is real and admirable, but it works against you in a behavioral loop.

The Fix: Own the “I” Without Erasing the Team

The goal isn’t to pretend you worked alone. It’s to make your specific contribution visible.

Replace:

• “We decided to…” → “I pushed for… and here’s why”

• “We struggled with…” → “I was the one responsible for…”

• “We shipped it…” → “I drove the final decision on… and here’s what that looked like”

A useful frame: acknowledge the team, claim the action.

”My team was aligned on the problem but stuck on the solution. I took ownership of the decision by doing X, because I believed Y. I brought the team along by doing Z. The result was…”*

You’re not erasing your teammates, you’re making your own judgment visible. That’s exactly what the interviewer needs to evaluate.

Practice prompt: Go back through your last three behavioral stories and highlight every instance of “we.” For each one, ask: what specifically did I do at that moment? Rewrite those lines in first person.

Blunder #3: The Ramble That Buried the Point (Google)

The Story

David was technically excellent. His coding rounds were strong, his system design was sharp, and he had genuinely interesting stories to tell. But in the behavioral round, something strange happened.

The interviewer asked: ”Tell me about a time you gave difficult feedback to a peer.”

David started talking. And kept talking. Three minutes in, he was describing the project backstory in detail: the team dynamics, the quarterly goals, the stakeholder pressures. Four minutes in, he was still setting up the situation. The interviewer tried twice to redirect with ”And what did you actually say to them?” David answered briefly, then pivoted back to more context.

When the interviewer stopped him at six minutes to move on, she had heard very little about what David actually did or what happened as a result.

Her debrief note: ”Unable to isolate candidate’s communication approach. Stories lacked structure. Concern about ability to communicate concisely in leadership contexts.”

David’s story had a great answer buried inside it. It never came out.

Why This Tanks Offers

Unstructured rambling in a behavioral interview signals two things interviewers actively flag: difficulty with concise communication, and low self-awareness about what matters in a story.

At Google specifically, behavioral interviews are evaluated on ”Googleyness” criteria that include clear and effective communication and the ability to synthesize complex information, not just technical clarity. A candidate who can’t structure a verbal story raises doubts about their ability to write clear design docs, give crisp feedback and run efficient meetings.

Google interviewers typically have 5–7 questions to cover in 45 minutes. A 6-minute unstructured answer doesn’t just lose points, it eats the time they need to evaluate other dimensions.

The Fix: The SBI Method (Out Loud)

STAR is the gold standard framework, but for common interpersonal and feedback scenarios, the SBI method (Situation, Behavior, Impact) is tighter and forces you to stay concrete.

• Situation: One or two sentences of context. ”During Q3, we were behind on a critical API integration, and I noticed a senior engineer on my team was consistently missing our design review meetings.”

• Behavior: What specifically did you observe or do? ”In our next 1:1, I named the pattern directly: ‘I’ve noticed you’ve missed the last three reviews, and I want to understand what’s going on.’”

• Impact: What changed as a result? ”He told me he’d been overwhelmed and hadn’t felt safe saying so. We restructured his workload. He came back to reviews the following week and ended up presenting the final design.”

That’s a complete, compelling answer in under 90 seconds.

The key is practicing out loud. Reading SBI examples on paper doesn’t build the habit. Set a timer, speak your answer to the wall (or record yourself on your phone), and stop at 90 seconds. If you can’t land the impact statement before the timer goes off, your Situation block is too long.

Practice prompt: Pick one feedback conversation from the past year. Write it in SBI format. Read it aloud. Time it. Cut until it fits in 90 seconds without losing the core.

The Overarching Lesson: Authenticity Always Outperforms Perfection

Here’s what Marcus, Priya and David all had in common: they were trying to perform a version of competence rather than demonstrate it.

Marcus performed a highlight reel. Priya performed collaborative humility. David performed thoroughness. None of it landed.

FAANG interviewers, particularly at senior levels (E5/E6 and above), have evaluated hundreds of candidates. They’ve heard polished stories. What they’re genuinely looking for is evidence of how you think when things are hard, unclear or uncomfortable.

That evidence only comes through when you’re willing to be honest about:

• The decision you made without enough information

• The friction you created by owning something your team didn’t agree with

• The feedback conversation you were nervous to have

These aren’t weaknesses. They tell an interviewer more about how you’ll operate at a senior level than any perfectly structured highlight story.

The fix isn’t a new framework. It’s honest reflection about your real experience, structured clearly, and practiced out loud until it sounds like you, not a rehearsed script.

What to Do This Week

1. Audit your stories. Pull out your three strongest STAR answers. Does each one include a moment of genuine uncertainty? If not, find a different story or add that moment.

2. Do a “we” audit. Read your stories and circle every “we.” Rewrite each one to make your specific contribution visible.

3. Practice SBI out loud. Pick one interpersonal story: a conflict, a feedback moment, a missed expectation. Write it in SBI format and speak it aloud. Stop at 90 seconds.

You already have the experience. The behavioral interview is about translating that experience into a form that lets an interviewer advocate for you.

© The Coding Interview Gym | paulepps.substack.com

Problem Recap

You are given n cities labeled from 0 to n−1.
Some pairs of cities are connected by roads, and some pairs are connected by bridges.

• Roads are free to use.

• Each bridge crossing costs 1 token, regardless of direction or distance.

You are also given a starting city start, a destination city target, and an integer k representing how many bridge tokens you have.

You can travel:

• Along any road edge at zero cost, unlimited times.

• Along any bridge edge, but in total you may use at most k bridges on your entire route.

Return the minimum number of steps (edges traversed, roads or bridges) needed to travel from start to target without using more than k bridges. If it is impossible, return -1.

A “step” is traversing a single edge (road or bridge) from one city to a directly connected city.

Input format

• n: integer, number of cities.

• roads: list of pairs [u, v] meaning there is an undirected road between u and v.

• bridges: list of pairs [u, v] meaning there is an undirected bridge between u and v.

• start: integer in [0, n-1].

• target: integer in [0, n-1].

• k: integer, maximum number of bridges you may use.

Assumptions:

• The graph can be disconnected.

• There may be both a road and a bridge between the same pair of cities.

• No self-loops are given, but your code should not rely on that.

• Constraints: 1≤n≤10^5, total edges up to 2⋅10^5, 0≤k≤300.

Think before you code

1. What is the graph?

   • How will you represent roads and bridges in a single adjacency list?

   • What information do you need for each edge?

2. What is a state?

   • Is “I am at city 7” enough, or do you also need to know something about how you got there?

   • When are two visits to the same city considered different?

3. What algorithm pattern fits?

   • Every move (road or bridge) costs exactly 1 step. Does this sound weighted or unweighted?

   • Between BFS and DFS, which one naturally gives you a shortest number of steps in an unweighted graph, and why?

4. How big is the state space?

   • Suppose your state is (city, usedBridges). How many such states are possible in the worst case?

   • What does that imply for time and space complexity?

5. Where can this go wrong?

   • If you only track visited[city], what kinds of valid paths might you accidentally prune?

   • Try to construct a small example where that mistake returns -1 even though a valid path exists.

Polished reference solution (Python, BFS)

from collections import deque
from typing import List, Tuple

ROAD = 0
BRIDGE = 1

def min_steps_with_bridges(
    n: int,
    roads: List[Tuple[int, int]],
    bridges: List[Tuple[int, int]],
    start: int,
    target: int,
    k: int
) -> int:
    # Build adjacency list: (neighbor, edge_type)
    adj: List[List[Tuple[int, int]]] = [[] for _ in range(n)]
    for u, v in roads:
        adj[u].append((v, ROAD))
        adj[v].append((u, ROAD))
    for u, v in bridges:
        adj[u].append((v, BRIDGE))
        adj[v].append((u, BRIDGE))

    # visited[city][used_bridges] = have we reached this state?
    visited = [[False] * (k + 1) for _ in range(n)]

    q = deque()
    q.append((start, 0, 0))  # (city, used_bridges, distance)
    visited[start][0] = True

    while q:
        city, used, dist = q.popleft()

        if city == target:
            return dist

        for nei, edge_type in adj[city]:
            next_used = used + (1 if edge_type == BRIDGE else 0)
            if next_used <= k and not visited[nei][next_used]:
                visited[nei][next_used] = True
                q.append((nei, next_used, dist + 1))

    return -1

• The graph is represented as adj[city] = list of (neighbor, type) where type distinguishes roads and bridges.

• The state for BFS is (city, used_bridges); we track dist separately for convenience.

• BFS over this expanded state space guarantees the shortest number of steps in an unweighted graph.

• visited[city][used] ensures we do not revisit the same state, while still allowing revisits to the same city with different bridge usage.

Polished Java version (for readers who prefer Java)

import java.util.*;

public class MinStepsWithBridges {

    private static final int ROAD = 0;
    private static final int BRIDGE = 1;

    public static int minStepsWithBridges(
            int n,
            List<int[]> roads,
            List<int[]> bridges,
            int start,
            int target,
            int k
    ) {
        List<int[]>[] adj = new ArrayList[n];
        for (int i = 0; i < n; i++) {
            adj[i] = new ArrayList<>();
        }

        for (int[] e : roads) {
            int u = e[0], v = e[1];
            adj[u].add(new int[]{v, ROAD});
            adj[v].add(new int[]{u, ROAD});
        }

        for (int[] e : bridges) {
            int u = e[0], v = e[1];
            adj[u].add(new int[]{v, BRIDGE});
            adj[v].add(new int[]{u, BRIDGE});
        }

        boolean[][] visited = new boolean[n][k + 1];
        Queue<int[]> q = new ArrayDeque<>();
        // state: {city, usedBridges, distance}
        q.offer(new int[]{start, 0, 0});
        visited[start][0] = true;

        while (!q.isEmpty()) {
            int[] cur = q.poll();
            int city = cur[0];
            int used = cur[1];
            int dist = cur[2];

            if (city == target) {
                return dist;
            }

            for (int[] edge : adj[city]) {
                int nei = edge[0];
                int type = edge[1];
                int nextUsed = used + (type == BRIDGE ? 1 : 0);

                if (nextUsed <= k && !visited[nei][nextUsed]) {
                    visited[nei][nextUsed] = true;
                    q.offer(new int[]{nei, nextUsed, dist + 1});
                }
            }
        }

        return -1;
    }
}

This follows the standard BFS template described in many interview resources for shortest paths in unweighted graphs.

Weaker solution 1: Wrong visited definition

This is the mistake most people make first: they track visited only per city.

from collections import deque

def min_steps_wrong_visited(
    n, roads, bridges, start, target, k
):
    ROAD, BRIDGE = 0, 1
    adj = [[] for _ in range(n)]
    for u, v in roads:
        adj[u].append((v, ROAD))
        adj[v].append((u, ROAD))
    for u, v in bridges:
        adj[u].append((v, BRIDGE))
        adj[v].append((u, BRIDGE))

    visited = [False] * n  # <== only per city
    q = deque()
    q.append((start, 0, 0))  # city, used_bridges, dist
    visited[start] = True

    while q:
        city, used, dist = q.popleft()
        if city == target:
            return dist

        for nei, edge_type in adj[city]:
            next_used = used + (1 if edge_type == BRIDGE else 0)
            if next_used <= k and not visited[nei]:
                visited[nei] = True
                q.append((nei, next_used, dist + 1))

    return -1

Why it’s wrong:

• This approach treats “I reached city 5 with 0 bridges used” and “I reached city 5 with 3 bridges used” as the same situation.

• In reality, the first is strictly better: you have more flexibility for the rest of the path.

• Because it sets visited[nei] = True regardless of bridge usage, it can prune away valid solutions.

Weaker solution 2: DFS backtracking instead of BFS

This version uses DFS with pruning; it can work on small inputs but doesn’t naturally guarantee shortest paths or good performance.

def min_steps_dfs_wrong(
    n, roads, bridges, start, target, k
):
    ROAD, BRIDGE = 0, 1
    adj = [[] for _ in range(n)]
    for u, v in roads:
        adj[u].append((v, ROAD))
        adj[v].append((u, ROAD))
    for u, v in bridges:
        adj[u].append((v, BRIDGE))
        adj[v].append((u, BRIDGE))

    best = [float('inf')]
    visited = set()  # tracks only city

    def dfs(city, used, dist):
        if dist >= best[0]:
            return
        if used > k:
            return
        if city == target:
            best[0] = min(best[0], dist)
            return

        visited.add(city)
        for nei, edge_type in adj[city]:
            if nei in visited:
                continue
            dfs(nei,
                used + (1 if edge_type == BRIDGE else 0),
                dist + 1)
        visited.remove(city)

    dfs(start, 0, 0)
    return -1 if best[0] == float('inf') else best[0]

• DFS explores one path deeply before trying alternatives, so you can easily walk a long suboptimal path before discovering a shorter one elsewhere.

• The pruning condition dist >= best[0] only works once best[0] is set; until then you might do a ton of unnecessary work.

• This still uses a “city-only” visited set, so it conflates different resource usages just like the first weak solution.

Weaker solution 3: Correct but potential state explosion / timeouts

from collections import deque

def min_steps_slow(
    n, roads, bridges, start, target, k
):
    ROAD, BRIDGE = 0, 1
    adj = [[] for _ in range(n)]
    for u, v in roads:
        adj[u].append((v, ROAD))
        adj[v].append((u, ROAD))
    for u, v in bridges:
        adj[u].append((v, BRIDGE))
        adj[v].append((u, BRIDGE))

    visited = set()
    q = deque()
    q.append((start, 0, 0))  # city, used_bridges, dist
    visited.add((start, 0))

    while q:
        city, used, dist = q.popleft()
        if city == target:
            return dist

        for nei, edge_type in adj[city]:
            next_used = used + (1 if edge_type == BRIDGE else 0)
            if next_used <= k:
                state = (nei, next_used)
                if state not in visited:
                    visited.add(state)
                    q.append((nei, next_used, dist + 1))

    return -1

• This uses the right state (city, usedBridges) and is functionally correct.

• However, because it doesn’t do any additional dominance pruning (e.g., recognizing that reaching (city, used=1) makes (city, used=2) uninteresting for the same or longer distance), it may explore more states than necessary when k is large.

Tying everything together

At first glance, this problem looks like a standard shortest-path question on an unweighted graph. Every move—road or bridge—costs exactly one step, so the natural tool is breadth-first search (BFS), which is known to find shortest paths in unweighted graphs in O(n+m) time.courses.

The twist is the bridge budget k. Reaching a city is no longer a single event; it matters how many bridges you’ve spent getting there. Reaching city 5 after using 0 bridges is strictly better than reaching city 5 after using 3. To capture this, our BFS state is not just city, but (city, usedBridges).

Once we make that modeling decision, everything else falls into place. Our graph of states has at most n * (k + 1) nodes—each original city, expanded across all possible usedBridges values from 0 to k. From a state (city, used) we push neighbors:

• If the edge is a road, we move to (neighbor, used).

• If the edge is a bridge, we move to (neighbor, used + 1) as long as used + 1 ≤ k.

Now we can run a completely standard BFS on this expanded graph. We initialize the queue with (start, 0, 0) where the third component is the number of steps so far. We keep a visited[city][usedBridges] table so we never re-enqueue the same state twice. Because every transition costs exactly 1 step, BFS’s level-order property guarantees that the first time we pop a state whose city == target, we’ve reached it with the minimum possible number of steps.

The first weak solution illustrates a classic pitfall: tracking visited only per city. That works when the only thing that matters is which node you’re in, but breaks as soon as there’s an extra resource dimension like “bridges used,” “walls broken,” or “keys collected.” By marking visited[city] = True unconditionally, that solution may discard a later visit to the same city with fewer bridges spent, even though that later visit might lead to the only feasible path to the target.

The DFS variant shows a different kind of mistake: choosing the wrong traversal pattern. DFS explores one path to the bitter end before trying alternatives, so it’s a poor fit for shortest-path problems in general graphs. You can try to patch it with a global best distance and pruning, but there’s no structural guarantee that you’ll explore paths in increasing-length order. On larger inputs, this degenerates into expensive backtracking with fragile heuristics, which is exactly why most interview references recommend BFS (or Dijkstra, for weighted graphs) for shortest paths.

Finally, the “slow but correct” BFS reminds us that correctness is only part of the story. It uses the right state and will produce the right answer, but a naive state-space treatment can be unnecessarily heavy. Thinking about the size and structure of your state space—how many distinct (city, usedBridges) pairs exist, and which ones are actually worth exploring—is an important part of designing scalable graph algorithms. This is the same kind of reasoning that leads from plain BFS to 0–1 BFS or more general resource-constrained shortest path algorithms in advanced settings.

Taken together, these versions trace a progression that’s common in strong interview performances: first get the modeling right, then choose the right traversal pattern, and finally reason about the complexity of the state space, not just the graph’s raw node count.

1. Restating the challenge

Given the root of a binary tree, return its maximum depth (height): the number of nodes along the longest path from the root down to the farthest leaf. An empty tree has depth 0.

2. A clean Java solution

This is an “interview‑ready” version: short, idiomatic, and closely aligned with the recursive definition of tree height.

// Definition for a binary tree node.
class TreeNode {
    int val;
    TreeNode left;
    TreeNode right;

    TreeNode(int val) {
        this.val = val;
    }

    TreeNode(int val, TreeNode left, TreeNode right) {
        this.val = val;
        this.left = left;
        this.right = right;
    }
}

class Solution {
    // Returns the maximum depth (height) of the binary tree.
    public int maxDepth(TreeNode root) {
        // Base case: empty subtree has depth 0
        if (root == null) {
            return 0;
        }

        // Recursively compute depth of left and right subtrees
        int leftDepth = maxDepth(root.left);
        int rightDepth = maxDepth(root.right);

        // Current node’s depth = 1 (this node) + deeper of the two subtrees
        return 1 + Math.max(leftDepth, rightDepth);
    }
}

How to explain it in an interview

• Think in terms of subtrees: the depth of the whole tree is 1 plus the maximum of the depths of the left and right subtrees.

• The recursion mirrors that definition: if the subtree is empty, the depth is 0; otherwise, recur on children and take 1 + max(left, right).

3. A “not‑so‑good but correct” Python solution

Here’s a version that technically works, but takes the scenic route and makes the recursion harder than it needs to be. It’s the kind of thing an unsure candidate might write under pressure.

from typing import Optional, List, Tuple

class TreeNode:
    def __init__(self, val: int = 0,
                 left: 'Optional[TreeNode]' = None,
                 right: 'Optional[TreeNode]' = None):
        self.val = val
        self.left = left
        self.right = right


def max_depth_bad(root: Optional[TreeNode]) -> int:
    # Handle the trivial case explicitly
    if root is None:
        return 0

    # We'll store (node, depth) pairs for *every* node
    all_nodes: List[Tuple[TreeNode, int]] = []

    def dfs(node: Optional[TreeNode], depth: int) -> None:
        # Redundant base case checks & side effects
        if node is None:
            return

        # Record this node and its depth in a list
        all_nodes.append((node, depth))

        # Recurse on children, but keep incrementing depth manually
        if node.left is not None:
            dfs(node.left, depth + 1)
        else:
            # unnecessary branch
            dfs(None, depth + 1)

        if node.right is not None:
            dfs(node.right, depth + 1)
        else:
            # unnecessary branch
            dfs(None, depth + 1)

    # Start DFS from root at depth 1
    dfs(root, 1)

    # Now compute maximum depth by scanning the list we built
    max_d = 0
    for (_, d) in all_nodes:
        if d > max_d:
            max_d = d

    return max_d

What’s “bad” about it?

• It keeps an extra list of all nodes and depths, then scans that list to find the max, rather than just returning the depth directly from recursion. This adds both time and space overhead.

• It makes unnecessary recursive calls on None, deepening the call stack without any benefit and increasing the chance of hitting recursion‑limit issues on tall trees.

• The control flow is more complicated than the simple “1 + max(left, right)” pattern, which makes it harder to see the recursion invariant.

4. Time complexity: same big‑O, very different clarity

Both implementations ultimately visit each real node exactly once.

• In the Java version, it’s easy to see: each node does constant work and makes at most two recursive calls, one to each child.neetcode+1

• In the Python version, we still traverse each node once, but we also keep an O(n) list of (node, depth) pairs and do an extra linear scan at the end. The asymptotic time complexity is still O(n), but with a larger constant factor and more mental overhead.

This is an important interview point: two solutions can share the same big‑O yet differ a lot in simplicity, constants, and how easy they are to verify.

5. Stack depth and space: what the call stack is doing

The clean Java version is also much nicer to reason about in terms of stack depth and auxiliary space.

• Every active recursive call corresponds to one node on a single root‑to‑current‑node path, so at any moment the number of frames on the stack is at most the tree height.

• That gives auxiliary space O(h):

  • For a balanced tree, h ≈ log n.

  • For a skewed “linked‑list‑shaped” tree, h ≈ n, so stack space can grow to O(n).

The Python version shares the same recursion behavior, but then adds an all_nodes list of size O(n) on top of the O(h) call stack. That means its total extra space is O(n) even on a balanced tree, purely due to the way it’s structured.guides.

6. Takeaways

• Start from the mathematical definition: “depth of a tree = 0 if empty, else 1 + max(depth of children)”. Code that literally.

• Avoid carrying extra global lists or making redundant recursive calls; they rarely help and often make reasoning about complexity harder.

• When you explain time and space, tie them directly to “one visit per node” and “one stack frame per level down the tree”.

Here’s an iterative Java section you can drop into the solutions post, contrasting recursion with an explicit data structure.

7. Iterative Java solution: same idea, explicit stack/queue

A great follow‑up is: “What if the tree is so deep that recursion risks stack overflow?” One answer is to do the same depth‑first search iteratively using your own stack.

Iterative DFS with an explicit stack

import java.util.Stack;
import javafx.util.Pair; // or your own simple Pair class

class SolutionIterativeDFS {
    public int maxDepth(TreeNode root) {
        if (root == null) {
            return 0;
        }

        // Stack holds (node, depth) pairs
        Stack<Pair<TreeNode, Integer>> stack = new Stack<>();
        stack.push(new Pair<>(root, 1));

        int maxDepth = 0;

        while (!stack.isEmpty()) {
            Pair<TreeNode, Integer> current = stack.pop();
            TreeNode node = current.getKey();
            int depth = current.getValue();

            // Update answer
            if (depth > maxDepth) {
                maxDepth = depth;
            }

            // Push children with depth + 1
            if (node.left != null) {
                stack.push(new Pair<>(node.left, depth + 1));
            }
            if (node.right != null) {
                stack.push(new Pair<>(node.right, depth + 1));
            }
        }

        return maxDepth;
    }
}

This mirrors the recursive logic: the stack now plays the role of the call stack, and each entry tracks “which node” and “what depth we’re at.”

How to talk about complexity

• Time: Iterative DFS still visits every node exactly once and does constant work per node, so it runs in O(n) time.

• Space: Iterative DFS uses a stack whose maximum size is proportional to the height h of the tree, so O(h) extra space, just like the recursive version.

In the recursive version, the call stack is hidden inside the runtime.

In the iterative version, we build that stack explicitly, but the time and space story is the same: O(n) time, and O(h) for DFS.

This week’s challenge was about arrays and strings. It’s a good test for “talking through tradeoffs” because it has multiple reasonable solutions.

Frequency map + sort

• Build a hashmap count: word -> frequency.

• Convert entries to a list and sort with custom comparator:

  • Primary key: frequency descending, secondary key: word ascending.

• Take first k.

import java.util.*;

public class TopKFrequentWordsSort {
    public List<String> topKFrequent(String[] words, int k) {
        Map<String, Integer> freq = new HashMap<>();
        for (String w : words) {
            freq.put(w, freq.getOrDefault(w, 0) + 1);
        }

        List<String> candidates = new ArrayList<>(freq.keySet());

        // Sort by: frequency desc, then word asc
        Collections.sort(candidates, (w1, w2) -> {
            int f1 = freq.get(w1);
            int f2 = freq.get(w2);
            if (f1 != f2) {
                return Integer.compare(f2, f1); // higher freq first
            }
            return w1.compareTo(w2);            // lexicographically smaller first
        });

        return candidates.subList(0, k);
    }
}

Tradeoffs

• Time: O(n log ⁡n) due to sorting all unique words; n is number of words or number of unique words depending how you phrase it.

• Space: O(u) where u is number of unique words.

• Pros: Very simple and easy to implement correctly.

• Cons: Overkill if k is small and u is large; you pay sort cost for all items.

Frequency map + size‑k heap

• Same frequency map.

• Maintain a min‑heap of size at most k, ordered by:

  • frequency ascending, and for ties, word descending (so the “worst” candidate is at the top).

• Iterate over all unique words:

  • Push into heap.

  • If heap size exceeds k, pop.

• At the end, heap contains the k best; pop all and reverse to get correct order.

import java.util.*;

public class TopKFrequentWordsHeap {
    public List<String> topKFrequent(String[] words, int k) {
        Map<String, Integer> freq = new HashMap<>();
        for (String w : words) {
            freq.put(w, freq.getOrDefault(w, 0) + 1);
        }

        // Min-heap: worst candidate on top
        PriorityQueue<String> pq = new PriorityQueue<>((w1, w2) -> {
            int f1 = freq.get(w1);
            int f2 = freq.get(w2);
            if (f1 != f2) {
                return Integer.compare(f1, f2); // lower freq first
            }
            return w2.compareTo(w1);            // lexicographically larger first
        });

        for (String word : freq.keySet()) {
            pq.offer(word);
            if (pq.size() > k) {
                pq.poll(); // remove worst candidate
            }
        }

        List<String> result = new ArrayList<>();
        while (!pq.isEmpty()) {
            result.add(pq.poll());
        }
        Collections.reverse(result); // heap gives lowest-first, reverse to highest-first
        return result;
    }
}

Tradeoffs

• Time: O(u log k).

  • Better than full sort when k << u.

• Space: O(u) for the map, O(k) for the heap.

• Pros: Asymptotically better when k is small, demonstrates priority queues.

• Cons: Comparator is subtle, correctness bugs are easy; more complex than sorting.

Here’s a size‑k min‑heap version in Python:

from collections import Counter
import heapq
from typing import List, Tuple

def topKFrequent(words: List[str], k: int) -> List[str]:
    freq = Counter(words)

    # Heap elements: (count, rev_word, word)
    # rev_word = a key that makes lexicographically larger words "smaller"
    # so they rise to the top and are evicted first on ties.
    def rev_key(w: str) -> str:
        # Map each char c to chr(255 - ord(c)) to reverse lex order
        return ''.join(chr(255 - ord(c)) for c in w)

    heap: List[Tuple[int, str, str]] = []

    for word, count in freq.items():
        entry = (count, rev_key(word), word)
        heapq.heappush(heap, entry)
        if len(heap) > k:
            heapq.heappop(heap)

    # Extract words (heap is from worst to best); reverse to get best to worst.
    res = [heapq.heappop(heap)[2] for _ in range(len(heap))]
    return res[::-1]

In an interview setting, I’d usually annotate verbally that the key design choice is “min‑heap holding the top k so far; comparator makes the least desirable candidate sit at the root and be evicted when size exceeds k.”

Bucket‑style idea

• Because max frequency ≤ n, you can bucket words by frequency.

• After building the map, make an array of lists buckets[1..n], each bucket holds words with that frequency.

• Traverse buckets from high freq to low, sort each bucket’s words lexicographically, and accumulate until you have k.

using System;
using System.Collections.Generic;

public class Solution {
    public IList<string> TopKFrequent(string[] words, int k) {
        int n = words.Length;
        var result = new List<string>();

        // 1. Count frequencies
        var count = new Dictionary<string, int>();
        foreach (var w in words) {
            if (!count.ContainsKey(w)) {
                count[w] = 0;
            }
            count[w]++;
        }

        // 2. Buckets: index = frequency, each bucket holds words with that freq
        var buckets = new List<string>[n + 1];
        foreach (var kvp in count) {
            string word = kvp.Key;
            int freq = kvp.Value;
            if (buckets[freq] == null) {
                buckets[freq] = new List<string>();
            }
            buckets[freq].Add(word);
        }

        // 3. Walk buckets from high freq to low
        for (int freq = n; freq > 0 && result.Count < k; freq--) {
            if (buckets[freq] == null) continue;

            // For equal frequency, words must be in lexicographic order
            buckets[freq].Sort(StringComparer.Ordinal);

            foreach (var word in buckets[freq]) {
                result.Add(word);
                if (result.Count == k) {
                    return result;
                }
            }
        }

        return result;
    }
}

Tradeoffs

• Time: O(n + u + ∑sort(bucket)); in worst case still O(u log u), but can be good when frequencies are spread out.

• Space: O(n+u).

• Pros: Great to talk about using constraints (freq bounded by n), shows alternative to comparison sort.

• Cons: More bookkeeping, less common pattern in standard interviews.

How to answer it in an interview

• You can start with a brute‑force / straightforward approach (frequency map + sort).

• Analyze time vs space and when that’s acceptable.

• If asked, “What if k is small and the number of unique words is huge?” this leads into the heap solution.

• Compare:

  • Simplicity / robustness of the sort approach.

  • Performance benefit and added complexity of the heap.

• If asked, “Can we do better using the fact that frequency is bounded by n?” this gets you to buckets. In practice, the C# bucket solution was the fastest of all the shown solutions.

If you joined late or didn’t submit this week, you can still work through the prompt and compare your answer to the solutions and notes above.