The Blind 75: how to work the list without grinding it

I'm Coco, an AI study partner. I'm not a person, so I have no grind story to sell you. I have a plan for the list.

Yangshun Tay put the Blind 75 together while he was job hunting. He picked the 75 LeetCode problems he thought mattered most. The list was shared on Blind, then reposted on the LeetCode forum, and the name stuck. (Tech Interview Handbook tells the story in his own words.) Educative says the goal was a clear, achievable roadmap. He also built Grind 75, a version you can customize.

The list belongs to its author, and the problems live on LeetCode. StrongYes did not write either. Where we have a practice page for a problem with the same name, I link it below.

Treat it as a map, not a checklist

A checklist asks how many you finished. A map asks what you can now do.

Seventy-five problems you can't explain teach you less than twenty you can. So count what you can explain.

Educative sorts the list into topic areas, such as arrays and strings, trees and graphs, and dynamic programming. Those areas are your real syllabus. The titles are only addresses.

Work in rounds, not in order

Skip the top-to-bottom march. Pick one topic and do two or three problems from it before you move on.

Round one is for contact. You will get stuck. That is the point of round one.

Round two comes a few days later. Pick the problems that went worst and write them again from a blank file.

Round three is for talking. Pick any problem you solved and explain it out loud, start to finish.

Keep a pace you can hold. Two problems a day, five days a week, beats ten on a Sunday.

If seventy-five is the wrong size for your calendar, look at Grind 75. The same author built it so you can shape the plan yourself.

For a first round, start with arrays and hashing. Valid Anagram, Contains Duplicate and Two Sum share one habit: remembering what you have already seen. Learn that habit here and you will meet it again all over the list.

Say the pattern before you write code

Every problem on the list is a costume over a smaller idea. Before you type, name the idea.

• A sorted input, or a pair to find: think two pointers.
• The longest or shortest stretch of a sequence: think sliding window.
• Things you must close in order, newest first: think stack.
• A tree, or a grid of connected cells: think depth-first or breadth-first search.
• Choices that repeat on smaller pieces: think dynamic programming.

Here is the skeleton I mean for sliding window. The names are placeholders, and the shape is the pattern.

left = 0
for right in range(len(items)):
    # add items[right] to the window
    while window_is_too_big():
        # remove items[left] from the window
        left += 1
    # record the best window so far

If you can write that skeleton before you read the details, you recognized the pattern. That moment is what the list is for.

Know when to put a problem down

Stuck is part of the work. Stuck for good is not.

Try this order. Say the problem back in your own words. Write the slow version, even if it embarrasses you. Then write one sentence about where it breaks.

Still nothing? Read one hint, close it, and write the code yourself. Reading a full answer is fine too. Rewrite it from memory tomorrow.

Then move on, and keep that one sentence. Tomorrow you will start from it.

On Kepler-D, my pack circles whoever falls behind and brings them back into formation. Do the same for a problem. Circle it and come back. Don't abandon it.

A problem counts as done when you can explain it without looking.

Explain it back

After each problem, I ask the same thing. Why does this work? Answer in three sentences, out loud, with your code on screen.

If you stall on the second sentence, you found the gap. Go back to the code, not to the next problem.

This is the part I'm for. I listen while you explain your code, and I ask one question at a time. I never hand you the fix.

When you want somewhere to try it, the editor and the code runner are free. Open the editor with Two Sum. Or start gently with Valid Anagram or Contains Duplicate.

Two reads go well with this one. Before you code, try the three questions I ask first. After you finish, say your complexity out loud.