Problem Solving Strategies for Coding Interviews

The Biggest Mistake Candidates Make

The number one reason candidates fail coding interviews is not lack of algorithm knowledge — it is jumping to code too quickly. They hear the problem, half-understand it, and start typing. Then they hit edge cases, realize their approach is wrong, and waste 20 minutes refactoring under pressure.

The fix is a structured process. Every successful interviewee follows roughly the same mental framework, whether they know it consciously or not.

The 6-Step Framework

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

Do NOT start coding. Instead:

• Restate the problem in your own words to the interviewer. "So I need to find the longest substring where no character repeats, correct?"
• Clarify ambiguities: What if the input is empty? Are there negative numbers? Is the array sorted? Can elements repeat?
• Identify input/output types: Array of integers in, single integer out? String in, list of strings out?
• Understand constraints: N ≤ 10^5 tells you O(n²) won't work. N ≤ 20 tells you exponential might be fine.

Pro tip: Write down the constraints on your whiteboard/paper. They guide your algorithmic choices.

Step 2: Explore with Examples (2-3 minutes)

Work through 2-3 examples by hand:

• One "normal" example from the problem statement
• One edge case (empty, single element, all same)
• One slightly complex example you create yourself

As you trace through, look for patterns. Often the manual process reveals the algorithm.

Step 3: Brute Force First (2-3 minutes)

State the brute force solution out loud, even if it is obviously too slow:

"The brute force would be to check every pair, which is O(n²). Given n can be 10^5, that is 10^10 operations — too slow. But let me note it as a starting point."

Why this matters:

• Shows the interviewer you can identify a correct (if slow) approach
• Gives you a fallback if you cannot optimize in time
• The brute force often hints at the optimization

Step 4: Optimize (5-10 minutes)

This is where algorithm knowledge meets problem-solving skill. Ask yourself:

• Can I sort the input? Sorting often enables two-pointer or binary search approaches.
• Can I use a hash map/set? Trades space for time. "Have I seen this element before?" becomes O(1).
• Can I precompute something? Prefix sums, frequency counts, cumulative results.
• What data structure gives me the operations I need? If I need fast lookup + ordered iteration → TreeMap. If I need fast insert + fast min → Heap.
• Can I break this into subproblems? → Dynamic programming.
• Is there a greedy choice? Can I make locally optimal decisions?

Step 5: Code (10-15 minutes)

Now — and only now — start writing code. Tips:

• Write clean, readable code. Use meaningful variable names. The interviewer reads your code.
• Start with the skeleton. Function signature, main loop structure, return statement. Fill in details after.
• Talk while you code. "I am initializing my hash map to track character frequencies..."
• Do not worry about perfection. A working solution with a few rough edges beats an unfinished elegant solution.

Step 6: Test and Debug (3-5 minutes)

Walk through your code with an example input. Trace every variable:

"For input [2, 7, 11, 15] with target 9: i=0, complement is 9-2=7, not in map, add {2:0}. i=1, complement is 9-7=2, found in map at index 0, return [0, 1]."

Then test edge cases mentally:

• Empty array → does my code handle it?
• Single element → does my loop execute correctly?
• All elements the same → does my logic break?

Thinking Aloud: The Hidden Skill

Interviewers evaluate your thought process as much as your code. A candidate who reaches 70% of the solution while communicating clearly will often score better than one who silently writes a perfect solution.

What to Say:

• "My first instinct is a hash map because I need O(1) lookups..."
• "Wait, this won't work for duplicates because... let me reconsider."
• "The constraint is 10^5, so I need O(n log n) or better."
• "I am going to try the greedy approach: always take the locally largest value."
• "I think this is correct but let me verify with an edge case..."

What NOT to Do:

• Sit in silence for 5 minutes (interviewer assumes you are stuck)
• Mumble incoherently
• Say "I have seen this problem before" (sounds like memorization, not skill)
• Apologize for not knowing something (just attempt it)

Common Mistakes and How to Avoid Them

Mistake 1: Off-by-One Errors

Prevention: Be explicit about whether boundaries are inclusive or exclusive. Write for i in range(n) not for i in range(1, n+1) unless you specifically need 1-indexing.

Mistake 2: Not Handling Edge Cases

Prevention: Before coding, list edge cases. Empty input, single element, maximum constraint. Handle them explicitly at the start of your function.

Mistake 3: Integer Overflow

Prevention: For large numbers, use Python (arbitrary precision) or explicitly use long long in C++. Ask the interviewer about the range of values.

Mistake 4: Modifying a Collection While Iterating

Prevention: Iterate over a copy, or build a new collection. Never list.remove(x) inside a for loop over that list.

Mistake 5: Forgetting to Return

Prevention: Write your return statement first. return result at the bottom, then fill in how result gets computed.

Rescue Strategies When Stuck

If you are completely stuck mid-interview:

1. Go back to examples. Trace through more examples. The pattern often appears with the third example.
2. Try a different data structure. If arrays are not working, try a set. If set is not enough, try a sorted structure.
3. Think backwards. Instead of building the solution from the start, think about what the answer looks like and work backwards.
4. Ask for a hint. This is completely acceptable. "I am stuck on how to avoid the quadratic comparison — could you give me a hint about the right data structure?" Better than sitting in silence.
5. Simplify the problem. Solve a simpler version first (2D → 1D, general → specific case), then generalize.

The Power of Pattern Recognition

After solving 150+ problems, you will notice that most interview problems fall into recognizable patterns. When you see a new problem, your process becomes:

1. Read the problem → "This involves finding subarrays with a constraint"
2. Match to pattern → "This is a sliding window problem"
3. Apply template → Adjust the window condition for this specific problem
4. Handle edge cases → Test with empty, single, boundary values

This is not memorization — it is building a problem-solving vocabulary, just like a chess player recognizing board positions.