How to Solve Graph Problems You've Never Seen

How to solve graph problems when you've never seen them before? Two engineers open the same problem. One stares at the description for ten minutes, writes nothing, and eventually guesses BFS. The other spends two minutes asking four questions, identifies it as a connected components task, and finishes a clean DFS solution with twelve minutes to spare.

They both know the same algorithms, so the difference isn't knowledge. One has a repeatable process for translating an unfamiliar problem into an algorithm choice. The other is matching against memory.

Why graph problems feel different

A graph problem is any problem where the solution depends on relationships between entities, whether those relationships are explicit (an edge list) or implicit (grid adjacency, dependency lists, network connections). That range of disguises is what makes them feel unpredictable. Graph problems aren't harder because the algorithms are more complex. They're harder because the modeling step is invisible.

With arrays, the data structure is given to you. You see an array, you think about two pointers or sliding windows. With trees, the structure is in the input. You see a root node with children, and traversal is the obvious starting point.

Graphs don't work that way. Most graph problems don't hand you an adjacency list. They hand you a grid, a list of dependencies, a network of cities, or a set of connections. Your first job isn't selecting an algorithm. It's recognizing that you're looking at a graph at all.

This is why knowing all five graph patterns doesn't prevent freezing on problems you haven't practiced. The translation from problem description to graph structure is where engineers actually get stuck.

Some graph problems (graph coloring, traveling salesman) are genuinely unsolvable in polynomial time, and the research on approximation algorithms for those is fascinating in its own right. But those rarely show up in coding interviews. Interview graph problems almost always map to one of five well known algorithms. The hard part is always the translation, not the algorithm.

How to solve graph problems with four questions

Every graph problem asks about a specific property, whether that's connectivity, shortest path, ordering, or cycles. Four repeatable questions turn unfamiliar problems into clear decisions. They work in order, and each one narrows the space for the next.

What are the nodes? Nodes are the individual entities or states, like people in a social network, cells in a grid, or courses in a dependency system. When the problem describes things that connect to other things, those things are your nodes.

What are the edges? Edges define relationships between nodes. Are two cells adjacent? Is course A a prerequisite for course B? Can you fly from city X to city Y? After naming the edges, ask two follow ups. Are the edges directed (one way) or undirected? Do they carry weights (costs, distances, times)?

What property is the problem asking about? This step gets skipped in favour of jumping straight to algorithms. Don't. Every graph problem targets one of five properties.

Naming the property narrows your algorithm choices from "everything you know" to two or three candidates. Which algorithm fits the property? Once you know the property, selection is almost mechanical.

Solve graph problems in practice with counting islands

This doesn't look like a graph problem at first. There's no edge list and no mention of nodes. But watch what happens when you run the four questions.

Nodes are each cell in the grid. Edges connect two cells if they're adjacent (up, down, left, right) and both contain 1. The edges are undirected and unweighted.

Property is "how many groups?" That's connectivity, specifically the number of connected components.

Algorithm is DFS or BFS from any unvisited 1. Traverse all reachable 1s, mark them visited, increment the count. Repeat until no unvisited 1s remain.

The whole problem collapses once you name the property. You didn't need to memorize "island count equals connected components." You needed to recognize that "how many groups of connected things" is always a connectivity question. The algorithm followed from the property, not from having seen this exact problem before.

Two more problems, same four questions

Course prerequisites

Courses are your nodes, and prerequisites create directed edges: if course 0 must come before course 1, draw an edge from 0 to 1. The question "can everything be ordered?" is an ordering problem, which means topological sort. If the sort processes all n nodes, the answer is yes. If it can't, a cycle exists and the answer is no. The cycle check comes free here, since a directed graph has a valid topological order if and only if it contains no cycles.

Cheapest flights with at most K stops

Cities are your nodes, and flights are directed, weighted edges. The question is shortest path, but with a constraint: maximum K edges in the path.

Your first instinct might be Dijkstra's. But Dijkstra greedily picks the cheapest next node without tracking how many edges you've used. The K stops constraint means path length matters, not just cost. A better fit: BFS processing one level per stop, or Bellman-Ford run for exactly K+1 iterations.

Naming the constraint before selecting the algorithm prevented a Dijkstra implementation that would've needed awkward modification mid solve. Two minutes of thinking saved ten minutes of debugging.

Common mismatches when solving graph problems

Even with the four questions, certain mistakes keep showing up. Worth knowing what they are so you can catch them faster.

Think before you implement

The four questions work because they force you to think about the problem before the solution. Every pattern module in Codeintuition's graph course follows the same principle: understand the mechanism, learn to identify when it applies, then solve problems with increasing difficulty. The identification lesson for connected components, for example, teaches the signals that distinguish a connectivity problem from a shortest path problem before you attempt a single problem.

One more thing worth practicing: mentally trace the algorithm on a specific input before writing code. Walk through BFS on your grid and predict the traversal order node by node. You'll catch edge cases before your first submission.

The same identification first approach works across all of DSA.

For dynamic programming, a similar three part identification test determines whether a problem needs DP before you start building a recurrence. Map the problem before you solve it.

You can try the full teaching approach before deciding whether it fits how you learn. The first two courses (Arrays and Singly Linked List) are free and use the same identification first method that the Graph course builds on. The complete learning path is $79.99/year.

Think about the last time you opened a graph problem. You probably read the description three times and started coding BFS because it's the algorithm you remembered best. Now picture this instead: you spend two minutes naming nodes, edges, and the property. The algorithm falls out naturally, and you haven't written a line of code yet. That's the shift.