The One Thing That Actually Got Me Through FAANG Interviews

Quick context (why you're writing this)

I remember staring at my screen at 2 a.m., third attempt at a medium‑level LeetCode problem, heart pounding because the clock was ticking and I kept thinking “I know the answer, I just can’t get it out.” I’d written a solution, run it, got a wrong answer, then spent another 20 minutes debugging a typo I could’ve spotted if I’d just slowed down. It felt like I was memorizing solutions instead of learning how to think. That night I realized I was missing a simple habit: I never talked through my plan before I typed a single line.

The Insight

Explain‑then‑code.

Before you touch the keyboard, say out loud (or write in plain English) exactly what your algorithm will do, step by step, as if you’re teaching a colleague who knows nothing about the problem. Only after you can verbalize the logic do you translate it into code.

Why does this work?

• It forces you to confront gaps in your understanding before you waste time on syntax errors.
• It mirrors what interviewers actually want to hear: a clear thought process, not just a working snippet.
• It catches off‑by‑one mistakes, missing edge cases, and inefficient loops early, when they’re cheapest to fix.

I was skeptical at first—felt like extra work—but after three days of forcing myself to explain first, my success rate on mock interviews jumped from ~30 % to over 80 %. The technique isn’t flashy, but it’s the single habit that turned my preparation from chaotic cramming into focused practice.

How (with code)

Let’s walk through a classic problem: Longest Substring Without Repeating Characters (LeetCode 3).

The usual mistake

def lengthOfLongestSubstring(s: str) -> int:
    max_len = 0
    for i in range(len(s)):
        seen = set()
        for j in range(i, len(s)):
            if s[j] in seen:
                break
            seen.add(s[j])
            max_len = max(max_len, j - i + 1)
    return max_len

What’s wrong here?

• The solution is correct but O(n²).
• The author probably jumped straight into nested loops because they knew the brute‑force idea and started coding without asking, “Is there a linear way?”
• In an interview, you’d spend time explaining the brute force, then realize you can do better—only after you’ve already written code that locks you into a suboptimal mindset.

Explain‑then‑code version

Step 1 – Verbalize the plan

“I’ll keep a window [left, right) that always contains unique characters. I’ll move right forward one character at a time, adding each char to a set. If the char is already in the set, I’ll shrink the window from the left until the duplicate is removed, updating the set accordingly. At each step I’ll record the window size; the largest size seen is the answer.”

Only after I can say that fluently do I write:

def lengthOfLongestSubstring(s: str) -> int:
    char_set = set()
    left = 0
    max_len = 0

    for right, ch in enumerate(s):
        # If we see a duplicate, shrink from the left until it's gone
        while ch in char_set:
            char_set.remove(s[left])
            left += 1
        char_set.add(ch)
        max_len = max(max_len, right - left + 1)

    return max_len

What changed?

• The explanation forced me to think about the sliding window invariant before I wrote a line of code.
• The while loop that shrinks the window appears naturally from the verbalized step “shrink from the left until the duplicate is removed.”
• I avoided the O(n²) trap because the linear pattern was already clear in my head.

Another quick example – “Two Sum”

Verbal plan:

“I’ll iterate through the list once. For each number, I’ll compute the complement (target - num). If I’ve already seen that complement, I’ve found the pair. I’ll store each number’s index in a hash map as I go, so look‑ups are O(1).”

Code:

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

If I’d started coding without the explanation, I might have written a double loop, missed the hash‑map optimization, or returned the values instead of indices—common slip‑ups that interviewers notice instantly.

Why This Matters

The biggest payoff isn’t just “you’ll solve more problems.” It’s that you’ll sound like the engineer they want to hire: someone who can break down ambiguity, communicate a plan, and then execute cleanly. In my own FAANG loops, interviewers repeatedly commented, “You walked me through your thinking clearly—that’s exactly what we look for.”

Explain‑then‑code also reduces anxiety. When you know exactly what you’re going to type before you type it, the whiteboard (or shared editor) feels less like a trap and more like a stage for a rehearsed demo.

Actionable Next Step

Pick one problem you’ve solved before (any difficulty). Close your editor, grab a notebook or a blank doc, and spend exactly two minutes explaining the solution out loud—no code, just the algorithm in plain English. Record yourself if you can; listen back and see if any step feels fuzzy. Only then open your editor and implement it. Do this for three problems today.

Tomorrow, repeat the habit with a new set of problems. Notice how often you catch a missing edge case or a clearer optimization before you write a line of code.

---

Your turn: Try the explain‑then‑code routine on a problem that’s been giving you trouble. Did you spot a flaw in your initial approach that you’d have missed otherwise? Drop your observation in the comments—I’m curious to hear what you discovered.