How to Crush FAANG Interviews in 3 Months — Like Neo Learning Kung Fu

The Quest Begins (The “Why”)

I still remember the night I stared at my screen after a failed mock interview, heart pounding like I’d just lost a boss fight in a retro arcade game. I could solve the problems on LeetCode when I was alone, but the moment an interviewer asked me to “walk me through your thinking,” my mind went blank. I’d start typing, realize I’d missed an edge case, backtrack, and end up sounding like I was making it up as I went along. The frustration was real: I knew the algorithms, I could write the code, but I couldn’t communicate my thought process under pressure.

That’s when I realized the dragon I needed to slay wasn’t a lack of knowledge — it was the inability to show that knowledge in real time. If I could learn to narrate my solution as naturally as I explain a bug to a teammate, the interview would feel less like an interrogation and more like a collaborative problem‑solving session.

The Revelation (The Insight)

The technique that turned things around for me is deceptively simple: talk through every step of your solution out loud, using a fixed script of phrasing, before you write a single line of code. I call it the “Talk‑Through” technique.

The exact wording I use (and have my practice partners repeat) is:

1. Restate the problem in my own words.
2. Clarify inputs, outputs, and constraints (ask about edge cases if anything is vague).
3. State the high‑level approach (e.g., “I’ll use a sliding window because we need O(n) time”).
4. Walk through the algorithm step‑by‑step, describing what each variable represents and why we update it.
5. Mention time and space complexity before coding.
6. Write the code, narrating each line as I type.
7. Run through a small example (or two) to verify correctness.
8. State the final complexity again and mention any possible optimizations.

Why does this work?

• It forces you to uncover gaps before you commit to code. If you can’t explain why you’re moving a pointer, you probably haven’t thought it through.
• It mirrors what interviewers actually want — they’re listening for structured thinking, not just a correct answer.
• It reduces panic. Having a script gives you a mental safety net; you’re not scrambling for the next phrase, you’re following a rehearsed routine.
• It builds communication muscle. The more you verbalize, the more natural it feels, and the less you rely on rote memorization.

I first tried this on a medium‑difficulty LeetCode problem (“Longest Substring Without Repeating Characters”). The first attempt was a mess: I dove into code, got stuck on the hashmap update, and backtracked three times. After I forced myself to follow the Talk‑Through script, the solution flowed. I explained the window, the left/right pointers, why we store the last index of each character, and then wrote the code in one smooth pass. The interviewer nodded, smiled, and said, “That’s exactly how we like to hear candidates think.”

Wielding the Power (Code & Examples)

Let’s look at a concrete before/after.

The Struggle (What NOT to Do)

def lengthOfLongestSubstring(s):
    # I’ll just start coding and see what happens
    seen = {}
    max_len = 0
    start = 0
    for i, ch in enumerate(s):
        if ch in seen and seen[ch] >= start:
            start = seen[ch] + 1
        seen[ch] = i
        max_len = max(max_len, i - start + 1)
    return max_len

What went wrong?

• No restatement of the problem.
• No mention of constraints (e.g., empty string, all same characters).
• No complexity analysis spoken aloud.
• The code is correct, but the silent journey leaves the interviewer guessing whether you understood why each line exists.

The Victory (Talk‑Through in Action)

Step 1 – Restate

“So we need to find the length of the longest substring that doesn’t contain any repeating characters. The input is a string, and we should return an integer.”

Step 2 – Clarify

“If the string is empty, the answer is zero. If all characters are unique, the answer is the length of the string.”

Step 3 – High‑level approach

“I’ll use a sliding window with two pointers, left and right. A hash map will store the most recent index of each character we’ve seen. When we encounter a duplicate inside the current window, we move left just past the previous occurrence.”

Step 4 – Walk through algorithm

“As right scans each character, we check the map. If the character isn’t in the map or its last index is before left, it’s safe to expand the window. Otherwise, we shrink the window by setting left to last_index[ch] + 1. After each step we update the map with the current index and compute right - left + 1 as a candidate for the maximum length.”

Step 5 – Complexity

“This runs in O(n) time because each character is processed once, and O(k) space where k is the size of the character set (at most O(n)).”

Step 6 – Code (narrated)

def lengthOfLongestSubstring(s: str) -> int:
    # Map char -> most recent index
    last_idx = {}
    max_len = 0
    left = 0                     # start of the sliding window

    for right, ch in enumerate(s):
        # If ch was seen inside the current window, jump left forward
        if ch in last_idx and last_idx[ch] >= left:
            left = last_idx[ch] + 1
        # Update the latest position of ch
        last_idx[ch] = right
        # Window size is right - left + 1
        max_len = max(max_len, right - left + 1)

    return max_len

While typing, I’d say:

“Now I create an empty dictionary to store the last index we saw each character. left marks the start of our current window. As we iterate with right, if the current character is already in the window (last_idx[ch] >= left) we move left just after its previous occurrence. Then we update the map with the current index and compute the window size, keeping track of the biggest we’ve seen.”

Step 7 – Verify with an example

“Let’s try s = 'abca'.

• right=0, ch='a': not in map → map{a:0}, window size 1, max=1.
• right=1, ch='b': map{a:0,b:1}, size 2, max=2.
• right=2, ch='c': map{a:0,b:1,c:2}, size 3, max=3.
• right=3, ch='a': a is in map at index 0, which is >= left (0) → left becomes 1. Update map{a:3}. Window is indices 1‑3 → size 3, max stays 3.”

Step 8 – Final recap

“So the algorithm returns 3, which is correct. Time O(n), space O(min(n, charset)).”

Notice how the exact same code appears, but the surrounding narration transforms it from a silent solution into a transparent thought process.

Why This New Power Matters

After three months of daily Talk‑Through practice — 20 minutes a day, picking a random LeetCode medium, recording myself, and listening back — I went from freezing in mock interviews to getting offers from three FAANG‑tier companies. The technique didn’t just improve my scores; it changed my mindset. I stopped seeing the interview as a test of memorized tricks and started seeing it as a conversation where I could showcase my problem‑solving style.

The best part? The skill transfers beyond interviews. Explaining your reasoning out loud makes you a better teammate, a clearer presenter, and a more confident engineer.

Your Turn — Embark on the Quest

Here’s your actionable next step, right now:

1. Pick one LeetCode medium problem you’ve solved before but never explained aloud.
2. Set a timer for 20 minutes.
3. Follow the Talk‑Through script exactly as written, recording your voice (your phone’s memo app works fine).
4. Play it back. Notice where you hesitated, where you skipped a step, or where you got vague.
5. Repeat with a new problem tomorrow.

Do this for three weeks, and you’ll feel the same shift I did — like Neo finally seeing the code behind the matrix.

What’s the first problem you’ll tackle? Drop it in the comments and let’s cheer each other on! 🚀

Comments

[Swapnoneel Saha]

the fixed talk through script is a useful way to reduce pressure. i would add a second practice round where a partner asks one new constraint or changes the input size, because interviews often test how the plan adapts. track missed edge cases and unclear explanations in a small log, then repeat those problem types later. this keeps practice focused on communication and reasoning, not only speed.