Two Sum Solution Python

Getting it done right

The naive brute-force approach checks every pair, which is O(n²). That works fine for small inputs in a coding interview, but it's garbage in production. The actual useful Two Sum Solution Python uses a hash map (dictionary) to track what you've seen so far, bringing it down to O(n) time. Here's what that looks like. def two_sum(nums, target): seen = {}

for i, num in enumerate(nums):     complement = target - num     if complement in seen:

        return [seen[complement], i]     seen[num] = i     return []

That's it. You loop through once, check if the complement already exists in your dictionary, and if it does, you return those two indices immediately. If not, you store the current number and keep going. Let me walk through a concrete example. Say nums is [3, 2, 4] and target is 6. On the first iteration, i=0, num=3, complement=3. Is 3 in seen? No. Store it: {3: 0}. Next iteration, i=1, num=2, complement=4. Is 4 in seen? No. Store it: {3: 0, 2: 1}. Next iteration, i=2, num=4, complement=2. Is 2 in seen? Yes — it's at index 1. Return [1, 2]. I ran into a genuinely annoying edge case last year on a project where the input array contained duplicate values and the target required two of the same number. Something like nums=[3, 3] and target=6. A sloppy implementation that checks for the complement before inserting the current number into the dictionary will fail here because on the second 3, the first 3 isn't yet in seen. The key is that you must check for the complement before you insert the current element into the dictionary. That ordering is what makes the code above correct.

Also worth noting: this returns the first valid pair it finds. If there are multiple valid pairs and you need all of them, this approach only gives you one. That's usually fine for the LeetCode version of the problem but it matters if you're actually using this in a real system where you need completeness.

Why people mess this up in interviews

Most candidates write the brute force version and call it a day. It passes the easy test cases but they don't think about why. The dictionary approach is O(n) because dictionary lookups are O(1) on average, and you only iterate through the array once. That tradeoff is worth understanding, not just memorizing. Another common mistake is returning the values instead of the indices. The actual problem statement asks for indices, so returning [3, 3] when the answer should be [0, 1] is an automatic fail. Read the requirements carefully before you code anything. There's also a space-time tradeoff you should be aware of. The hash map solution uses O(n) extra space. If memory is constrained and you can't afford that, you could sort the array first and use two pointers, which gets you O(1) extra space but O(n log n) time. For most practical purposes the hash map version is better because O(n) time beats O(n log n) time, even with the extra memory cost. But if you're working in an environment where allocating a dictionary for millions of elements is problematic, the two-pointer approach is your fallback.

A word on production usage

I've seen this pattern get pasted into real codebases where the input size was unbounded and unpredictable. Dictionary lookups can degrade to O(n) in the worst case due to hash collisions, so it's not guaranteed O(n). Python's dict implementation is generally solid about this, but if you're dealing with adversarial inputs designed to cause collisions, you could hit performance issues. In those rare cases, a sorted binary search approach is more predictable, though more code to maintain. For the vast majority of uses — coding interviews, competitive programming, internal tools with reasonable input sizes — the hash map approach is the right call. It's clean, fast, and easy to explain. That's why it's the standard Two Sum Solution Python you'll find everywhere, and for good reason.