🧠 The Graph Traversal Recipe That Simplified Every Graph Problem I Solved

By Sai Pranav Moluguri

Recently, while solving graph problems, I noticed a pattern that kept appearing over and over again.

At first, every graph problem felt different.

Some problems wanted:

• DFS Traversal
• BFS Traversal
• Has Path
• Connected Components
• Node Counting
• Shortest Path

The outputs were different.

The goals were different.

The return values were different.

But eventually, something clicked.

I realized that most graph problems were using the exact same traversal recipe.

The only thing changing was the work being performed at each node.

The Recipe

After solving several graph problems, I found myself repeatedly following the same sequence:

Take node
↓
Already visited?
↓
Skip if yes
↓
Mark visited
↓
Do the node's work
↓
Explore neighbors

Once I started viewing graph problems through this lens, they became much easier to reason about.

Example 1: DFS Traversal

Suppose we want to collect all nodes.

The work becomes:

res.append(node)

The traversal skeleton:

if node in visited:
    return

visited.add(node)

res.append(node)

for neighbour in graph[node]:
    dfs(neighbour)

The purpose of the node is simply to contribute itself to the result.

Example 2: Has Path

Now suppose the problem changes.

Instead of collecting nodes, we want to answer:

Does a path exist from source to destination?

The traversal barely changes.

The work becomes:

if node == dst:
    return True

Example:

if node in visited:
    return False

visited.add(node)

if node == dst:
    return True

for neighbour in graph[node]:
    if dfs(neighbour):
        return True

return False

The traversal is the same.

The node’s responsibility changed.

Example 3: Connected Components

Now suppose we want to count connected components.

Again, the traversal stays almost identical.

The work shifts toward discovering unvisited regions of the graph.

The exploration process remains unchanged.

The Realization

Before this, I was treating graph problems as completely separate techniques.

Now I think about them differently.

The traversal is usually already known.

The important question becomes:

What should happen when I visit a node?

Examples:

Traversal:

res.append(node)

Path Checking:

if node == dst:

Counting:

count += 1

Finding a Minimum:

best = min(best, value)

The graph exploration doesn’t change very much.

The node’s work changes.

Why The Visited Check Comes First

Another thing that became clear was the order of operations.

The correct pattern is:

Take node
↓
Already visited?
↓
Skip if yes
↓
Mark visited
↓
Do the node's work
↓
Explore neighbors

Why?

Because once a node has already been processed, we don’t want to:

• Process it again
• Count it again
• Add it to the result again
• Explore its neighbors again

The visited set protects us from duplicate work and prevents infinite loops in cyclic graphs.

A Question I Ask Now

Whenever I encounter a graph problem, I ask:

What is the work that needs to happen when I visit a node?

Once I answer that question, the traversal often becomes much easier to write.

The biggest lesson wasn’t about DFS.

It wasn’t about BFS.

It was realizing that many graph problems share the same traversal recipe.

Once I understood the recipe, I could focus on the actual problem instead of rebuilding the traversal logic every time.

Sometimes learning isn’t about discovering a new algorithm.

It’s about recognizing the pattern that was already there.

About Me

I am Sai Pranav Moluguri, a recent Master’s graduate in Computer Science from Florida Atlantic University (FAU).

My interests include:

• Backend Development • Full-Stack Engineering (MERN Stack) • Distributed Systems & Scalable Architectures

I am currently preparing for Software Development Engineer opportunities and targeting FAANG-level roles.

Forever Learning. Forever Growing.

— Sai Pranav Moluguri