DSA Roadmap: Where to Start and How to Actually Get Good

I remember the first time I opened LeetCode. I stared at a problem about binary trees, panicked, and closed the tab. Opened a YouTube video about DSA. Panicked more. Closed that too. Ordered a 1,000-page algorithms textbook and fully read about 3 pages before it became a very expensive doorstop.

Sound familiar?

Here’s what nobody tells you: DSA is not about solving 500 LeetCode problems and memorizing solutions. It’s about building intuition for a set of patterns that come up over and over again. Once you see the pattern, you can solve problems you’ve never seen before. That mindset shift is everything.

After years of writing production code, hiring engineers, and being on both sides of the interview process, I’ve distilled what actually works into a roadmap you can follow right now.

---

The Ground Rules Before We Begin

Let me be brutally honest about a few things first, because I wish someone had told me this early.

My 3 AM Debugging Story

I’ll never forget the time I spent three hours debugging a “simple” two-pointer problem during interview prep. The problem was finding pairs in a sorted array, and my solution kept returning wrong answers. I was convinced the test cases were broken. I rewrote the logic four times. I drew diagrams. I even suspected my compiler was buggy.

The bug? I forgot the array was sorted and kept moving both pointers in the same direction. Three hours for a one-line fix. The embarrassment was real, but the lesson stuck: slow down, verify your assumptions, and actually read what the problem says. Now when I’m stuck, I first check if I’m solving the problem I think I’m solving.

That night taught me more about debugging than any tutorial ever could. Getting stuck isn’t failure — it’s where the real learning happens.

You will feel dumb. A lot. That’s not a bug — it’s the process. Every senior engineer I know has spent hours stuck on a problem a junior solved in 20 minutes. The goal isn’t to never get stuck. It’s to get better at getting unstuck.

Consistency beats intensity every time. Two hours a day for six months is infinitely better than two weeks of 12-hour benders followed by giving up. Your brain needs time to consolidate patterns during sleep. I’ve seen this play out hundreds of times.

Understanding beats memorizing. I guarantee you’ll forget a solution you memorized within a week. But once you truly understand why two pointers work on a sorted array, you’ll never forget it. Aim for the “aha” moment, not the checkbox next to a problem.

The order matters more than you think. Learning Dynamic Programming before you understand recursion is like trying to run before you can walk. I’ve laid out the roadmap in a specific order — please follow it.

---

Self-Assessment: Where Should You Start?

Before diving in, let’s figure out your starting point. Answer these honestly:

1. Can you implement binary search from memory without bugs?

• Yes, easily → Skip to Phase 2
• Sort of, with some thinking → Start at Phase 1, Arrays section
• No or unsure → Start at Phase 1, beginning

2. Have you solved 20+ LeetCode problems successfully?

• Yes, and I understood the patterns → Phase 2
• Yes, but I mostly looked at solutions → Phase 1
• No → Phase 1

3. Can you explain what O(n log n) means and why merge sort is that complexity?

• Yes, confidently → Phase 2 or 3
• Vaguely → Phase 1
• No → Phase 1, study Big-O first

4. Do you understand recursion well enough to solve tree problems?

• Yes → Phase 2 (Trees section)
• Somewhat → Phase 1 (Recursion section)
• No → Phase 1 (start with Recursion)

5. Have you implemented a graph algorithm (BFS/DFS) before?

• Yes, multiple times → Phase 3
• Once or twice → Phase 2
• No → Phase 2

Your Starting Point:

• Mostly “No” answers: Start at Phase 1, Arrays. Build your foundation properly.
• Mix of answers: Start at Phase 1 but move quickly through familiar topics.
• Mostly “Yes” answers: Jump to Phase 2 or 3, but review fundamentals if you get stuck.

---

The Full Roadmap at a Glance

Here’s the complete picture before we get into the details:

Four phases, roughly 12-16 weeks total at 1-2 hours daily. The goal at the end: walk into any coding interview and have a framework for attacking any problem you see. Let’s dig into each phase.

---

Phase 1 — The Foundation (Weeks 1-3)

This is where you build the bedrock. Don’t rush this. I’ve seen more people fail in interviews because they never solidified their fundamentals than because they didn’t know advanced algorithms.

Arrays — Your Single Most Important Data Structure

