DSA / Chapter 03 of 04
This is the chapter where the earlier patterns become reusable tools. You stop asking only “what technique?” and start asking “what is the right structure for this problem, and why?”
Trees / heaps / graphs / traversal / backtracking / greedy
Chapter outcomeChoose a structure and defend the tradeoff under pressure.More structure. More depth. Better tradeoffs.
By this point, the goal is not to collect random tricks. It is to understand when a data shape changes the problem itself.
Move beyond lists and learn the recursive structure of a tree: root, children, subtrees, and parent-child relationships. Questions become clearer when you can describe a solution in terms of a node and its descendants.
Leave with: You can reason through tree traversals, root-to-leaf paths, and subtree properties without guessing at implementations.
Study binary trees ->Heaps are the data structure behind efficient top-k logic, scheduling, and median tracking. They give you the ability to extract the smallest or largest item in controlled time while keeping the rest of the data organized.
Leave with: You can choose a heap when a single best value matters and decide when a sorted structure is too heavy.
Learn heaps ->The graph chapter is about modeling relationships: neighbors, dependencies, distances, and connectivity. It combines the patterns from earlier chapters into a more connected, more realistic system.
Leave with: You know when to use BFS, DFS, shortest-path logic, or component counting to answer a graph question.
Explore graph patterns ->Some problems require exploring valid branches and undoing a choice when it fails. Others can be solved by making the locally best move and proving it stays globally correct. Learn the difference.
Leave with: You can tell when a problem is a search problem versus a choice problem and avoid infinite or incorrect recursion.
Read greedy strategy ->Level-up problems reward clarity, not just speed.
The next gain comes from asking better questions before the code. The structure matters as much as the final implementation.
Practice recursive structure, not just traversal code. Before writing a solution, ask: what is the node doing, and what should its children contribute?
Define neighbors, visited state, and stop conditions early. Graph bugs usually come from mixing representation details with algorithm logic.
A faster algorithm is not the goal if it hides the reason. The right answer is the one you can explain, defend, and re-implement from memory.
Pick the structure before you optimize the code.
Most hard problems stop being hard when you can name the right structure quickly and avoid debugging the wrong abstraction.
Recognition signal
The input has a root, parent-child relationships, nested structure, or a question about every subtree.
How to approach it
Define what the current node should return, then let the left and right children provide the smaller answers. Use DFS for subtree or path reasoning and BFS when the level matters.
Problem shape
Find the maximum depth, validate a binary search tree, or calculate the best root-to-leaf path.
Watch for
Do not treat a tree like a flat array. Write the base case first and decide whether the answer belongs at the node, on the path, or across both subtrees.
Recognition signal
The question repeatedly asks for the next smallest, largest, earliest, or most important item as new data arrives.
How to approach it
State the heap invariant before coding. Keep the best K items when the answer is Top K, or use two heaps when values must be split around a running median.
Problem shape
Find the Kth largest value, merge sorted streams, schedule the next available job, or track the median of a data stream.
Watch for
A heap only guarantees access to its best current item. Do not assume the remaining elements are fully sorted, and check whether a min-heap or max-heap should discard first.
Recognition signal
The entities are connected by relationships, and the useful answer depends on paths, neighbors, components, or dependency order.
How to approach it
Model the nodes and edges before choosing BFS, DFS, topological sort, or shortest-path logic. Define visited state and edge direction explicitly.
Problem shape
Count islands, find the shortest route, detect a cycle, determine course order, or group connected accounts.
Watch for
Most graph bugs come from an incomplete model: forgetting disconnected components, reversing an edge, or marking a node after it has already been queued.
Recognition signal
The problem asks for every valid arrangement, combination, path, or choice sequence rather than one simple greedy answer.
How to approach it
At each level, choose an option, recurse with the updated state, then undo it. Prune only when the partial answer cannot become valid.
Problem shape
Generate subsets, solve N-Queens, build valid parentheses, or find every word path on a board.
Watch for
Keep the choice, constraint, and undo step visible. Be precise about whether an item can be reused and whether duplicate branches are allowed.
Use a repeatable method when the problem feels messy.
Strong problem solvers do not jump straight into coding. They narrow the problem, decide the structure, and test the logic before the final implementation.
State the problem in one sentence: what are you actually optimizing or finding?
Identify the structure: tree, heap, graph, subset search, or greedy choice problem?
Write down the state variables and the invariant you want to preserve.
Choose a brute-force or simplest correct idea before optimizing it.
Test the logic on a tiny example before writing the polished version.
Fix the edge cases and then reason about complexity out loud.
Only then code the final solution and verify it on a second example.
These mistakes show up again and again.
A lot of confusion in advanced DSA comes from not naming the state or from forcing a pattern onto a problem that is asking a different question.
Make the upgrade visible.
Do not rush to mock interviews before you can identify the real structure behind a problem. The better question is always the one you ask before writing the first line of code.