How to Explain Your Approach to an Interviewer

Feb 19, 20269 min read

Solving the problem is only half the battle. The other half is communicating your thought process clearly. Interviewers evaluate how you think, not just whether you get the right answer. This guide covers the 4-step framework, what interviewers look for, and templates you can use in any coding interview.

The 4-Step Framework

Step 1: Understand

Before writing any code, confirm you understand the problem. Restate it in your own words, identify inputs and outputs, and ask clarifying questions. This shows you think before acting.

What to say:

"So if I understand correctly, we have an array of integers and need to find the longest contiguous subarray where the sum equals K. Can the array contain negative numbers? What should we return if no such subarray exists?"

Step 2: Plan

Outline your approach before coding. State the pattern or algorithm, mention time and space complexity, and walk through a small example. If you have multiple ideas, compare them briefly and explain why you chose one.

What to say:

"I will use a hash map to store prefix sums. As we iterate, we check if (currentSum - K) exists in the map; if so, we have found a subarray with sum K. This runs in O(n) time and O(n) space. Let me trace through with [1, 2, 3] and K=3..."

Step 3: Implement

Code your solution while narrating key decisions. Name variables clearly, add brief comments for non-obvious logic, and keep talking. If you hit a snag, say what you are thinking instead of going silent.

What to say:

"I will initialize the map with prefix 0 at index -1 so we handle subarrays starting at index 0. Now I am iterating and updating the prefix sum..."

Step 4: Review

After coding, walk through your solution with a test case. Check edge cases (empty input, single element, duplicates). State the complexity again and mention possible optimizations or follow-ups.

What to say:

"Let me verify with [1, -1, 1, 1] and K=1. We should get length 4. For edge cases: empty array returns 0, and if no subarray exists we return 0. We could optimize space if we only need the count, but the current solution is clear."

What Interviewers Look For

Problem decomposition: Can you break a complex problem into smaller parts?
Pattern recognition: Do you recognize when to use Sliding Window, Two Pointers, or Prefix Sum?
Trade-off awareness: Do you understand time vs. space and when to optimize?
Collaboration: Do you ask for feedback, accept hints gracefully, and stay calm under pressure?
Code quality: Is your code readable, with sensible names and structure?

Communication Templates

When you need a moment to think:

"Let me think through this for a moment." / "I want to consider the edge cases first."

When you have two approaches:

"I see two options: brute force in O(n²) or a hash map in O(n). The hash map is better for large inputs, so I will go with that."

When you get stuck:

"I am stuck on the edge case. Could you give me a hint?" / "I think I need to handle the empty subarray differently."

When you find a bug:

"I see the issue — I am off by one in the loop. Let me fix that." / "Good catch. I need to handle the case when left exceeds right."

Common Mistakes to Avoid

Jumping to code: Always restate the problem and outline your approach first.
Going silent: Even if you are thinking, say something. "I am considering the base case" is better than 30 seconds of silence.
Ignoring hints: If the interviewer gives a hint, acknowledge it and use it. Do not dismiss or ignore.
Over-explaining: Be concise. State the key idea, then code. Do not narrate every line.

Practice pattern recognition

The faster you identify the right pattern, the more time you have to explain and implement.

Take the Pattern Quiz