Everything in programming ultimately comes back to arrays. They’re stored as contiguous blocks of memory, which gives them O(1) random access — the single best property any data structure can have.

Think of an array like a parking lot with numbered spots. You want to park in spot 42? You go directly there — you don’t check spots 1 through 41. That’s O(1) access. Magic.

But here’s the tradeoff: if you want to insert a car in the middle, every car to the right has to move. That’s O(n). Arrays pay for their fast reads with expensive inserts and deletes.

The patterns you must nail on arrays:

The Two Pointer pattern is how you avoid nested loops on sorted arrays. Instead of comparing every pair with O(n²), you put one pointer at each end and march them toward each other. Classic example: given a sorted array, find two numbers that sum to a target. You check the sum — too big, move the right pointer left; too small, move the left pointer right. O(n) instead of O(n²). That’s the kind of thinking that impresses interviewers.

The Sliding Window pattern is for any problem that asks about subarrays or substrings. You maintain a window that slides across the array, tracking whatever state you need (sum, character counts, etc.). When the window violates a condition, shrink it from the left. When it doesn’t, expand it to the right. Problems like “Maximum Sum Subarray of Size K” or “Longest Substring Without Repeating Characters” — both classic examples.

Binary Search deserves a whole conversation by itself. It only works on sorted arrays, but when it applies, it turns O(n) searches into O(log n). For a million elements, that’s the difference between 1,000,000 operations and 20 operations. Every time you see a sorted array in a problem, your first thought should be: “Can I binary search here?”

Prefix sums are a technique that almost nobody learns early enough. You precompute cumulative sums, and suddenly any range sum query becomes O(1) instead of O(n). It’s a one-time O(n) investment that pays dividends on every query.

Start with these problems: Two Sum, Best Time to Buy and Sell Stock, Maximum Subarray (Kadane’s Algorithm), Contains Duplicate, Product of Array Except Self.

Linked Lists — Learning Dynamic Memory

Linked lists get a bad rap because you rarely use them directly in production code. But they are an absolute interview staple, and understanding them builds deep intuition about pointers and memory.

Unlike arrays, a linked list doesn’t need contiguous memory. Each node knows where the next one is. This makes inserting at the head O(1) — just change some pointers. But accessing element #500 means following 499 links. O(n) access is the cost of that flexibility.

The patterns that come up in interviews:

Fast and Slow Pointers (Floyd’s Algorithm) — this is the method for detecting cycles in a linked list. Two pointers traverse the list: one moves one step at a time (slow), one moves two steps (fast). If there’s a cycle, they’ll eventually meet. If not, the fast pointer hits null. This is a beautiful algorithm because it uses O(1) extra space — no extra data structure needed.

Reversing a linked list — you’ll be asked this in a dozen different forms. The in-place O(1) space reversal is done by rearranging pointers as you traverse. Understanding this builds the muscle memory for pointer manipulation that’s needed in harder problems.

Dummy nodes — one of the most practical tricks in linked list problems. Creating a dummy node whose .next points to the head saves you from writing special cases for when the head itself needs to change.

Stacks and Queues — Data Structures with Rules

A stack is arrays with a rule: last in, first out. A queue is arrays with a rule: first in, first out. Simple, but these constraints make them powerful.

Stacks shine anywhere you need to remember previous state and potentially undo it. Balanced parentheses, browser history, undo/redo operations — all stacks. The pattern: push when you open something, pop when you close it, and check if the top matches.

Queues show up any time you need to process things in order they arrived. BFS (breadth-first search) is fundamentally a queue algorithm. Any time you’re exploring level by level, you’re using a queue.

A monotonic stack is an advanced pattern built on stacks. You maintain elements in a stack in monotonically increasing or decreasing order. When a new element would break the monotonic property, you start popping. This is the trick behind problems like “Next Greater Element” and “Largest Rectangle in Histogram” — two of the most requested interview problems.

Strings — Arrays in Disguise

Strings are just character arrays with extra rules. Most string problems are actually array problems in disguise. The key difference is understanding how operations like substring and concatenation work, and being careful about character encoding.

Sliding window applies directly to string problems. “Longest substring without repeating characters,” “Minimum window substring” — both windows. The trick for character problems: use a hash map (or a 26-element array for lowercase letters) to track character frequency in your window.

Two pointers for palindromes. Check if a string is a palindrome by starting from both ends and walking toward the middle. O(n) time, O(1) space.

