Make It Work, Then Make It Right, Then Make It Fast: The FAANG Interview Prep Like a Marvel Hero's Journey

#interview #career #programming #softwareengineering

The Quest Begins (The "Why")

I still remember the first time I stared at a whiteboard during a mock FAANG interview. The interviewer asked, “Given an array of integers, return the length of the longest sub‑array with sum equal to k.” My brain went blank. I started scribbling fancy optimizations—hash maps, prefix sums, sliding windows—before I even knew if my basic idea would work. Ten minutes later I had a tangled mess of code, a dozen syntax errors, and the interviewer’s polite smile that said, “Nice effort, but let’s try again.”

I walked away feeling like I’d just lost a boss fight in a game I hadn’t even learned the controls for. The problem wasn’t that I lacked knowledge; it was that I was trying to win the fight before I even knew how to swing the sword. I needed a simpler, repeatable battle plan—something I could rely on when nerves kicked in and the clock was ticking.

The Revelation (The Insight)

After a few brutal weeks of grinding LeetCode problems, I stumbled onto a mantra that changed everything:

“Make it work, then make it right, then make it fast.”

It sounded almost too simple, but the moment I said it out loud, the pressure lifted. The idea is to treat each coding problem as three distinct phases, not a single frantic sprint:

Make it work – Get any correct solution, no matter how inefficient. Focus on clarity, not performance.
Make it right – Clean up the code, handle edge cases, and ensure readability.
Make it fast – Optimize only after you have a correct, readable baseline.

This mirrors the way a Marvel hero learns their powers: first they survive the initial encounter (make it work), then they learn to control their abilities (make it right), and finally they unleash their full potential (make it fast).

The beauty of this technique is that it forces you to externalize your thought process before you dive into syntax. When you verbalize “I’m just going to try the brute‑force approach first,” you give yourself permission to be imperfect. That permission is the antidote to interview paralysis.

Wielding the Power (Code & Examples)

Let’s walk through a classic problem: “Given an array of integers, find the maximum sum of any contiguous subarray.” (AKA Kadane’s algorithm).

❌ What NOT to do – Premature Optimization

def max_subarray(nums):
    # Trying to be clever from the start
    best = float('-inf')
    for i in range(len(nums)):
        current = 0
        for j in range(i, len(nums)):
            current += nums[j]
            if current > best:
                best = current
                # …and then I start fiddling with indices to shave off O(1) …
    return best

What went wrong? I dove straight into the O(n²) solution, got tangled in index gymnastics, and forgot to test the simplest case (nums = [-2,1,-3,4,-1,2,1,-5,4]). The interviewer watched me stare at the screen, second‑guessing every line, while the clock ticked down.

✅ The “Make it work → right → fast” Approach

Phase 1 – Make it work (brute force, O(n²))

def max_subarray(nums):
    # Simple, obvious solution: check every start/end pair
    max_sum = float('-inf')
    for i in range(len(nums)):
        for j in range(i, len(nums)):
            # sum of slice i..j
            s = sum(nums[i:j+1])
            if s > max_sum:
                max_sum = s
    return max_sum

Why this works: It’s easy to write, easy to explain, and I can verify it with a few examples on the spot. I say out loud, “I’m just checking every possible sub‑array and keeping the biggest sum.” The interviewer nods; I’ve bought myself time and confidence.

Phase 2 – Make it right (clean up, handle edge cases)

def max_subarray(nums):
    if not nums:               # edge case: empty list
        return 0
    max_sum = float('-inf')
    for i in range(len(nums)):
        for j in range(i, len(nums)):
            s = sum(nums[i:j+1])
            if s > max_sum:
                max_sum = s
    return max_sum

I added a guard clause and renamed variables for readability. No logic changed—just hygiene.

Phase 3 – Make it fast (optimize to O(n))

Now that I have a correct, readable base, I can replace the inner loop with Kadane’s idea:

def max_subarray(nums):
    if not nums:
        return 0
    current = best = nums[0]
    for x in nums[1:]:
        # either extend the previous subarray or start fresh at x
        current = max(x, current + x)
        best = max(best, current)
    return best

What changed? I kept the same function signature, the same edge‑case check, and the same return value. The only difference is the algorithm inside—a linear scan that’s now optimal.

Traps to Avoid

Trap	What it looks like	Why it hurts	How to dodge it
Optimizing before correctness	Jumping straight to hash maps or binary search	You introduce bugs that are hard to spot under stress	State aloud: “Let me get a working version first.”
Skipping the “make it right” step	Leaving cryptic one‑liners or unclear variable names	Interviewer can’t follow your reasoning, even if it works	After the brute force, rename variables, add a comment, handle empty input.
Trying to impress with fancy tricks	Using bit‑wise hacks or obscure library calls	Distracts from core problem solving; can backfire if you misapply	Save tricks for the “make it fast” phase only after you’ve verified correctness.

Why This New Power Matters

Adopting the “make it work → right → fast” mantra turned my interview prep from a frantic scramble into a repeatable ritual. I stopped dreading the whiteboard and started looking forward to the chance to show my process.

Confidence boost: Knowing I have a fallback (the brute force) eliminates the fear of blanking out.
Clear communication: Interviewers hear my thought process in real time, which often scores more points than a silent, perfect solution.
Time management: I allocate a fixed chunk (≈2‑3 minutes) for the first phase, then iterate. I never run out of time polishing something that isn’t even correct yet.
Transferable skill: This mindset works beyond coding interviews—debugging, system design, even writing production code.

In short, I went from feeling like a side‑kick scrambling for a gadget to feeling like the hero who knows their powers and when to unleash them.

Your Turn – The Challenge

Pick any Medium LeetCode problem you’ve avoided because it “looks too hard.” Right now, set a timer for 10 minutes and run through the three phases:

Make it work – Write the simplest brute‑force solution you can think of.
Make it right – Clean it up, name variables clearly, handle edge cases.
Make it fast – Refine to an optimal approach, explaining each step out loud.

When the timer dings, look at what you’ve built. If you’ve got a correct solution, even if it’s still O(n²), you’ve already won the battle.

Ready? Grab your favorite beverage, open that LeetCode tab, and start the quest. I’ll be cheering you on from the comment section—let’s hear how your first “make it work → right → fast” run went! 🚀