Hash Map Bugs in Coding Interviews: Five That Still Get You
- Check-before-insert: In Two Sum, storing before checking causes an element to match itself on inputs like
[3,3], target=6 - Unhashable list keys:
sorted()returns a list in Python; convert totuple()before using it as a hash map key - Missing prefix seed
{0: 1}: Without it, Subarray Sum Equals K misses every subarray starting at index 0 - Phantom zero-count keys: Delete the key when its count hits zero;
len(window)treats zero-count and absent keys differently - Non-unique composite keys: Joining character counts without a delimiter silently collides when any count reaches double digits
Hash maps look like the solution to everything. Existence check? Hash set. Frequency count? Hash map. Subarray sum? Hash map. You see the pattern, reach for the tool, and type out the solution in five minutes feeling like an absolute genius.
Then the interviewer changes one number and your code breaks.
These hash map bugs in coding interviews are not about knowing when to reach for the pattern. They are the implementation details that only surface on specific inputs. Here are the five that show up most often, with the exact input that exposes each one.
The Check Has to Come Before the Insert
Two Sum is probably the first hash map problem you solved. It's the "hello, world" of interview prep. For each number, check whether its complement exists in the map. If yes, return both indices. If no, store the number and move on. Easy.
The ordering matters more than most solutions bother to explain. Consider nums = [3, 3], target = 6. If you insert before checking, when you reach the second 3, you find the first 3 already stored and return [0, 0]. Congratulations. You matched an element with itself. The index you returned was the same index twice. The interviewer is making a note.
# Bug: insert before check for i, num in enumerate(nums): seen[num] = i complement = target - num if complement in seen: return [seen[complement], i] # returns [0, 0] for [3,3], target=6
Two lines swapped fixes it:
# Correct: check before insert for i, num in enumerate(nums): complement = target - num if complement in seen: return [seen[complement], i] seen[num] = i
Check first. Store after. The current element cannot be its own complement because it is not in the map yet. The bug input is not some obscure adversarial case. It is two identical numbers that sum to the target. Every Two Sum test suite has it.
Mutable Lists Cannot Be Hash Map Keys
Group Anagrams is the classic "design your key" problem. Sort each word to get its canonical form, use that as the map key. Most people sort correctly but pass the result directly without converting it.
key = sorted(word) # returns a list groups[key].append(word) # TypeError: unhashable type: 'list'
Python raises TypeError immediately, so at least you know. JavaScript is quieter: arrays used as object keys get coerced to strings, which looks right until you find an accidental collision. Python crashes loudly; JavaScript corrupts silently. This is a metaphor for their entire relationship.
Any mutable object fails as a hash table key because its hash value could change after insertion. The hash function has to return the same result across lookups. Mutable objects cannot guarantee that, so Python just refuses. The fix is one word.
key = tuple(sorted(word)) # tuples are hashable
If you are grouping by character frequency instead of sorted letters, the same rule applies. Build a 26-element count array, then wrap it: tuple(counts). Java's HashMap will accept a list as a key, but if you mutate it after insertion, the bucket lookup breaks and the entry becomes permanently unreachable. Java will not tell you this happened. The data just vanishes.
Two Sum with [3,3]: the "easy warm-up" that filters candidates who memorized solutions instead of understanding them.
The Prefix Sum Seed You Always Forget
Subarray Sum Equals K uses prefix sums with a hash map to count valid subarrays in O(n). For each prefix sum, check if prefix_sum - k was seen before. If yes, those two positions bound a subarray with sum k. The algorithm is beautiful. The initialization is a trap.
The bug: starting with an empty map.
seen = {} # bug prefix = 0 for num in nums: prefix += num count += seen.get(prefix - k, 0) seen[prefix] = seen.get(prefix, 0) + 1
Try nums = [3], k = 3. After processing 3, prefix = 3. You look for prefix - k = 0 in seen. Not there. You return 0. The correct answer is 1.
The map represents "prefix sums seen so far," and a prefix sum of 0 exists before you process any element. That is the empty prefix. It covers any subarray starting at index 0 that sums exactly to k. Without it, that entire category disappears from the count and you have no idea why your solution is off by one.
seen = {0: 1} # correct: the empty prefix has sum 0
Two characters. Completely changes the output. This trips up roughly half the wrong submissions on prefix sum problems. If your solution passes [1, 1, 1] with k = 2 but fails [3] with k = 3, this is exactly why.
The prefix sum guide covers when the hash map pairing is the right move.
Phantom Keys Break Your Window Size
Sliding window problems often track window contents in a hash map, then check map size to validate the current window. Longest Substring with At Most K Distinct Characters is the standard example: map size tells you how many distinct characters are in the window.
When a character slides out, you decrement its count. If you forget to delete the key when the count hits zero, the map size is wrong. The character is gone. The key is still there. The map thinks it is still present. Your window shrink condition fires based on a lie.
# Bug: stale zero entry left in map window[outgoing] -= 1 # missing: if window[outgoing] == 0: del window[outgoing] left += 1 # len(window) now includes a character not in the window
The phantom key makes len(window) report a value that includes a character no longer present. Your shrink condition fires too early or not at all. The bug only surfaces when a character fully exits the window before the next check, which is not every test case, which is why it feels like it works until suddenly it does not.
# Correct window[outgoing] -= 1 if window[outgoing] == 0: del window[outgoing] left += 1
The same rule applies to Minimum Window Substring and any problem where "this key is in the map" means "this element is present." A zero-count key and an absent key are not the same thing. A count of zero is not the same as gone. Clean up when the count reaches zero.
The sliding window guide covers the full expand-and-shrink loop.
Your Composite String Key Is Not Unique
This one nobody warns you about. And it does not crash. It just produces wrong answers that look plausible.
A common approach for Group Anagrams: skip sorting, compute a 26-element character frequency array, join the counts into one string.
counts = [0] * 26 for c in word: counts[ord(c) - ord('a')] += 1 key = "".join(map(str, counts)) # looks right, breaks on specific inputs
This produces silent collisions whenever any character count reaches double digits. Here is the exact mechanism.
Take two words that are not anagrams:
"accccccccccc"(a=1, c=10): counts =[1, 0, 10, 0, ...]"aaaaaaaaaab"(a=10, b=1): counts =[10, 1, 0, ...]
Joining without a delimiter:
[1, 0, 10, 0, ...]→"1"+"0"+"10"+"0"+ ... →"1010..."[10, 1, 0, ...]→"10"+"1"+"0"+ ... →"1010..."
Same string. Different words. Not anagrams. They land in the same group, and every output that includes them is wrong.
This does not show up in most test suites because standard inputs have each character appearing only a few times. The collision appears only when a character repeats ten or more times. You will not notice it during practice, you will not notice it during the first part of the interview, and you will absolutely notice it when the interviewer runs the last test case.
Your Group Anagrams solution on 99% of test inputs. Then: "accccccccccc".
Both fixes are reliable:
# Option 1: add a delimiter key = ",".join(map(str, counts)) # "1,0,10,0,..." is unambiguous # Option 2: skip string encoding key = tuple(counts) # always safe
The same issue appears in matrix problems where people encode coordinates as str(row) + str(col). Row=1, col=23 and row=12, col=3 both produce "123". A comma or a tuple ends the ambiguity immediately.
The inputs that expose these bugs are not exotic. A target equal to twice one element, a character repeated ten times, a subarray starting at index zero. The fix in each case is one or two lines. Knowing the failure mode is the hard part, and reading about it is very different from catching it yourself mid-interview while someone watches you type.
If you want to find these bugs under actual interview pressure rather than reading about them, SpaceComplexity runs voice-based mock interviews that surface exactly this kind of mistake mid-solution, before the interviewer has to point it out.