Recursion — The Mental Model You Can’t Skip

Recursion is where most beginners get stuck, and it’s because they try to mentally simulate the call stack. Don’t. Instead, learn to trust the recursion.

There are two parts to any recursive solution. One: define what the function does and what it returns — write it clearly in a comment first. Two: handle the base case (when to stop recursing). Three: call the function recursively, assuming it works perfectly, and build your answer.

The “assume it works” part is called the leap of faith. It’s hard the first time. It gets easier. Once you genuinely internalize recursion, Dynamic Programming — which is just smart recursion — unlocks completely.

---

Phase 2 — Core Data Structures (Weeks 4-7)

With the fundamentals solid, it’s time to build your toolkit. The data structures in this phase are the ones you’ll use in the vast majority of interview questions.

Trees — The Most Interview-Heavy Data Structure

Trees are everywhere in interviews because they touch recursion, DFS, BFS, and problem-solving patterns simultaneously. If you had to pick one data structure to master, it’s trees.

The three traversals. Memorize these cold: inorder (left → root → right), preorder (root → left → right), postorder (left → right → root). For a Binary Search Tree, inorder traversal gives you elements in sorted order — this is not a coincidence, it’s a property of BSTs and it comes up constantly.

Binary Search Trees give you O(log n) search, insert, and delete — but only if the tree stays balanced. A BST filled by inserting sorted elements degenerates into a linked list. This is why Balanced BSTs (AVL trees, Red-Black trees) were invented. You don’t need to implement these for most interviews, but you should know why they exist.

The DFS recursive pattern. Most tree problems can be solved with a single recursive function that returns something computed from the left subtree, the right subtree, and the current node. The key insight: you almost never need global variables. Return information up the call stack.

For maximum depth: max(depth(left), depth(right)) + 1. For checking balance: return height if balanced, -1 if not. For lowest common ancestor: if a node sees one target in its left subtree and one in its right, it’s the LCA. These patterns come up in dozens of different problems.

Level-order traversal (BFS) on trees. Use a queue. Add root. Loop: dequeue current node, process it, enqueue its children. When you want to know which level nodes are on (zigzag traversal, right side view, average by level), track the queue size at the start of each iteration — that’s how many nodes are on this level.

Hash Maps and Hash Sets — Speed at a Price

Hash maps are the Swiss Army knife of data structures. O(1) average case for insert, delete, and lookup. In exchange for this speed, you lose ordering and pay memory cost.

More than 50% of LeetCode Easy problems can be solved in one pass using a hash map. The pattern: as you iterate through the array, for each element, check whether something you’ve already seen (something in your map) combines with this element to give you the answer. If yes, you’re done. If no, store this element in the map and continue.

“Two Sum” is the best example: for each number, check if target - num is already in the map. One pass, O(n) time, O(n) space. Elegant and fast.

Frequency counting. You can replace 90% of sorting-and-comparing with hash maps. Want to check if two strings are anagrams? Count character frequencies in each, compare the frequency maps. O(n) instead of O(n log n).

When not to use hash maps: when you need ordering, or when space is severely constrained, or when you’re dealing with a language that has hash collision concerns in competitive settings.

Heaps (Priority Queues) — Always Getting the Best

A heap is a tree that keeps its smallest (or largest) element at the root. The key operation: extract the minimum in O(log n). No other data structure can do this better.

Any time a problem talks about “the k largest,” “the k smallest,” “the top k,” or anything involving continuously getting the best element from a stream of data — that’s a heap.

The k largest elements pattern. Maintain a min-heap of size k. For each new element, push it to the heap. If the heap exceeds size k, pop the minimum. At the end, everything left in the heap is one of the k largest elements. This processes n elements in O(n log k) time — much better than sorting the entire array.

Merge k sorted lists. Push the first element from each list into a min-heap. Each time you pop the minimum, you get the next element in the merged sorted order. Push the next element from that list into the heap. O(n log k) where k is the number of lists.

Sorting and Divide & Conquer

You need to understand at least two sorting algorithms deeply: Merge Sort and Quick Sort.

Merge sort is O(n log n) guaranteed, stable, and uses the divide and conquer strategy cleanly. It divides the array in half repeatedly, sorts each half recursively, then merges the two sorted halves. The merge step is where all the work happens.

