Given an array of integers and a target, return the indices of two numbers that add up to the target.

The complete answer guide: what this question really tests, two example strong answers in different angles, the common weak answer rewritten, and the trap most candidates fall into. This is a technical deep-dive archetype question — see the broader pattern guide for the structural shape.

What this question is really testing

This question isn't testing whether you can solve the two-sum problem—it's testing whether you can think algorithmically under pressure and communicate your thought process before writing code. The interviewer is making a binary read: do you jump straight to coding, or do you pause to clarify constraints, consider multiple approaches, and articulate trade-offs? They're specifically worried you're someone who has memorized LeetCode solutions without understanding the underlying principles of hash table optimization. The signal they want is that you can recognize when a brute force O(n²) solution is unacceptable and independently arrive at the O(n) hash map approach through reasoning, not recall.

The deeper test is about your engineering maturity. When you ask "Can the array contain duplicates?" or "Should I return any valid pair or all pairs?" you're demonstrating that you've debugged enough production code to know that ambiguous requirements cause bugs. When you say "I'll use a hash map to trade space for time," you're showing you understand algorithmic trade-offs aren't just academic—they're decisions you'll make when optimizing database queries or caching strategies. The interviewer is deciding whether you're someone who will ship a nested loop that times out on production data, or someone who instinctively reaches for the right data structure.

Two strong answers, two angles

Angle A: Structured problem-solver

"Let me first clarify the constraints—can I assume each input has exactly one solution, and can I use the same element twice? Assuming not, I'll walk through two approaches. The brute force is checking every pair with nested loops, which is O(n²) time and O(1) space. The optimized approach uses a hash map: as I iterate through the array, I check if `target - current_number` exists in my map, and if not, I store the current number with its index. This gives me O(n) time and O(n) space. For an interview or production scenario, I'd choose the hash map approach unless we're severely memory-constrained, which would be unusual for this problem size."

Angle B: Practical engineer

"I've actually debugged a similar problem in production where a teammate used nested loops to find matching transactions, and it timed out once we hit 10,000 records. So my instinct here is to use a hash map to make this single-pass. I'll iterate once, and for each number, I'll check if its complement—`target minus current number`—already exists in my map. If yes, I return both indices immediately. If no, I add the current number and index to the map and continue. This is O(n) time because hash lookups are O(1), and O(n) space for the map. The key insight is we don't need to see all pairs—we just need to remember what we've seen so far."

The common weak answer

"I would use two loops to check every possible pair of numbers. The outer loop goes through each element, and the inner loop checks if any other element adds up to the target. When I find a match, I return those indices. If I don't find anything, I return an empty result or null."

This answer fails because it stops at the brute force solution without acknowledging its limitations or demonstrating awareness that a better solution exists. The interviewer reads this as someone who either doesn't know fundamental data structures or doesn't care about performance—both are red flags. You've technically answered the question, but you've signaled you're not thinking about scalability, which is exactly what separates junior from mid-level engineers. Even if you genuinely can't figure out the optimal solution, you should say: "The brute force O(n²) approach works but feels inefficient—I'm thinking there's probably a way to use a hash map here to make it linear time, let me work through that." This reframe shows you recognize the problem even if you need a moment to solve it.

The one trap most candidates fall into

The trap is treating this as purely an algorithms puzzle instead of a conversation about engineering decisions. Candidates often launch into coding the hash map solution immediately because they've memorized it, but they skip the crucial step of explaining why the hash map works and what trade-off they're making. When the interviewer asks "Why use a hash map?" and you can't articulate "because I need O(1) lookup to check if the complement exists, and a hash map gives me that while an array would require O(n) searching," you've revealed the memorization.

The counterintuitive insight is that talking through the brute force solution first—even though it's "wrong"—actually makes you look stronger, not weaker. It demonstrates you can analyze time complexity, that you understand the problem deeply enough to see multiple solutions, and that you're choosing the optimal approach deliberately rather than reflexively. Interviewers have seen hundreds of candidates recite the hash map solution; what distinguishes you is showing the reasoning path that leads there. Spend 30 seconds on "the naive approach is nested loops, but that's quadratic" before jumping to the optimization, and you'll signal senior-level thinking even if you're applying for a junior role.

Common questions

Other technical deep-dive questions