Demonstrating Problem Solving

Problem-solving is the most important dimension of your interview. Here's how to demonstrate it effectively.

The Problem-Solving Framework

Step 1: Understand the Problem (2-3 minutes)

What to do:

Repeat the problem in your own words
Ask clarifying questions
Work through examples
Identify constraints

Example dialogue:

You: "So just to confirm, we need to find two numbers that sum to
     the target, and we return their indices, not the values?"

Interviewer: "Correct."

You: "And can we assume there's always exactly one solution?"

Interviewer: "Yes."

You: "Can the same element be used twice?"

Interviewer: "No, each element can only be used once."

Good Questions to Ask:

Input constraints (size, range, type)
Edge cases (empty input, duplicates, negatives)
Expected output format
Can I modify the input?
Are there guaranteed to be solutions?

Step 2: Examples and Edge Cases (2-3 minutes)

Walk through examples out loud:

You: "Let me work through an example to make sure I understand.

     If we have [2, 7, 11, 15] and target is 9:
     - We check 2: need 7, and we have 7 at index 1
     - So we return [0, 1]

     Let me think about edge cases:
     - Empty array: should return error or empty result
     - Array with one element: no solution possible
     - Duplicate numbers: like [3, 3] target 6, return [0, 1]
     - Negative numbers: [-1, -2, -3] target -5, works normally"

Step 3: Discuss Approaches (3-5 minutes)

Present multiple solutions with tradeoffs:

You: "I can think of a few approaches:

     Approach 1: Brute Force
     - Check every pair of numbers
     - Time: O(n²), Space: O(1)
     - Simple but inefficient for large inputs

     Approach 2: Hash Map
     - Store numbers we've seen in a map
     - For each number, check if complement exists
     - Time: O(n), Space: O(n)
     - Much faster, uses extra space

     Approach 3: Two Pointers (if sorted)
     - Sort the array first
     - Use two pointers from ends
     - Time: O(n log n), Space: O(1)
     - But we need to track original indices

     I think the hash map approach is best here because:
     1. Linear time is optimal for this problem
     2. The extra space is acceptable
     3. We avoid the sorting overhead

     Does that sound reasonable?"

Why this is good:

Shows you can think of multiple approaches
Demonstrates understanding of tradeoffs
Invites collaboration with interviewer
Shows you prioritize the right solution

Step 4: Optimize Before Coding (1-2 minutes)

Think through your algorithm:

You: "So here's my plan:
     1. Create an empty hash map
     2. For each number and its index:
        a. Calculate complement (target - number)
        b. Check if complement is in map
        c. If yes, return [map[complement], current index]
        d. If no, add current number and index to map

     This ensures we see each number once before checking it,
     so we won't use the same element twice.

     Does this approach make sense?"

Communication Patterns That Score Well

Pattern 1: Incremental Thinking

❌ Bad:

"I'll use dynamic programming."
*starts coding immediately*

✅ Good:

"This feels like it might have optimal substructure. Let me think...
Each position depends on choices made at previous positions.
We could use DP. Let me define the state..."

Pattern 2: Considering Alternatives

❌ Bad:

"I'll sort the array."
*sorts without explanation*

✅ Good:

"We could sort the array which would let us use two pointers,
but that's O(n log n) and we'd lose the original indices.
Instead, let's use a hash map to get O(n) time..."

Pattern 3: Catching Your Own Mistakes

❌ Bad:

*writes wrong solution*
*doesn't notice*

✅ Good:

"Wait, actually that won't work because...
Let me reconsider. What if we..."

Pattern 4: Responding to Hints

❌ Bad:

Interviewer: "What if you stored the values you've seen?"
You: "Hmm, I don't think that helps."

✅ Good:

Interviewer: "What if you stored the values you've seen?"
You: "Oh interesting! So as I go through, I could check if I've
     already seen the complement. Let me work that out..."

Demonstrating Problem-Solving Skills

Show Pattern Recognition

You: "This reminds me of the two-sum problem. We're looking for
     pairs that satisfy a condition. The hash map approach should
     work here too, where we..."

Break Down Complex Problems

You: "This is complex. Let me break it down:
     1. First, we need to validate the input
     2. Then, find all the candidates
     3. Finally, count the valid pairs

     Let me tackle each part separately..."

Consider Constraints

You: "Given that n can be up to 10⁵, an O(n²) solution might be too
     slow. We should aim for O(n) or O(n log n)..."

Think About Edge Cases

You: "Before I code, let me think about edge cases:
     - What if the array is empty?
     - What if there are duplicates?
     - What if no solution exists?

     I should handle these in my code..."

Red Flags to Avoid

❌ Silent Thinking

*stares at screen for 3 minutes*

Fix: "Let me think through this out loud..."

❌ Jumping to Code

*immediately starts typing*

Fix: "Let me first outline my approach..."

❌ Ignoring Constraints

*doesn't consider input size*

Fix: "Given the constraints, we need O(n)..."

❌ Not Asking Questions

*makes assumptions without confirming*

Fix: "Before I continue, can I clarify..."

❌ Defensive About Approach

"My solution is definitely right."

Fix: "I think this works, but let me verify..."

Practice Exercise

Next time you practice, record yourself and check:

Did I repeat the problem to confirm understanding?
Did I ask at least 3 clarifying questions?
Did I work through 2-3 examples?
Did I mention edge cases?
Did I discuss multiple approaches?
Did I explain my choice of approach?
Did I outline my algorithm before coding?
Did I think out loud throughout?

Key Takeaway

Problem-solving isn't just about finding the answer—it's about showing how you think. The best candidates make the interviewer feel like they're pair programming with a thoughtful colleague, not watching someone struggle in silence.