Quick sort is O(n log n) average, O(n²) worst case, but in practice it’s often faster than merge sort because of cache efficiency. The pivot selection matters — always pick a random pivot to avoid worst-case behavior.

More importantly, the divide and conquer pattern extends far beyond sorting. It’s how binary search works, how merge intervals works, how closest pair of points works. The pattern: divide the problem into smaller subproblems of the same type, solve them recursively, combine the results. If combining is cheap (O(n) or less), and the division is roughly equal, you get O(n log n).

Backtracking — Systematic Exploration

Backtracking is how you solve problems that require trying all combinations or permutations. The key: you build your solution incrementally, and when a partial solution can’t possibly lead to a valid complete solution, you abandon it (backtrack) and try a different path.

Think of it like solving a maze. You walk forward until you hit a dead end, then you back up and try a different direction. The algorithm is always the same: make a choice, recurse, undo the choice.

The classic problems: generate all permutations of a list, generate all subsets, solve the N-Queens problem, fill a Sudoku board. The code structure is almost identical for all of them — a backtrack function that iterates over available choices, makes one, recurses, and undoes it.

The performance insight: backtracking is exponential in the worst case (you’re exploring all possibilities), but the “prune bad branches early” optimization makes it much faster in practice than brute force.

---

Phase 3 — Advanced Data Structures (Weeks 8-12)

This is where the interview hard problems live. Get comfortable here and you’re FAANG-ready.

Graphs — The Real World Is a Graph

Practically everything in the real world is a graph. Social networks, road maps, airline routes, package dependencies, web links — all graphs. This is why graph algorithms are so practically important, and why interviewers love them.

A graph is just nodes (vertices) connected by edges. Two flavors: directed (edges have direction, like a one-way street) and undirected (edges go both ways). Edges can have weights (like distance) or not.

BFS finds the shortest path in an unweighted graph. The logic is elegant: since BFS explores level by level, the first time it reaches a destination, it took the minimum number of steps. Queue a node, dequeue it, enqueue its unvisited neighbors. Track visited nodes to avoid infinite loops. For grids (2D arrays), BFS is your default weapon for minimum-steps problems.

DFS is your friend for connectivity. Is there any path between A and B? Are all nodes connected? How many connected components are there? DFS can answer all these. It also powers cycle detection — if DFS visits a node that’s already on the current recursion path, you’ve found a cycle.

Topological Sort orders a directed acyclic graph such that for every edge from A to B, A comes before B. Classic use case: you have a list of tasks where some tasks depend on others — what order do you complete them? Course prerequisites, build systems, task scheduling — all topological sort. Use Kahn’s algorithm (BFS-based) for a clean implementation.

Dijkstra’s algorithm finds the shortest path in a weighted graph (positive weights only). It’s basically BFS but with a priority queue instead of a regular queue, so you always explore the cheapest node next. The runtime is O((V+E) log V), and it’s used in everything from GPS navigation to network routing.

The most common graph interview problems you’ll face: Number of Islands (BFS/DFS on a grid), Clone Graph, Course Schedule (cycle detection), Network Delay Time (Dijkstra), Word Ladder (BFS shortest path).

The Trie — For All Things String

A trie (pronounced “try”) is a tree where each node represents a character. Words share prefixes, so “apple” and “application” would share the “a-p-p-l” path before branching. This makes prefix lookups incredibly fast — O(m) where m is the length of the prefix, regardless of how many words are in the trie.

When do you use a trie? Any time you have problems about autocomplete, word search, prefix matching, or common prefixes. Interviewers love “Design a search autocomplete system” — at its core, that’s a trie.

The implementation is simpler than it sounds. Each node has an array (or map) of child nodes for each possible next character, and a boolean saying “a word ends here.” Insert, search, and starts-with are all O(m) operations where m is the word length.

Dynamic Programming — The Hard Part That’s Worth It

This is the one everyone dreads. And I get it — DP problems look like black magic until you’ve seen enough of them to recognize the patterns. Let me demystify it.

DP is nothing more than recursion with caching. If you can solve a problem recursively, and the same sub-problems are being solved multiple times, you cache the results and call it Dynamic Programming.

There’s a simple test to spot a DP problem: it asks for an optimal value (maximum, minimum) or a count of ways. It has “overlapping subproblems” — the same smaller version of the problem comes up multiple times. And it has “optimal substructure” — the optimal solution can be built from optimal solutions to sub-problems.

