LeetCode and the Matrix: A Beginner's Guide to Mastering the Feynman Technique

The Quest Begins (The “Why”)

I still remember the first time I opened LeetCode after a boring Saturday morning. I stared at the “Easy” tag, picked Two Sum, and dove straight into the editor. Fifteen minutes later I was staring at a red error, my coffee gone cold, and I felt like I’d just tried to dodge bullets in a hallway without knowing where the gun was pointed. I kept thinking, “If I just keep grinding, it’ll click.” Spoiler: it didn’t.

I was stuck in a loop of read → code → fail → Google → copy‑paste → feel guilty. The problems started to feel like bosses in a dark RPG that I could never beat because I never learned the pattern of their attacks. I needed a quest‑log, a way to internalize what I was doing instead of just memorizing syntax.

The Revelation (The Insight)

The breakthrough came when I stumbled on a study tip that sounded almost too simple: explain the solution out loud, as if you’re teaching a total beginner. It’s the Feynman technique, repurposed for coding interviews. The magic isn’t in writing more code; it’s in forcing your brain to turn fuzzy intuition into crystal‑clear steps.

When you articulate the problem in plain English, you expose the gaps in your understanding before you even type a single semicolon. Those gaps become the exact places where you’d otherwise get stuck, stare at a stack trace, and question your life choices. By filling them first, the actual coding feels like filling in a coloring book — you already know the picture, you just need to stay inside the lines.

Here’s the exact wording I now use for every LeetCode problem I tackle:

“Explain the problem to a friend who knows nothing about programming:

1. What are we given? (input format, constraints)
2. What do we need to return? (output format)
3. What is the core idea or trick? (the “aha!”)
4. Walk through the solution step‑by‑step, using concrete numbers.
5. State the time and space complexity in plain terms.

If I can answer those five points without looking at my notes, I know I truly get it. Only then do I open the editor.

Wielding the Power (Code & Examples)

Let’s see this in action with a classic Easy problem: Contains Duplicate (LeetCode 217).

❌ The Old Way – Jump Straight to Code

def containsDuplicate(nums):
    seen = set()
    for n in nums:
        if n in seen:
            return True
        seen.add(n)
    return False

I wrote this after a quick glance at the description. It works, but I had no idea why a set is the right tool. When the interviewer asked, “What if the array is huge?” I stumbled, because I hadn’t internalized the trade‑off between time and space.

✅ The Feynman Way – Explain First, Then Code

Step 1‑5 explanation (out loud or on paper):

1. We’re given an array of integers.
2. We need to return True if any value appears at least twice, otherwise False.
3. The core idea: we can track what we’ve seen so far; if we see a number again, we have a duplicate.
4. Walk‑through:
   • Start with an empty “seen” container.
   • Look at the first number, 1 → not in seen, add it.
   • Second number, 2 → not in seen, add it.
   • Third number, 1 → already in seen, so we can immediately return True.
   • If we finish the loop without a hit, return False.
5. Complexity: Each lookup/insert in a set is O(1) on average, so we scan the list once → O(n) time. The set may store up to n elements → O(n) space.

Now the code feels inevitable:

def containsDuplicate(nums):
    """
    Returns True if any element appears at least twice in nums.
    Uses a hash set for O(1) average‑time look‑ups.
    """
    seen = set()                     # container for numbers we have visited
    for n in nums:                   # examine each number once
        if n in seen:                # duplicate found?
            return True              # early exit – we’re done
        seen.add(n)                  # remember this number for later checks
    return False                     # no duplicates after full scan

Notice the docstring and the inline comments? They’re not just for readability; they’re the verbalization I did before writing a single line. The code is now a direct transcription of my explanation, which means I can defend every line if asked.

Common trap to avoid:

• Writing the explanation after the code. That turns it into a post‑hoc justification and does nothing to uncover hidden misunderstandings.
• Skipping the “core idea” step. If you can’t name the trick (hash‑set lookup, two‑pointer sweep, etc.), you’re likely memorizing a pattern rather than understanding it.

Why This New Power Matters

Since I adopted the “explain‑first” habit, my LeetCode sessions feel less like grinding and more like uncovering secrets. I solve problems faster because I spend less time staring at a blank screen and more time thinking. When I walk into an interview, I can articulate my approach before I write a single line, which instantly signals confidence to the interviewer.

The best part? The technique scales. Whether you’re tackling Easy array tricks or medium‑difficulty DP, the same five‑question script forces you to confront the essence of the problem. You start recognizing patterns across questions — “Oh, this is just a sliding‑window version of the two‑sum trick I used last week.” That pattern recognition is the real XP gain.

Your Turn – The Challenge

Pick any Easy problem you’ve avoided because it felt “boring” (I’m looking at you, Valid Parentheses). Spend five minutes explaining it out loud using the five‑question script above — no coding allowed. Then, open your editor and write the solution only after you can give that explanation without hesitation.

Come back and drop a comment with the problem you chose and how the explanation changed your coding experience. I’m betting you’ll feel like you just leveled up in the Matrix — dodging bugs with style.

Happy hacking, and may your explanations be as clear as a Neo‑style slow‑mo dodge! 🚀