Blind 75 for Tech Interviews (Study Plan & Tips)
The Blind 75 is a set of 75 coding problems used to practice common data-structures-and-algorithms patterns for software interviews. Choose one version, follow an eight-week plan, and track how you solve each problem. Aim to explain your approach, test edge cases, and state its time and space costs, not just finish the list.
Preparing for coding interviews can feel like a race to solve more problems. But a long completion list does not show whether you can solve a new problem under pressure. The better goal is to build skills you can use again: spotting patterns, explaining your thinking, testing your code, and learning from mistakes.
I recommend treating the 75 problems as a practice plan, not a test of your worth or a promise of a job. The set is not a formal credential or a universal employer syllabus. Your results matter most when they show what you can solve without help, and where you still need practice.
What the Blind 75 covers
The Blind 75 is a collection of coding interview problems grouped by topic, such as arrays, trees, graphs, and dynamic programming. Lists and category labels can differ across published versions, so pick one list and record its source. Use it to practice problem-solving patterns, not as proof that you have learned every interview topic.
A pattern is a reusable way to approach a type of problem. For example, two pointers can help compare or scan values from two positions, while graph traversal visits connected items. Learning when a pattern applies is more useful than memorizing a specific answer.
Many versions include problems from areas such as:
- Arrays, strings, and hash maps
- Two pointers and sliding windows
- Binary search and intervals
- Linked lists, trees, and graphs
- Heaps, backtracking, and dynamic programming
A hash map stores key-value pairs so code can look up a value by its key. Big-O notation describes how an algorithm’s work or memory use may grow as its input grows. You should be ready to explain both for your solutions.
The set does not cover every question a company may ask. Interviews can also test communication, role-specific skills, or system design, especially for experienced candidates. Check the format for each employer and role, and use the 75 problems as one part of your preparation.
How to start: a one-week diagnosis
A short diagnosis helps you choose the right pace. Before starting the full list, select your interview language, review key basics, and try one problem with a timer. Use the result to find gaps, not to label yourself as ready or unready.
Week 0 checklist
- Choose a language you can write clearly under time pressure.
- Review arrays, hash maps, recursion, and basic data structures.
- Learn how to describe time and space complexity.
- Attempt one timed problem before looking at a hint.
- Note what slowed you down: understanding, choosing an approach, coding, or testing.
Set a limit of 30–45 minutes for your first attempt at each problem. If you are stuck, record what you tried and where you got blocked. Then use a hint or solution to learn the missing idea. Reading a solution is a useful step, but it is not the same as solving the problem independently.
Use a simple status for each problem:
| Status | What it means | Next action |
|---|---|---|
| Independent | You solved it without hints | Revisit it in mixed practice |
| Hint-assisted | You needed a clue to find the approach | Re-solve without notes |
| Solution-reviewed | You needed to study the solution | Rebuild the reasoning and code |
| Mastered | You later solved it without notes | Keep it in occasional review |
This record makes progress more honest than a checked box. Mark a problem mastered only after an unaided re-solve.
An eight-week study plan
An eight-week plan gives you time to try problems and return to difficult ones. The target is about 9–10 first attempts each week, plus review. That pace is a planning guide, not a requirement. If algorithms are new to you, extend the schedule rather than rushing through problems without learning from them.
| Week | Focus | Main task |
|---|---|---|
| 0 | Diagnosis | Pick a language, review basics, try a baseline problem |
| 1–2 | Foundations | Work through familiar data structures and core patterns |
| 3–5 | Coverage | Continue through your chosen list by topic |
| 6–7 | Consolidation | Re-solve flagged problems and mix topics under time limits |
| 8 | Interview practice | Run mock interviews and target your remaining gaps |
Use the published order if it supports your learning, or group problems by topic. Either way, keep the source list consistent and make sure you cover all 75. After each problem, write down the pattern, the key idea, and any assumption that caused trouble.
For problems you missed or solved with help, try an unaided re-solve after about one day and again after about seven days. These intervals are study targets, not employer standards. If you still cannot explain the approach, review the concept and schedule another attempt.
A repeatable method for each problem
A consistent routine helps you learn from every attempt. First understand what the problem asks, then choose an approach, code it, and test it. Finish by explaining the reasoning and complexity. This turns a practice session into evidence of skill, whether you solved the problem alone or learned from a solution.
- Restate the task. Identify the input, required output, and any limits.
- Try a simple example. Check what the expected result should be.
- Choose a possible pattern. Ask whether the problem suggests a hash map, two pointers, a sliding window, binary search, graph traversal, or another method.
- Explain the idea before coding. State the key rule your algorithm will maintain. This rule is an invariant: a condition that stays true as the code runs.
- Write and test the code. Include ordinary and edge-case inputs.
- State the cost. Describe time and space complexity in Big-O terms.
- Log the lesson. Record the failed assumption, the correction, and what you will try next time.
Test for an empty input, a single item, duplicates, and boundary values when they apply. Also check whether your approach relies on an assumption the problem does not guarantee. A correct-looking solution can fail on an edge case if you skip this step.
When you review a solution, close it before trying again. Rebuild the reasoning in your own words, then write the code from memory. If you can only recognize the solution when it is on screen, keep it in the review queue.
Practical examples: adjust the plan to your starting point
These examples are study scenarios, not reports of measured outcomes. They show how two candidates might use the same problem set differently. The right pace depends on what you already know, how much time you have, and when you expect interviews.
Scenario A: New to algorithms. A student can code in their chosen language but has little practice with recursion or Big-O. They start with the Week 0 review, spend longer on each pattern, and may need more than eight weeks. Their goal is steady understanding, not hitting 9–10 attempts every week.
Scenario B: Experienced developer, new to interviews. A developer already uses common data structures at work but has not practiced timed coding interviews. They may move faster through familiar topics and spend more time on mixed practice, explaining decisions aloud, and testing under time limits.
The method stays the same for both candidates: record whether each attempt was independent, hint-assisted, or solution-reviewed. Change the pace when you see repeated gaps. Accumulating unfinished attempts is less useful than pausing to review one weak area.
How to judge readiness and choose what comes next
Readiness is a mix of skills, not a problem count. Look for evidence that you can solve a range of problems independently, explain your reasoning, analyze complexity, and handle edge cases. Then use mock-interview feedback and the target employer’s format to decide what to practice next.
Before an interview, check whether you can:
- Solve a mixed set of problems without knowing the topic in advance.
- Explain the key invariant or algorithm clearly.
- Write a correct implementation within the time available.
- State time and space complexity.
- Test relevant edge cases and respond calmly when an approach fails.
A mock interview is a practice interview that uses a realistic format, often with a timer and verbal explanation. Use feedback to find specific gaps. If you struggle with graph traversal, for example, focus on that skill rather than restarting all 75 problems automatically.
Finishing the list does not guarantee an interview, offer, or job. Hiring also depends on experience, role fit, communication, and the employer’s process. The list is not an accredited course or credential. Do not treat completion as a formal qualification.
Key next step: choose a list, set your pace, and begin an error log. Use independent re-solves and mixed mock interviews to decide whether your practice is transferring to unfamiliar problems.
Frequently asked questions
How long does it take to complete the Blind 75?
An eight-week schedule is a practical starting plan, with about 9–10 first attempts each week plus review. You may need more time if algorithms are new or your schedule is limited. Learning and re-solving matter more than finishing by a fixed date.
Should I solve every problem before looking at a solution?
Try each problem for up to 30–45 minutes before using a hint or solution. If you are stuck, record your attempt and study the missing idea. Then close the solution and rebuild the reasoning and code independently.
Is the Blind 75 enough to pass a coding interview?
No list can ensure that you will pass. The problems can help you practice common patterns, but interviews vary by employer, role, and seniority. Pair the list with mock interviews and preparation for the specific format you expect.
What programming language should I use?
Choose a language you can use clearly and reliably under time pressure. Review its common data structures and syntax before practice. If an employer specifies supported languages or has a language-specific interview, follow that guidance.
How should I track progress?
Mark each problem independent, hint-assisted, or solution-reviewed. Record your approach, complexity, edge cases, and the point where you needed help. Count a problem as mastered after you solve it again without notes.
When should I re-solve a missed problem?
Try it again without notes after about one day and again after about seven days. These are useful review targets, not fixed rules. If you still cannot explain the approach, revisit the concept and schedule another attempt.
Should I study by topic or follow the list order?
Either can work if you use one defined list and cover all its problems. Grouping by topic can help you learn a pattern; mixed practice later tests whether you can recognize it without a label.
What if I cannot finish all 75 problems?
Do not rush through the rest just to reach 75. Focus on understanding the problems you attempted, reviewing repeated gaps, and practicing a smaller mixed set under interview-like conditions. Adjust your schedule to your interview date and starting level.
Does completing the list earn a credential?
No. The problem set is interview preparation, not an accredited academic program or professional credential. Treat your performance as practice evidence, not as a qualification or a promise of employment.
What should I do after completing the list?
Re-solve problems you needed help with, then try mixed timed practice and mock interviews. Review the target employer’s interview format and use feedback to select the next topics, rather than automatically repeating every problem.
(This article was written by one of our staff writers, James Holloway. Visit our Meet the Team page.)