The 5 DP categories you must know:

One-dimensional DP is where you start. Climbing stairs, house robber, min-cost climbing — these all have a dp[i] that represents the best answer for the problem up to index i. The recurrence usually involves dp[i-1] and maybe dp[i-2].

Two-dimensional or Grid DP involves a table where dp[i][j] represents the best answer for the subproblem defined by positions i and j. Unique paths on a grid, minimum path sum, edit distance — the table fills from top-left to bottom-right.

The Knapsack pattern shows up in problems about selecting items with constraints: “given weights and values, maximize value within a weight limit.” The key insight: for each item, you either include it or you don’t. That binary choice gives you the recurrence.

Subsequence and string DP compare two sequences character by character, often in a 2D DP table. Longest Common Subsequence, Edit Distance, Longest Palindromic Subsequence — these are the standard hard problems that companies love.

State machine DP is the hardest and most beautiful. The stock trading problems (Best Time to Buy and Sell Stock I through IV) are canonical examples. You have multiple states (holding a stock, not holding, in cooldown) and you track the best value in each state at each time step. The state transitions form the backbone of the recurrence.

My honest advice on DP: Do every DP problem in order of difficulty. Solve Fibonacci bottom-up first. Then Climbing Stairs. Then Coin Change. Then House Robber. Don’t skip to hard DP problems — the pattern recognition builds incrementally. After 30-40 DP problems, you’ll start seeing the category before you’ve read the full problem. That’s when you know it’s clicking.

Big-O — The Language of Interviews

Understanding algorithms is one thing. Analyzing their complexity is what interviewers actually test.

The single most important rule: always know the time and space complexity of your solution before the interviewer asks. Walk them through it as you code. “This is O(n log n) time because of the sort, and O(n) space for the extra array.” That shows you understand what you’re building.

From fastest to slowest: O(1) → O(log n) → O(n) → O(n log n) → O(n²) → O(2ⁿ) → O(n!). For n of one million, O(n²) is already billions of operations — it won’t pass in time. O(n log n) gives you 20 million operations — usually fine. O(log n) gives you 20 — blazing fast.

The mental model I use: on a modern computer, you can do about 10⁸ to 10⁹ simple operations per second. If your algorithm has n = 10⁶ and your solution is O(n²), that’s 10¹² operations — you’re not finishing in this lifetime. O(n log n) at the same n is 2×10⁷, which gives you plenty of room.

---

Phase 4 — Expert Territory (Weeks 13+)

At this point, you can solve most interview problems. Phase 4 is about edge-case scenarios and senior-level expectations.

Advanced graph algorithms like Bellman-Ford (handles negative weights, where Dijkstra fails), Floyd-Warshall (all-pairs shortest path), and Minimum Spanning Trees (Kruskal’s and Prim’s) show up in senior rounds and more specialized roles.

String algorithms like KMP (Knuth-Morris-Pratt) for pattern matching, and the Z-algorithm, teach you to avoid naive O(n²) string matching. These replace brute force substring search with O(n+m) cleverness.

Advanced DP beyond the five categories — interval DP, digit DP, tree DP — these appear in competitive programming and occasional hard interview rounds. They’re extensions of the patterns you already know.

Segment trees and Binary Indexed Trees (Fenwick Trees) solve range query problems efficiently. When you need point updates and range queries both in O(log n), these are your tools. You’ll see them in problems about range sum queries with updates.

---

Common Interview Questions by Company

Here’s what actually gets asked at top companies. I’ve seen these patterns across hundreds of interviews:

Google

• Arrays/Strings: Longest Substring Without Repeating Characters, Trapping Rain Water
• Trees: Serialize and Deserialize Binary Tree, Lowest Common Ancestor
• Graphs: Word Ladder, Number of Islands
• DP: Edit Distance, Longest Increasing Subsequence
• Focus: Clean code, edge cases, optimization discussions

Amazon

• Arrays: Two Sum, Three Sum, Product of Array Except Self
• Trees: Binary Tree Level Order Traversal, Validate BST
• Graphs: Course Schedule (topological sort), Clone Graph
• Design: LRU Cache, Design HashMap
• Focus: Leadership principles, scalability thinking

Meta (Facebook)

