The Jedi Way to Talk Through Code in Interviews

The Quest Begins (The "Why")

I still remember the first time I walked out of a coding interview feeling like I’d just lost a lightsaber duel. The problem was a simple array‑rotation task, but I dove straight into typing, eyes glued to the screen, and barely said a word. When the interviewer asked, “What are you thinking right now?” I froze, mumbled something about “just trying to get it done,” and watched the seconds tick away. The feedback later? “Great coding skills, but we couldn’t follow your thought process.”

That moment stung because I knew I could solve the problem—I just hadn’t learned how to show my thinking. After a few more silent attempts, I realized the interview isn’t a solo boss fight; it’s a co‑op mission where the interviewer wants to see how you navigate the terrain. If they can’t hear your internal monologue, they have no way to gauge your problem‑solving instincts, communication style, or ability to catch mistakes early.

I went on a quest for a repeatable, low‑effort way to narrate my thinking without turning the interview into a monologue. What I found was a three‑step verbal framework that felt like unlocking a new Force power—simple, repeatable, and surprisingly effective.

The Revelation (The Insight)

The technique I now swear by is State → Plan → Execute. At each stage you say out loud exactly what you’re doing, using a tight, repeatable script. It’s not about over‑explaining; it’s about giving the interviewer a clear map of your mind.

Here’s the exact wording I use, broken down by phase:

1. State – Clarify the problem, assumptions, and constraints.
   
   
   “Okay, so we need to rotate an array to the right by k steps. I’m assuming k can be larger than the array length, so I’ll use modulo to normalize it. The array can contain any integers, and we should aim for O(n) time and O(1) extra space.”




2. Plan – Outline the high‑level approach before writing a line of code.
   
   
   “My plan is to use the three‑step reversal algorithm: reverse the whole array, then reverse the first k elements, then reverse the remaining n‑k elements. That gives us the rotation in place.”




3. Execute – Write the code while narrating each small step.
   
   
   “First I’ll compute k = k % n. Now I’ll write a helper to reverse a sub‑array between indices left and right. I’ll call it three times: reverse(0, n‑1), reverse(0, k‑1), reverse(k, n‑1).”

If you hit a snag, you simply insert a quick check‑in: “I’m not sure if this edge case works when k is zero—let me test it with a quick mental example.”

The beauty is that the script is short enough to remember, yet it forces you to vocalize the three things interviewers actually care about: understanding, strategy, and implementation.

Wielding the Power (Code & Examples)

Let’s see the framework in action with a classic interview problem: reverse a singly‑linked list.

The Silent Struggle (What NOT to Do)

def reverseList(head):

    prev = None

    while head:

        nxt = head.next

        head.next = prev

        prev = head

        head = nxt

    return prev

What happened? I typed the solution without saying a word. The interviewer saw the final code but had no idea why I chose the iterative approach over recursion, whether I considered edge cases like an empty list, or if I was just copying a snippet I’d memorized. When they asked, “Why did you pick this method?” I had to backtrack, breaking the flow and looking unprepared.

The Jedi Talk‑Through (What TO Do)

State


“We need to reverse a singly‑linked list. I’ll assume the list may be empty or have a single node. I want O(n) time and O(1) extra space, so an iterative pointer‑reversal feels right.”

Plan


“I’ll keep three pointers: prev (the node that will become the new next), curr (the node we’re processing), and next_temp to hold the original next reference before we overwrite it. We’ll walk through the list, flipping each node’s next to point to prev, then shift the pointers forward.”

Execute (with live narration)


“First I set prev = None and curr = head. Now I enter the loop. Inside, I store next_temp = curr.next so we don’t lose the rest of the list. Then I reverse the link: curr.next = prev. Next I advance prev to curr and curr to temp. When curr becomes None, we’ve processed every node, and prev holds the new head. I’ll return prev.”

The corresponding code looks exactly the same as before, but now the interviewer has heard my reasoning at each step. If I’d made a mistake—forgot to save next_temp or mixed up the pointer order—I’d have caught it while speaking, because the verbal step forces me to verify the logic before typing.

Common trap #1: Jumping straight into code without the State phase.


Result: Interviewer assumes you skipped understanding and may doubt your ability to handle ambiguous requirements.

Common trap #2: Over‑explaining irrelevant details during Plan.


Result: You waste time and look unfocused. Keep the plan to one or two sentences that capture the core algorithm.

Common trap #3: Silent coding with occasional “uh‑huh” noises.


Result: The interviewer hears nothing and can’t follow your thought process, leading to the dreaded “we couldn’t follow your thinking” feedback.

By sticking to the short State → Plan → Execute script, you avoid all three pitfalls.

Why This New Power Matters

When you verbalize your thinking, the interview turns from a black‑box coding test into a collaborative problem‑solving session. The interviewer can:

• See that you’ve clarified assumptions (reducing the chance of solving the wrong problem).
  


• Follow your logical route, which makes it easier for them to nudge you if you drift.
  


• Spot missteps early, giving you a chance to correct them before they become bugs in the final code.
  


• Gauge your communication skills—a huge factor for any team role.
  

I’ve used this framework in over a dozen interviews since that first disastrous attempt, and the shift is palpable. Interviewers now say things like, “I loved how you walked me through your reasoning,” or “Your thought process was crystal clear.” It’s not magic; it’s a repeatable habit that turns nervous silence into confident dialogue.

Your Next Mission

Pick a problem you’ve solved silently before—maybe the classic “two‑sum” or “merge intervals”—and try the State → Plan → Execute script out loud on your own. Record yourself (even just on your phone) and listen back. Notice where you naturally pause, where you forget to state an assumption, or where your plan gets vague. Refine the script until it feels like a natural conversation, not a rehearsed monologue.

Then, the next time you face a live interview, let the Force guide your words. You’ll be surprised how much smoother the conversation feels when your interviewer can actually hear your thinking.

Ready to give it a go? What problem will you tackle first with your new verbal lightsaber? May the code be with you!