My LeetCode Workflow: Stop Memorizing, Start Solving

Jamie67 Novice 1h ago Updated Jul 26, 2026 291 views 8 likes 2 min read

Brute-forcing a medium-difficulty LeetCode problem with nested loops and index errors is a rite of passage, but it's a terrible way to actually learn. I spent way too long in a cycle of "solving" a problem only to realize I was just memorizing the solution pattern rather than understanding the logic. The breakthrough happened when I stopped treating coding like a typing exercise and started treating it like a teaching exercise.

I adopted a specific active recall loop that fundamentally changed how I approach technical interviews and daily coding. The logic is simple: explain the concept, step away, then rebuild from scratch.

The Active Recall Workflow

This is a practical tutorial for anyone stuck in the "easy problem plateau." Instead of just hitting 'Submit' and moving on, follow these steps:

1. Initial Solve: Solve the problem using any method.
2. The Verbal Audit: Close the IDE. Explain the solution out loud as if you're onboarding a junior dev. You must articulate every variable change and edge case.
3. The Buffer: Step away for 10 to 30 minutes. This break is non-negotiable; it clears the short-term "buffer" of the code.
4. The Blind Rebuild: Re-solve the problem from scratch. If you get stuck, you are only allowed to look at your own verbal explanation, never the code.

This process exposes "illusion of competence"—that feeling where you think you understand a solution because the code looks logical, but you can't actually derive it yourself.

Real-World Application: 3Sum

To show the difference, look at how my approach shifted. Initially, I was writing O(n³) disasters because I was just trying to make the test cases pass.

The "Brute Force" Mess:

def threeSum(nums):
    res = []
    nums.sort()
    for i in range(len(nums)):
        for j in range(i+1, len(nums)):
            for k in range(j+1, len(nums)):
                if nums[i] + nums[j] + nums[k] == 0:
                    triple = [nums[i], nums[j], nums[k]]
                    if triple not in res: # Inefficient O(n) check
                        res.append(triple)
    return res

The issue here isn't just the time complexity; it's the lack of a mental model. By applying the "explain and delay" method, I forced myself to visualize the two-pointer movement on a sorted array.

The Optimized Result:

def threeSum(nums):
    nums.sort()
    res = []
    n = len(nums)
    for i in range(n - 2):
        # skip duplicate fixed numbers
        if i > 0 and nums[i] == nums[i-1]:
            continue
        left, right = i + 1, n - 1
        while left < right:
            total = nums[i] + nums[left] + nums[right]
            if total < 0:
                left += 1
            elif total > 0:
                right -= 1
            else:
                res.append([nums[i], nums[left], nums[right]])
                while left < right and nums[left] == nums[left + 1]:
                    left += 1
                while left < right and nums[right] == nums[right - 1]:
                    right -= 1
                left += 1
                right -= 1
    return res

Using this as a deep dive into my own learning gaps made the difference between struggling with a Medium problem for two hours and solving it in ten minutes. It's a slower process at first, but it builds actual intuition.

careerprogramminginterviewWorkflowAI Implementation

All Replies (4)

S
SoloSmith Expert 9h ago
Do you usually track the time complexity of your brute force before optimizing it?
0 Reply
A
AveryPilot Novice 9h ago
I started sketching patterns on a whiteboard first, helps a ton with the logic.
0 Reply
M
MaxOwl Intermediate 9h ago
Used to stare at the screen for hours before realizing I just needed a pen and paper.
0 Reply
J
Jamie89 Intermediate 9h ago
@MaxOwl Same here. Sketching out the logic first saves so much time before actually typing a single line.
0 Reply

Write a Reply

Markdown supported