• Arrays: Move Zeroes, Merge Intervals, Valid Parentheses
• Trees: Binary Tree Right Side View, Path Sum
• Graphs: Friend Circles (Union Find), Shortest Path in Binary Matrix
• Strings: Add Binary, Multiply Strings
• Focus: Communication, multiple solutions, trade-offs

Microsoft

• Arrays: Rotate Array, Container With Most Water
• Linked Lists: Reverse Linked List, Merge Two Sorted Lists
• Trees: Inorder Traversal, Maximum Depth
• Strings: Reverse Words in a String, String to Integer (atoi)
• Focus: Problem-solving process, testing approach

Apple

• Arrays: Best Time to Buy and Sell Stock, Maximum Subarray
• Trees: Same Tree, Symmetric Tree, Balanced Binary Tree
• Strings: Valid Palindrome, Longest Common Prefix
• Design: Design a Stack with Min Operation
• Focus: Attention to detail, clean implementation

Difficulty Distribution by Round

• Phone Screen: 80% Easy, 20% Medium
• Onsite Round 1-2: 70% Medium, 30% Easy
• Onsite Round 3-4: 60% Medium, 30% Hard, 10% Easy
• Senior Roles: 50% Medium, 40% Hard, 10% Design

What Interviewers Actually Look For

1. Problem clarification - Do you ask about edge cases and constraints?
2. Multiple approaches - Can you discuss brute force before optimizing?
3. Complexity analysis - Do you state time/space complexity without being asked?
4. Clean code - Is your code readable with good variable names?
5. Testing mindset - Do you walk through test cases, including edge cases?
6. Communication - Can you explain your thinking clearly as you code?

---

Essential Resources with Practice Links

Here are the resources that actually matter, in order of importance:

Practice Platforms

• LeetCode - The gold standard. Start with their “Top Interview Questions” list
• NeetCode - Curated list of 150 essential problems with video explanations
• HackerRank - Good for interview prep kits and skill assessments

Visualization Tools

• VisuAlgo - Animated visualizations of algorithms and data structures
• Algorithm Visualizer - Interactive algorithm animations

Learning Resources

• GeeksforGeeks - Comprehensive tutorials and explanations
• Big-O Cheat Sheet - Quick reference for complexity analysis

Books Worth Reading

• Cracking the Coding Interview by Gayle Laakmann McDowell - The interview bible
• Elements of Programming Interviews - More advanced, great for senior roles
• Introduction to Algorithms (CLRS) - The comprehensive reference (not for beginners)

---

How to Actually Practice

Let me give you the practice strategy I recommend to every engineer I mentor:

The 45-minute rule. Give yourself 45 minutes on a problem. If you’re completely stuck at 20 minutes, that’s fine — look at the hints or the category tag. If you’re making progress at 45 minutes, keep going. If you’re totally stuck at 45 minutes, look at the solution, understand it thoroughly, then code it yourself from memory. The understanding, not the solution, is the point.

Never copy-paste solutions. Seriously. Type it out. The muscle memory matters. And you won’t remember anything you didn’t write.

Keep an error log. When you get a wrong answer, add it to a document: what was the bug, what was your mental model that led you astray, what’s the correct mental model? Review this weekly. Mistakes have patterns. Once you see your own pattern, you stop making those mistakes.

Practice dead-code intervals. About once a week, try solving a problem on paper, without running the code. This forces you to think through edge cases and traces your logic. Interviewers notice when you can think on a whiteboard.

Do timed sessions. Once you’re solving problems correctly, start timing yourself. Most onsite interviews give you 45 minutes for a coding question. Practice within that constraint.

The rough target numbers for a strong job search outcome:

• 100+ Easy problems → builds the reflex for common patterns
• 200+ Medium problems → this is the real interview territory
• 50+ Hard problems → differentiates you for senior roles
• 350+ total → you’re in the top 10% of candidates

---

Track Your Progress: The Metrics That Matter

Don’t just solve problems randomly. Track your progress systematically to know when you’re ready.

Essential Metrics to Track

1. Problems Solved by Difficulty

• Easy: ___ / 100 (Target: 100+)
• Medium: ___ / 200 (Target: 200+)
• Hard: ___ / 50 (Target: 50+)

2. Problems by Pattern (Track first 100 problems)

