The LeetCode 100-Problem Strategy
From Zero to a Job Offer

Grinding 500 problems won't get you there — 100 of the right problems will. Here's a complete 100-problem strategy across 6 categories, plus a "topic-based absorption method" and a "mistake-log system." For engineers prepping to switch careers, jump ship, or land a new-grad role. No fluff — just what actually works.

※ The pattern categories in this article are compiled with reference to public resources like NeetCode 150, Blind 75, and Grind 75. Specific problem difficulties may change as LeetCode updates.

First, kill 3 myths

01 More is better

Wrong.

Plenty of people grind 300+ problems and still freeze in interviews — because they go about it the "read it and jump to the next one" way. Spend 15 minutes per problem, and after 500 problems you'll remember only a handful of approaches.

The right way is "few but deep": 100 problems, 3 rounds each (first pass / review pass / variant), about 1.5 hours per problem all in — 100 problems is 150 hours.

02 Start from Easy and grind in order

Also wrong.

Grind in LeetCode number order and you'll "know Two Sum, know Reverse Linked List, know Valid Parentheses" — and then still be stumped when a Sliding Window problem shows up in the interview.

The right way is "grind by topic": practice just 1 topic at a time, grind until the pattern for that topic surfaces on its own, then move to the next.

03 No need for notes — just read it

This is the biggest mistake.

People forget. Of 100 problems you can do today, you might forget 60 two weeks later. No mistake log means you never really practiced.

The core strategy —the topic-based absorption method

I didn't invent this method — it's the consensus approach in the interview-prep world. I just turned it into an executable process:

1. Pick 1 topic (e.g. Sliding Window)
2. Read 1 concept explainer (any tutorial video or article, 20-30 minutes)
3. Grind 3 Easy problems (think for 15 minutes before looking at the solution; only look if you're stuck)
4. Grind 5 Medium problems (same as above, but cap it at 25 minutes)
5. Read the solutions to 1-2 Hard problems (don't solve them yourself — learn "what the strongest solution looks like")
6. Write a "template" note for that topic (which conditions call for which solution)
7. Redo 1 problem 3 days later (test whether you've forgotten)

1 topic = 1 week. 10 topics = 10 weeks, about 100 problems total.

This is 10x more effective than randomly grinding 300 problems by number.

10 must-grind topics + recommended problem distribution

That's 100 problems in total. Doable in 10 weeks (about 1.5-2 hours a day).

Looking for a concrete problem list? I'd suggest cross-referencing the two public lists NeetCode 150 / Blind 75 — they're the industry-consensus, high-ROI problem sets.

Advanced principles —4 details no one talks about

01 Stuck after 15 minutes? Looking at the solution is fine

A point where many people get stuck — "looking at the solution is cheating."

Wrong.

Whether looking at the solution helps depends on how you look at it:

• ❌ Read it and copy it straight over — useless; you still won't be able to do it next time
• ✅ Read it, close the window, rewrite it yourself — useful
• ✅ After writing, ask yourself "why is it designed this way?" "would I still write it this way if the conditions changed?" — most useful

02 After every problem, explain it out loud once

This is the training most easily overlooked for interviews — what the interviewer wants isn't the code, it's "your ability to explain your code."

After each problem, imagine an interviewer in front of you and spend 3 minutes explaining out loud:

1. What's the problem?
2. What approach am I using? Why did I pick this one?
3. Time complexity? Space complexity?
4. What edge cases are there?
5. Is there a faster solution?

Plenty of people can write the code but can't talk through it — and the interviewer will assume you just memorized the answer.

03 Write your mistake log like this

A recommended structure (Notion / Obsidian / pen and paper all work):

## Problem number + title
LC 121. Best Time to Buy and Sell Stock

## Pattern
Single-pass + tracking min

## Where I got stuck the first time
I tried brute force O(n²) and forgot it could be O(n)

## Key idea
Track "the minimum seen so far" and, at each step, compute "how much I'd make if I sold today"

## Code template
```python
def maxProfit(prices):
    min_price = float('inf')
    max_profit = 0
    for p in prices:
        min_price = min(min_price, p)
        max_profit = max(max_profit, p - min_price)
    return max_profit
```

## Variants
- LC 122 — multiple buys and sells allowed
- LC 309 — with a cooldown

## Review history
- 2026-04-01: first pass, stuck 20 min, looked at solution
- 2026-04-15: review pass, solved in 10 min
- 2026-05-01: redo, solved straight away in 3 min

The upside of this structure — when you flip through your mistake log 3 months later, you can refresh an entire topic in 5 minutes.

04 Train until you "use templates," not until you "memorize problems"

There's a big gap between two kinds of people:

• The memorizers: "I've done this one, I remember how the code goes" — dead the moment it's a variant
• The template users: "given condition X, I use template A; given condition Y, I use template B" — solve variants just the same

How to train it: after finishing each topic, write your own decision flow for "given which conditions, apply which template."

For example (Sliding Window):

• See "contiguous subarray" + "satisfies some condition" → think sliding window
• Fixed window size → fixed-size template
• Variable window size → variable-size template
• Also need distinct elements → add a hash map to track them

With this flow, when you see a new problem you can decide which template to use within 30 seconds.

How long does it take? 3 realistic stages

Clueless → can read Easy (4 weeks)

Focus: learn the 4 topics Array + Hash Map + Two Pointers + Linked List, about 38 problems total.

At this stage — don't chase speed; build the ability to "understand the problem + write a brute force."

Can read Easy → can solve Medium (5 weeks)

Add: Sliding Window + Stack + Binary Search + Tree, about 40 problems total.

This stage is where people get stuck most easily — because Medium is no longer "rename the variables in a brute force"; it takes real thinking to find the pattern. Be patient and don't skip ahead to Hard.

Can solve Medium → ready for interviews (3 weeks)

Add: Graph + DP + Heap, about 30 problems total.

This stage isn't about "knowing everything"; what you want is "a pattern for the common problem types, and at least being able to articulate the approach for Hard."

12 weeks in total, about 3 months. At 1.5-2 hours a day, you can fit it around a full-time job.

The 5 most common give-up points

1. "I'm bad at math, I'll never get it" — 85% of LeetCode problems have nothing to do with math
2. "I can't understand Hard, giving up" — 90% of companies don't test Hard; being able to do Medium already puts you ahead of most people
3. "A month of grinding and I still can't do it — maybe I have no talent" — one month is just warm-up; it takes 6-8 weeks to get into the groove
4. "I'm slow studying on my own — should I take a course?" — 90% of people don't need a course; what they need is one or two experienced people to unblock their sticking points
5. "I can't explain things clearly in mock interviews" — then do more mocks: find a friend, find a paid one, or add me on LINE and I'll do a mock with you

One last reminder

LeetCode isn't an IQ test, it's skill training.
IQ tests come down to talent; skill training comes down to time.
It's not that you can't do it — you just haven't practiced enough yet.

This 100-problem path — I've walked it myself, and the people I've coached have walked it. It's one of the few pieces of advice that genuinely works.

The rest comes down to whether you're willing to put in 1.5 hours a day.