How I Nailed FAANG Interviews in 90 Days With One Simple Habit

Quick context (why you're writing this)

I was staring at my screen at 2 a.m., third failed mock interview in a row, feeling like I’d memorized every LeetCode solution but still froze when the interviewer asked, “Walk me through your approach.” I knew the answers, but I couldn’t show my thinking. It hit me: I was preparing like I was studying for a multiple‑choice test, not like I was going to have a conversation. That realization changed everything.

The Insight

The single technique that turned my prep around was talking through my solution out loud before I wrote a single line of code — and then continuing to narrate as I typed. I call it the “talk‑through.” It forces you to externalize your thought process, surface hidden assumptions, and prove you can communicate under pressure — exactly what FAANG interviewers are listening for.

Why does it work? Interviewers aren’t just checking if you can get the right answer; they’re evaluating how you break down a problem, how you handle ambiguity, and whether you can stay calm while thinking on your feet. When you verbalize each step, you make those skills visible. Plus, hearing yourself explain often reveals gaps you’d miss in silent coding.

How (with code)

Let’s take a classic easy‑medium problem: Given an integer array nums and an integer target, return indices of the two numbers that add up to target. (LeetCode “Two Sum”)

The mistake most people make

They jump straight into coding:

def two_sum(nums, target):
    for i in range(len(nums)):
        for j in range(i+1, len(nums)):
            if nums[i] + nums[j] == target:
                return [i, j]

What’s wrong? No clarification of edge cases, no mention of time complexity, and the interviewer has no idea if you considered a hash map solution. You look like you’re brute‑forcing without thinking.

The talk‑through version

Step 1 – Clarify (out loud)

“So we have an array of integers and a target sum. I need to return the indices of the two numbers that add up to the target. I assume there’s exactly one solution and I can’t use the same element twice. Is it okay to return the indices in any order?”

Step 2 – State the approach (out loud)

“I’ll use a hash map to store each number’s complement (target – num) as I iterate. That way I can check in O(1) if I’ve already seen the number I need.”

Step 3 – Walk through the algorithm (out loud, line by line)

“I’ll create an empty dictionary called seen. Then I’ll loop over the array with enumerate so I have both index i and value num. For each num, I calculate complement = target - num. If complement is already in seen, I’ve found the pair and can return [seen[complement], i]. Otherwise, I store num in seen with its index and continue.”

Step 4 – Code while narrating

def two_sum(nums, target):
    # hash map: value -> index
    seen = {}
    for i, num in enumerate(nums):
        complement = target - num
        if complement in seen:          # "Found the match!"
            return [seen[complement], i]
        seen[num] = i                   # "Remember this number for later"
    # The problem guarantees a solution, so we never reach here.

Step 5 – Verify complexity (out loud)

“We touch each element once, so time is O(n). The hash map holds at most n entries, so space is O(n).”

Notice how every line of code is preceded by a sentence that explains why it’s there. If you get stuck, you can backtrack to the last spoken step and see where the logic broke.

What NOT to do

• Don’t start coding before you’ve spoken the plan. You’ll miss the chance to catch misunderstandings early.
• Don’t mute yourself while typing. Silence makes it look like you’re just copying from memory.
• Don’t skip the complexity analysis. Interviewers often ask for it explicitly; if you’ve already said it out loud, you’re ready.

Why This Matters

After I made the talk‑through a non‑negotiable part of every practice session, my mock interview scores jumped from 3/10 to 8/10 within two weeks. Interviewers started commenting, “You explained your thinking really clearly,” which is exactly the signal they want. The habit also reduced my anxiety: knowing I’d verbalized the plan gave me a safety net if I blanked mid‑code.

It’s not a magic bullet — you still need to know data structures and algorithms — but it amplifies whatever knowledge you have by making it visible and audible. The best part? It costs nothing but a few extra seconds of talking.

Actionable next step

Pick any problem you’ve solved before (maybe an easy one you’re comfortable with). Set a timer for 15 minutes. Before you open your editor, spend the first two minutes talking through the problem exactly as you would to an interviewer: clarify assumptions, name your approach, and walk through each step out loud. Then code while continuing to narrate. Record yourself on your phone (audio only is fine). When the timer ends, listen back and note any places where you hesitated or missed a detail. Do this once a day for the next week, gradually moving to harder problems.

Give it a try and see how your confidence shifts when you’re no longer just coding silently, but actually conversing with the interviewer. What’s the first problem you’ll run through with the talk‑through method? Let me know in the comments — I’m curious to hear how it feels for you.