• Two Pointers: ___ / 15
• Sliding Window: ___ / 15
• Binary Search: ___ / 10
• DFS/BFS: ___ / 20
• Dynamic Programming: ___ / 20
• Backtracking: ___ / 10
• Other: ___ / 10

3. Success Rate

• Solved without hints: ___% (Target: 60%+)
• Solved within 45 min: ___% (Target: 70%+)
• Optimal solution first try: ___% (Target: 40%+)

4. Weekly Consistency

• Days practiced this week: ___ / 7 (Target: 5+)
• Current streak: ___ days (Target: 30+ days)
• Hours this week: ___ (Target: 10-14 hours)

Progress Milestones

Beginner (0-50 problems)

• ✓ Can solve Easy problems with hints
• ✓ Understand basic patterns (two pointers, hash maps)
• ✓ Know Big-O notation basics
• Ready for: Entry-level phone screens

Intermediate (50-150 problems)

• ✓ Solve most Easy problems without hints
• ✓ Solve Medium problems with some struggle
• ✓ Recognize patterns quickly
• Ready for: Mid-level interviews, some FAANG phone screens

Advanced (150-300 problems)

• ✓ Solve Easy problems in <15 minutes
• ✓ Solve Medium problems in 30-45 minutes
• ✓ Attempt Hard problems with reasonable approach
• Ready for: FAANG onsites, senior roles

Expert (300+ problems)

• ✓ Solve most Medium problems in <30 minutes
• ✓ Solve Hard problems with multiple approaches
• ✓ Can teach patterns to others
• Ready for: Senior/Staff roles, competitive offers

Weekly Review Checklist

Every Sunday, review your week:

• Did I solve at least 5 problems?
• Did I review problems I got wrong?
• Did I learn a new pattern or technique?
• Can I explain my solutions clearly?
• Did I practice without looking at solutions first?

Red Flags (Time to Slow Down)

• Solving problems but not understanding why solutions work
• Looking at solutions after <20 minutes of trying
• Not reviewing problems you got wrong
• Skipping complexity analysis
• Jumping between topics without mastery

Green Flags (You’re on Track)

• Recognizing patterns before reading full problem
• Solving variations of problems you’ve seen
• Explaining solutions clearly to others
• Catching your own bugs during testing
• Feeling more confident week over week

Sample Progress Tracker (Spreadsheet Format)

Date	Problem	Difficulty	Pattern	Time	Solved?	Notes
3/14	Two Sum	Easy	Hash Map	15min	✓	Easy, one-pass solution
3/14	3Sum	Medium	Two Pointers	45min	✓	Struggled with duplicates
3/15	Max Subarray	Easy	Kadane’s	20min	✓	Reviewed DP approach

Download Template: Create a Google Sheet with these columns and track every problem. Review monthly to see patterns in your struggles.

---

Key Takeaways

After years of experience, here’s what I know for certain:

Start with arrays and don’t leave until you’ve internalized two pointers, sliding window, prefix sums, and binary search. Every other data structure builds on this foundation.

Trees then graphs, in that order. Trees are graphs without cycles. Understanding tree DFS and BFS makes graph algorithms obvious — they’re the same algorithms with more complexity.

DP is the great equalizer. Candidates who crack DP problems confidently tend to land the best offers. Invest disproportionately here once you have the fundamentals.

Time complexity is half the answer. Always know and state your complexity. “It’s O(n) time and O(1) space” is a complete answer. “It works” is not.

Patterns over problems. Once you label “this is a sliding window problem” or “this is a classic DFS with backtracking,” the solution framework appears. That’s the skill experienced interviewers test for.

Consistency over everything. Two hours a day for six months. Every day. Skip two days and it’s fine. Skip two weeks and you’ll feel like you’re starting over. Protect those daily sessions like they’re meetings you can’t cancel.

---

The Bottom Line

DSA isn’t a mountain you climb once and stand at the top. It’s more like a language — the more you practice, the more fluent you get, and you never really stop improving.

Start with Phase 1. Really start. Today. Don’t wait until you finish reading this. Pick up one Easy array problem and work through it. Don’t look at the solution for at least 20 minutes. Get comfortable being uncomfortable.

The difference between engineers who crack top-company interviews and those who don’t isn’t raw intelligence. It’s consistent, deliberate practice with an organized framework. Now you have the framework.

---

Working through a tough problem and feeling stuck? Let’s talk — I’m happy to walk through specific DSA patterns with you.