Graph problems scare people more than they should. The reason isn't the graphs. It's that most of us learn graphs as a pile of named algorithms - BFS, DFS, Dijkstra, union-find, topological sort - without a model for when each one shows up. So every new problem feels like a fresh puzzle.
Here's the shift that fixed it for me. A graph isn't a special data structure you have to be handed. It's just "things and the connections between them." Once you see the things and the connections, you've already built the graph in your head. The rest is picking a traversal.
Step one: find the nodes and edges
Before you write any code, answer two questions.
What are the nodes? What connects two nodes?
That's it. Most "this isn't a graph problem" problems are graph problems wearing a costume.
- A grid of cells? Each cell is a node. Edges connect a cell to its neighbors up, down, left, right.
- A list of course prerequisites? Each course is a node. An edge points from a prerequisite to the course that needs it.
- Words you can transform one letter at a time? Each word is a node. An edge connects two words that differ by one letter.
- People who know each other? Person is a node, "knows" is an edge.
When you can say the nodes and edges out loud, you stop seeing a word problem and start seeing a graph. That's most of the battle.
Step two: pick BFS or DFS by what you're asked
Once it's a graph, you almost always start with one of two traversals. The question tells you which.
Use BFS (a queue, level by level) when you care about distance or the fewest steps. Shortest path on an unweighted graph, minimum number of moves, "how many layers out" - that's BFS. It explores everything one step away, then two steps away, so the first time you reach the target, you reached it in the fewest steps.
Use DFS (recursion or a stack) when you care about reachability or structure. Can I get from A to B at all? How many separate islands are there? Does a cycle exist? Is there any valid path? DFS dives down one route as far as it goes, then backtracks.
A rough rule: if the problem says "shortest," "nearest," or "minimum number of," reach for BFS. If it says "is there a path," "how many groups," or "detect a cycle," reach for DFS. Both visit every node once, so they cost about the same. You're choosing based on what answer you need, not speed.
Step three: don't visit the same node twice
This is the bug that wrecks more graph solutions than anything else. Without a visited set, your traversal loops forever the moment there's a cycle, or it redoes the same work exponentially.
The fix is one line of discipline. Keep a set. Before you process a node, check if it's in the set. If it is, skip it. If it isn't, add it, then process it.
For grids, your visited can be the grid itself - mark a cell as you leave it so you don't come back. Same idea, less memory.
If your traversal is slow or hangs, this is the first thing to check.
A worked shape: number of islands
Classic problem. A grid of land and water, count the separate landmasses.
Nodes are land cells. Edges connect adjacent land cells. You want "how many groups," so DFS.
Walk every cell. When you hit unvisited land, that's a new island, so add one to your count. Then DFS out from that cell, marking every connected land cell visited so you don't count it again. Move on. When the grid's done, your count is the answer.
Notice you didn't memorize an "islands algorithm." You found the nodes and edges, picked DFS because of "how many groups," and used visited to avoid double-counting. The same three steps.
When the basic two aren't enough
Most interview graph problems are solved by plain BFS or DFS plus a visited set. Learn those cold first. They cover more ground than people expect.
When edges have weights and you need the cheapest path, BFS isn't enough and you reach for Dijkstra. When you need a valid ordering that respects dependencies (build order, course schedule), that's topological sort. When you're repeatedly merging groups and asking "are these two connected," that's union-find. But don't start there. Reach for the heavier tool only when the simple traversal can't answer the question.
How to practice this
Pick ten graph problems and, before coding any of them, write one sentence: "Nodes are ___, edges are ___, and I'll use BFS/DFS because ___." Don't solve them yet. Just do the framing.
You'll find the framing is the hard part and the code is short once it's done. After a dozen reps, you'll read a new problem and the nodes, edges, and traversal will surface on their own. That recognition is the whole skill. If you want reps under pressure, a few timed mock interviews on graph problems will tell you fast whether the model has actually stuck.
Graphs stopped being scary for me when I quit treating each one as new. Find the things, find the connections, pick the traversal, track what you've visited. Same four moves, every time.