The Matrix: Communicating Your Thought Process in Coding Interviews

The Quest Begins (The “Why”)

I still remember my first technical interview like it was yesterday. The interviewer handed me a whiteboard marker and a simple problem: “Given an array of integers, return the indices of the two numbers that add up to a specific target.” My heart raced. I grabbed the marker, started writing code, and… fell silent. I was so focused on getting the syntax right that I forgot to say anything out loud. Ten minutes later I had a working solution, but the interviewer looked puzzled. “I didn’t follow your thinking,” they said. “Can you walk me through how you arrived at that?” I stumbled, tried to back‑track, and the moment slipped away. I left the room feeling like I’d solved the puzzle but missed the point entirely.

That experience taught me a hard lesson: solving the problem is only half the interview. The other half is showing how you think. If you stay quiet, the interviewer can’t see your problem‑solving process, and they’ll assume you’re just coding on autopilot.

The Revelation (The Insight)

After a few more painful interviews, I stumbled on a simple, repeatable technique that changed everything: The 3‑Part Verbal Framework. It’s nothing fancy — just a script you run in your head before you touch the keyboard. Here’s the exact wording I use, word for word:

1. Restate the problem – “So, just to make sure we’re on the same page, we need to find two numbers in the array whose sum equals the target, and return their indices.”
2. Outline your high‑level plan – “I’m going to use a hash map to store each number’s complement as I iterate. That lets us check in O(1) time whether we’ve already seen the partner we need.”
3. Walk through the code line by line, explaining why – (as you write each line, say what it does and why you chose it)

That’s it. No jargon, no fluff, just three clear steps that turn a silent coding session into a guided tour of your brain.

Wielding the Power (Code & Examples)

The “Before” – Silent Coding (What NOT to Do)

def two_sum(nums, target):
    d = {}
    for i, n in enumerate(nums):
        if target - n in d:
            return [d[target - n], i]
        d[n] = i

What went wrong? I dove straight into the solution. I never told the interviewer why I chose a hash map, or what the loop was accomplishing. If they missed a detail, they had no way to know whether I was guessing or reasoning.

The “After” – Using the 3‑Part Verbal Framework

Interviewer: “Given an array of integers, return the indices of the two numbers that add up to a specific target.”

Me (Step 1 – Restate): “Just to confirm, we need to find two distinct indices i and j such that nums[i] + nums[j] = target, and return them as a list.”

Me (Step 2 – Outline): “I’ll solve this in one pass with a hash map. As I iterate, I’ll store each number’s index. For the current number x, I’ll check whether target − x is already in the map. If it is, I’ve found the pair; if not, I’ll add x to the map and keep going.”

Me (Step 3 – Code & Explain):

def two_sum(nums, target):
    # Step 3a: create an empty dictionary to hold value→index
    complements = {}

    # Step 3b: loop through the list with both index and value
    for i, num in enumerate(nums):
        # Step 3c: compute the value we need to reach the target
        needed = target - num

        # Step 3d: have we already seen that needed value?
        if needed in complements:
            # Step 3e: yes! return the earlier index and the current one
            return [complements[needed], i
        # Step 3f: otherwise, store the current number, i]  # <-- note: I’d actually write the variable name here

        # Step 3g: store the current number for future look‑ups
        complements[num] = i

(As I write each line, I say the comment out loud.)

Why this works:

• The interviewer hears my reasoning before I write anything, so they know I’m not just typing blindly.
• Each line is justified, which shows I understand the trade‑offs (O(n) time, O(n) space).
• If I make a mistake, they can pinpoint exactly where my logic went off track, instead of guessing whether I slipped on syntax or on the algorithm.

Common Traps to Avoid

Trap	What it looks like	Why it hurts	Fix
Jumping straight into code	No restatement, no plan, just start typing.	Interviewer can’t follow your thought process; they assume you’re guessing.	Always do Step 1 and Step 2 before touching the keyboard.
Over‑explaining irrelevant details	Spending two minutes talking about your favorite language features or the history of hash tables.	Wastes time and signals you can’t stay focused on the problem at hand.	Keep your explanation tightly coupled to the current step; if you go off‑track, bring it back with “Getting back to the problem…”.
Silent debugging	You hit a bug, stare at the board, and mutter nothing while you erase and rewrite.	The interviewer loses the signal of how you troubleshoot.	Vocalize: “I’m seeing an off‑by‑one here; let me check the loop bounds.”
Using vague placeholders	Saying “I’ll just put something here” without stating what.	Shows uncertainty; you lose credibility.	Be specific: “I’ll store the current number as the key and its index as the value.”

Why This New Power Matters

When you adopt the 3‑Part Verbal Framework, the interview stops being a black‑box coding test and becomes a conversation about problem‑solving. You’ll notice three concrete shifts:

1. Clarity – The interviewer can map each line of code to a reason you gave earlier, which builds trust.
2. Confidence – Knowing you have a script to fall back on reduces the panic that comes with a blank whiteboard.
3. Signal Strength – You demonstrate core hiring competencies: analytical thinking, communication, and the ability to translate ideas into concrete steps.

In my own interviews after I started using this framework, I went from “nice solution, but I didn’t follow your thinking” to “great explanation, you really broke it down cleanly.” The difference wasn’t the algorithm — it was the talk.

Your Turn – A Quick Challenge

Grab a timer, pick a simple LeetCode‑style problem (e.g., “reverse a string” or “check if a string is a palindrome”), and spend exactly two minutes explaining your approach out loud before you write a single line of code. Use the three steps: restate, outline, then walk through. Record yourself if you can — listen back and notice where you hesitated or where you added extra fluff.

Do this a few times a week, and you’ll find that the whiteboard stops feeling like a monster and starts feeling like a stage where you get to show off how you think.

Ready to give it a shot? What problem are you going to tackle first? Drop your choice in the comments — I’d love to hear how it goes!