# LeetCode Patterns: The Top 75 Problems That Actually Prepare You for Technical Interviews
Most candidates grinding LeetCode solve the wrong problems in the wrong order. They burn weeks on arbitrary "easy" problems that do not generalize, avoid the medium problems that actually teach the patterns interviewers test, and skip the hard problems that signal senior readiness. The Top 75 problem list, in its various community-curated forms, exists to solve this. Walked correctly, it takes 8 to 12 weeks and produces meaningful interview readiness at the FAANG-adjacent tier.
This guide covers what the Top 75 actually is, how to work through it, the 12 patterns it teaches, and how to know when you are ready to move from practice to real interviews.
## What the Top 75 Actually Is
The "Top 75" or "Blind 75" is a list of 75 LeetCode problems originally compiled on the Blind app as the minimum viable set for technical interview preparation. Variants exist (NeetCode 150, Grind 75, Top 100 Liked Questions), but they share the same purpose: cover the patterns that appear most frequently in real technical interviews without requiring a candidate to solve 500 problems.
The 75 problems are distributed across 14 problem categories:
| Category | Problem Count | Pattern Focus |
| --- | --- | --- |
| Arrays and Hashing | 9 | Hashmap lookup, frequency counting |
| Two Pointers | 5 | In-place manipulation, sorted array traversal |
| Sliding Window | 6 | Substring and subarray problems |
| Stack | 7 | Monotonic stack, parentheses, expression evaluation |
| Binary Search | 7 | Search space reduction |
| Linked List | 11 | Pointer manipulation, cycle detection |
| Trees | 15 | DFS, BFS, recursion on nodes |
| Tries | 3 | Prefix tree structure |
| Heap / Priority Queue | 4 | K-element problems, merge sorted |
| Backtracking | 9 | Combinatorial exploration |
| Graphs | 13 | DFS, BFS, topological sort, union-find |
| Advanced Graphs | 6 | Dijkstra, MST, more complex patterns |
| 1-D Dynamic Programming | 12 | Bottom-up DP, memoization |
| 2-D Dynamic Programming | 11 | Grid DP, string DP |
| Greedy | 8 | Local optimal decisions |
| Intervals | 6 | Merging, overlap detection |
| Math and Geometry | 8 | Bit manipulation, number theory |
| Bit Manipulation | 7 | XOR tricks, bit counting |
Some Top 75 lists are slightly different. What matters is covering the 14 patterns, not the exact problem selection.
> "The point of the Top 75 is not to memorize 75 solutions. It is to extract the 12 or so patterns that generalize to every new problem you see in an interview. Candidates who solve 200 problems without identifying patterns underperform candidates who solve 75 problems deliberately." - Yu Wang, former Google software engineer and co-creator of the Blind 75 list
## The 12 Core Patterns
Across the 75 problems, roughly 12 patterns recur. Mastering the patterns is the actual goal. Mastering individual problems is the side effect.
### Pattern 1: Hash Map / Set Lookup
Use a hashmap or set to achieve O(1) lookup for values you will check repeatedly. Exemplar problem: Two Sum. Variants: Contains Duplicate, Group Anagrams, Top K Frequent Elements.
### Pattern 2: Two Pointers
Two indices traversing an array, usually one from each end or both moving forward at different rates. Exemplar: Valid Palindrome. Variants: 3Sum, Container With Most Water, Trapping Rain Water.
### Pattern 3: Sliding Window
A window that expands or contracts based on a condition, tracking state within the window. Exemplar: Longest Substring Without Repeating Characters. Variants: Minimum Window Substring, Longest Repeating Character Replacement.
### Pattern 4: Fast and Slow Pointers
Two pointers moving at different speeds through a linked list or sequence, often for cycle detection. Exemplar: Linked List Cycle. Variants: Middle of Linked List, Happy Number.
### Pattern 5: Merge Intervals
Sort intervals and merge overlapping ones. Exemplar: Merge Intervals. Variants: Insert Interval, Non-overlapping Intervals, Meeting Rooms.
### Pattern 6: Tree Traversal (DFS and BFS)
Recursive or iterative traversal of a tree, choosing the right order for the problem. Exemplar: Maximum Depth of Binary Tree. Variants: Same Tree, Lowest Common Ancestor, Binary Tree Level Order Traversal.
### Pattern 7: Binary Search
Reduce a sorted search space by half at each step. Exemplar: Binary Search. Variants: Search in Rotated Sorted Array, Find Minimum in Rotated Sorted Array, Median of Two Sorted Arrays.
### Pattern 8: Dynamic Programming (1-D and 2-D)
Optimal substructure plus overlapping subproblems. Solve smaller subproblems and build up. Exemplar: Climbing Stairs. Variants: House Robber, Longest Increasing Subsequence, Longest Common Subsequence, Edit Distance.
### Pattern 9: Backtracking
Explore a decision tree, abandoning branches that cannot lead to valid solutions. Exemplar: Subsets. Variants: Permutations, Combination Sum, N-Queens, Word Search.
### Pattern 10: Graph Traversal (DFS and BFS)
Explore nodes and edges systematically, tracking visited state. Exemplar: Number of Islands. Variants: Clone Graph, Course Schedule, Pacific Atlantic Water Flow.
### Pattern 11: Topological Sort
Ordering nodes in a directed acyclic graph such that each node comes before its dependents. Exemplar: Course Schedule II. Variants: Alien Dictionary, Minimum Height Trees.
### Pattern 12: Union-Find
Disjoint-set data structure for tracking connected components. Exemplar: Number of Connected Components in Undirected Graph. Variants: Graph Valid Tree, Redundant Connection.
These 12 patterns cover roughly 85 percent of questions you will see in technical interviews from the associate software engineer level through senior. The remaining 15 percent is problem-specific cleverness that cannot be patterned.
## Study Order: Easy to Hard, Pattern by Pattern
The correct order is not "start with problem 1 and go to 75." The correct order is pattern by pattern, within each pattern solving easy before medium before hard.
Recommended order:
| Week | Pattern Cluster | Problem Count |
| --- | --- | --- |
| 1 | Arrays and Hashing | 9 |
| 2 | Two Pointers + Sliding Window | 11 |
| 3 | Stack + Binary Search | 14 |
| 4 | Linked List | 11 |
| 5 | Trees (easy and medium) | 10 |
| 6 | Trees (hard) + Tries | 8 |
| 7 | Heap + Backtracking | 13 |
| 8 | Graphs (basic) | 7 |
| 9 | Graphs (advanced) + Intervals | 12 |
| 10 | 1-D DP | 12 |
| 11 | 2-D DP | 11 |
| 12 | Greedy + Math + Bit | 22 |
This is 140 problems across 12 weeks, which expands the Blind 75 into NeetCode 150 coverage. Candidates with less time should compress into 8 weeks with the Blind 75 only.
For a complementary approach to this study plan, the [cognitive science of effective exam preparation](/exam-prep/study-techniques/cognitive-science-of-effective-exam-preparation) guide covers spacing and retention strategies that apply directly to LeetCode practice.
## How Long Per Problem
Set a time budget per problem. Without one, candidates either rush (solving problems without learning the pattern) or stall (spending hours on a single problem).
| Difficulty | First Attempt Time | Solution Review | Re-attempt Without Help |
| --- | --- | --- | --- |
| Easy | 20 to 30 min | 10 min | 10 min |
| Medium | 30 to 45 min | 15 min | 15 to 20 min |
| Hard | 45 to 60 min | 20 min | 20 to 30 min |
If you cannot solve an easy in 30 minutes, read the solution, understand it, and re-implement it from scratch. Do not spin on easies past the time budget.
If you cannot solve a medium in 45 minutes, read the approach (not full solution), and attempt again with the hint. This is the single most valuable study pattern: constrained hints rather than full solutions.
Hards are different. Most candidates should read solutions for hards sooner, study them, and return to the problem a week later to re-solve from memory. Hards are about exposure to patterns, not about unaided problem-solving at the first attempt.
## The Solution Review Process
The most important part of LeetCode study is not the initial attempt. It is the solution review. Many candidates solve a problem correctly, submit, and move to the next. This wastes most of the learning value.
For every problem, regardless of whether you solved it:
- Read at least one community solution with high upvotes.
- Identify the pattern explicitly. Write it down: "This is a sliding window problem."
- Note the time and space complexity and why.
- Note the edge cases the solution handles (empty input, single element, all duplicates).
- Write a one-paragraph summary in your own words.
Keep these notes in a searchable format (Obsidian, Notion, Anki, or a Git-backed Markdown folder). After 75 problems, you have 75 pattern summaries, which become your personal interview prep document.
For note-taking structure specifically, [Cornell note-taking for technical study](/exam-prep/note-taking/cornell-note-taking-for-certs) covers a structure that works well for LeetCode problem notes.
## Language Choice
Use one language consistently throughout your LeetCode study. Switching languages mid-study wastes time. The most common interview languages are Python, Java, C++, and JavaScript.
| Language | Pros | Cons |
| --- | --- | --- |
| Python | Concise, fast to write, rich standard library | Slower runtime, sometimes TLE on hard problems |
| Java | Strongly typed, common in enterprise interviews | Verbose, slower to write during timed interviews |
| C++ | Fastest runtime, expected at some elite firms | Steepest learning curve, manual memory management |
| JavaScript | Familiar to web developers | Limited at some backend-heavy firms |
For general technical interviews, Python is the most common recommended language. It is concise enough to type quickly under pressure and the standard library (collections, heapq, itertools) handles common data structures without manual implementation.
If you are interviewing for roles that explicitly require C++ or Java, use those. Otherwise, Python is a low-risk choice.
## Common Study Mistakes
**Mistake 1: Grinding without reviewing.** Solving 200 problems and not being able to recall the pattern for any specific one is a failure mode. Review is where learning happens.
**Mistake 2: Jumping randomly across patterns.** One day arrays, next day DP, next day graphs. This prevents pattern consolidation. Stay on one pattern cluster for at least 3 to 5 days before switching.
**Mistake 3: Skipping the hard problems in each pattern.** Hards are where the deep understanding lives. Skipping them produces candidates who solve medium problems well but freeze on any unfamiliar hard in interviews.
**Mistake 4: Writing code directly without thinking first.** Before typing, say out loud (or write) the approach, complexity, and edge cases. This practice transfers directly to interviews where "think out loud" is expected.
**Mistake 5: Using an IDE with autocomplete.** Many LeetCode users develop in an IDE with heavy autocomplete, then panic in interviews when the shared editor lacks it. Practice in a plain editor (LeetCode's built-in editor or a bare VSCode without Copilot) at least 50 percent of the time.
> "In a technical interview, the candidate who says 'I recognize this as a sliding window problem because we need to track a contiguous subarray with a constraint' outperforms the candidate who just starts coding. Pattern recognition and verbalization are the two skills that matter most." - Gayle Laakmann McDowell, author of Cracking the Coding Interview
## Mock Interview Practice
Solving problems on LeetCode is necessary but not sufficient. Interviews have live pressure, time limits, and communication expectations that static practice does not replicate.
Mock interview resources:
- Pramp: free peer-to-peer mock interviews, 45 minutes, both sides (interviewer and interviewee).
- Interviewing.io: paid mock interviews with engineers from top companies.
- Study groups on Discord or Slack for paired practice.
Schedule at least 10 mock interviews in the last 3 weeks before real interviews. The first few will feel awkward. By interview 10, the format feels familiar.
Our [whiteboard interview strategies](/interviews/technical-interviews/whiteboard-interview-strategies) guide covers the verbal communication patterns that separate strong candidates from technically capable but silent ones.
## The Ready Signal
How do you know when you are ready?
You are ready when:
- You can identify the pattern of a medium problem within 2 minutes of reading it
- You can articulate your approach verbally before coding
- You can code a clean solution for most mediums within 25 minutes
- You recover from simple bugs without heavy debugging
- You can discuss time and space complexity fluently for any solution you write
You are not ready if:
- You freeze on unseen medium problems even though you have solved similar ones
- You forget the pattern 2 days after solving a problem
- You can code the solution but cannot explain why it works
- You cannot think out loud without losing your place
Most candidates underestimate how long it takes to reach the ready signal. Budget 8 to 12 weeks of serious study. Candidates who rush to interviews at week 4 typically burn interview slots without converting them.
## The Company-Specific Signal
Different companies emphasize different patterns. Rough mapping based on community reports from actual interviews:
| Company | Emphasis | Style |
| --- | --- | --- |
| Google | Graphs, DP, algorithmic creativity | Open-ended, multi-stage |
| Amazon | Leadership principles + medium coding | Behavioral-heavy, pattern-based coding |
| Microsoft | Core data structures, OOP | Balanced, practical |
| Meta | Arrays, strings, trees, graphs | Fast-paced, volume |
| Apple | Language fluency, systems thinking | Deep on fewer problems |
| Netflix | Systems design + senior-level problems | Limited junior hiring |
| Bloomberg | OOP design + data structures | Heavy on LC mediums |
This mapping is rough and changes over time. Crowdsourced interview experience sites (Glassdoor, LeetCode discuss, levels.fyi) have current, company-specific reports.
## Beyond LeetCode
LeetCode is necessary but narrow. For senior-level roles, two additional study areas matter:
### System Design
For staff and senior engineer roles, system design is 30 to 50 percent of the interview process. LeetCode alone does not prepare you. Our [system design interview framework](/interviews/technical-interviews/system-design-interview-framework) covers the structure and rubric.
### Behavioral Interviews
At every level, behavioral interviews decide a significant fraction of hiring decisions. Candidates with strong LeetCode and weak behavioral lose offers. The [STAR method for behavioral interviews](/interviews/behavioral-interviews/star-method-explained-how-to-structure-behavioral-interview-answers) and the upcoming guide on the failure question both matter.
## Tool Stack for LeetCode Study
| Tool | Purpose |
| --- | --- |
| NeetCode.io | Free pattern-organized problem walkthroughs |
| LeetCode Premium ($35/mo) | Company-filtered problem lists |
| Excalidraw | Visual tree and graph drawing during study |
| Anki | Pattern flashcards |
| Obsidian | Note management |
| Pramp | Free mock interviews |
A minimal viable toolset is NeetCode.io, the free LeetCode tier, and a note-taking system. Everything else is nice to have.
For candidates managing cognitive load across a 12-week study campaign, retention resources at [What's Your IQ](https://whats-your-iq.com) cover spaced repetition and memory consolidation that apply directly. Technical writing skills pair with interview communication skills, and [Evolang](https://evolang.info) covers professional writing including technical explanation patterns. Independent consultants building practices around their technical interview coaching can reference [Corpy](https://corpy.xyz) for business formation.
## Scheduling Around Life
Full-time workers can reasonably fit 10 to 15 hours of LeetCode study per week. This looks like:
- Weekday mornings: 1 hour, one problem
- Weekday evenings: 1 hour, review solutions and notes
- Saturday: 3 to 4 hours, mixed problems and mock interview
- Sunday: 2 to 3 hours, pattern consolidation and weak-spot practice
Candidates who try to study 25+ hours per week while holding a full-time job consistently burn out by week 4. The 10 to 15 hour pace is sustainable for 12 weeks and produces reliable results.
Candidates unemployed or actively between roles can compress to 6 to 8 weeks at 25 to 30 hours per week, but even then, diminishing returns kick in past 30 hours per week. Rest is part of the process.
For time-management frameworks that apply to intensive study periods, see our guides on [time management for exams](/exam-prep/time-management/) and [eliminating distractions during study](/exam-prep/study-techniques/eliminating-distractions-during-study).
## Miscellaneous Utilities
Two small utility resources show up during interview prep in unexpected ways. [File converter tools](https://file-converter-free.com) appear when candidates compile PDF study packets from multiple sources. [QR code utilities](https://qr-bar-code.com) show up in interview logistics for some take-home assessments. Not core, but worth bookmarking.
## The Longer Arc
The Top 75 is the first 12 weeks of technical interview preparation. What follows depends on the level and company.
For junior and associate-tier candidates, the Top 75 is sufficient. Companies do not expect deep algorithmic brilliance from 0 to 2 year candidates.
For senior engineers, the Top 75 is the baseline, with additional preparation needed in system design, distributed systems fundamentals, and leadership interview patterns.
For staff and principal engineers, coding interviews are still part of the loop but weighted less. System design, architecture discussions, and technical leadership become dominant. LeetCode study for these candidates is maintenance rather than primary preparation.
## References
- McDowell, Gayle Laakmann. *Cracking the Coding Interview, 6th Edition*. CareerCup, 2015. ISBN: 978-0984782857.
- Sedgewick, Robert and Kevin Wayne. *Algorithms, 4th Edition*. Addison-Wesley Professional, 2011. ISBN: 978-0321573513.
- Cormen, Thomas H., et al. *Introduction to Algorithms, 4th Edition*. MIT Press, 2022. ISBN: 978-0262046305.
- Blind. *Blind 75 Problem List*. Original compilation on the Blind app, 2019. [https://www.teamblind.com](https://www.teamblind.com)
- NeetCode. *NeetCode 150 Roadmap*. NeetCode.io. [https://neetcode.io](https://neetcode.io)
- Laaksonen, Antti. *Competitive Programmer's Handbook*. [https://cses.fi/book/book.pdf](https://cses.fi/book/book.pdf)
- Google. *Technical Interview Guidelines*. Google Careers. [https://careers.google.com/how-we-hire/interview/](https://careers.google.com/how-we-hire/interview/)
- Amazon. *Amazon Leadership Principles*. Amazon. [https://www.amazon.jobs/en/principles](https://www.amazon.jobs/en/principles)
Frequently Asked Questions
How long does it take to finish the Blind 75?
Eight to twelve weeks for a working professional studying 10 to 15 hours per week. Full-time study compresses this to 4 to 6 weeks. Candidates who attempt shorter timelines typically complete the problems but fail to extract the patterns, which shows up in interview performance.
Is the Blind 75 enough for a FAANG interview?
The Blind 75 covers the core patterns but the volume is light for elite-tier interviews. For FAANG and similar, extend to NeetCode 150 or the Top 100 Liked Questions, add company-specific problem lists from LeetCode Premium or LeetHub, and add mock interview practice. The Blind 75 is the minimum, not the complete prep.
Which programming language is best for LeetCode?
Python for most candidates. It is concise, fast to type under interview pressure, and has a rich standard library. Use Java or C++ only if you are specifically targeting roles that require them. Pick one language and stick with it through the entire study cycle to avoid switching overhead.
Should I read the solution if I cannot solve a problem?
Yes, but only after spending the time-budgeted attempt. For easy problems, 20 to 30 minutes. For mediums, 30 to 45 minutes. After that, read the solution, understand it, then re-solve without looking. The re-solve is where learning consolidates.
Is it better to solve 200 problems or 75 problems deeply?
75 problems deeply. Solving 200 problems without pattern extraction produces recognition without generalization. Candidates who solve 75 problems and can articulate the underlying pattern for each one outperform candidates who solved three times as many problems without structured review.
When am I ready to start applying to jobs?
When you can identify the pattern of a new medium problem within 2 minutes, articulate your approach verbally, code a clean solution within 25 minutes, and discuss time and space complexity fluently. Most candidates underestimate how long this takes and apply too early.
How many mock interviews should I do?
At least 10 in the last 3 weeks before real interviews. Mock interviews surface weaknesses that static LeetCode practice hides, particularly verbal communication, clarifying questions, and recovery from mistakes. Pramp and Interviewing.io are common resources.
