🧠 What I Learned While Revisiting the Shortest Path Graph Problem

By Sai Pranav Moluguri

Recently, I revisited one of the earliest graph problems I had solved: finding the shortest path in an unweighted graph.

I wasn’t solving it for the first time.

I was revisiting it from memory to strengthen my understanding instead of relying on solutions I had written before.

During this revision, I noticed a mistake that completely changed the way I think about Breadth-First Search.

It wasn’t a syntax mistake.

It was a thinking mistake.

And fixing it helped me understand why BFS is able to find shortest paths in the first place.

My First Attempt

My original solution looked something like this:

from collections import defaultdict, deque

def shortest_path(edges, node_A, node_B):
    graph = defaultdict(list)

    for a, b in edges:
        graph[a].append(b)
        graph[b].append(a)

    visited = set()
    return bfs(graph, node_A, node_B, 0, visited)

def bfs(graph, src, dst, dist, visited):
    q = deque([src])

    while q:
        node = q.popleft()

        if node in visited:
            continue

        if node == dst:
            return dist

        visited.add(node)
        dist += 1

        for nei in graph[node]:
            q.append(nei)

    return -1

At first glance, it looked reasonable.

I initialized the distance as 0.

Every time I visited a node, I increased the distance.

But there was a fundamental flaw.

I wasn’t measuring the shortest path.

I was simply counting how many nodes I had visited.

The Realization

Consider this graph:

a
     / \
    b   c
    |    \
    d     e

The actual shortest distances from a are:

a = 0
b = 1
c = 1
d = 2
e = 2

But my algorithm behaved like this:

Visit a → distance = 0

Visit b → distance = 1

Visit c → distance = 2

That immediately exposed the problem.

Node c is only one edge away from a.

But my algorithm assigned it a distance of 2.

The reason became obvious.

I wasn’t tracking the distance of each node.

I was increasing one global counter after every visit.

Those are two completely different ideas.

The Biggest Lesson

Every node has its own shortest distance from the source.

There isn’t one distance variable shared by the entire traversal.

Instead, each node must carry its own distance as it moves through the queue.

That completely changes what the queue stores.

Instead of:

queue = deque([source])

the queue becomes:

queue = deque([(source, 0)])

Every element now contains:

(node, distance)

When exploring neighbors, their distance naturally becomes:

current_distance + 1

That is exactly what BFS is computing.

Not the number of visited nodes.

The shortest number of edges from the source.

My Final Implementation

from collections import defaultdict, deque

def shortest_path(edges, node_A, node_B):
    graph = defaultdict(list)

    for a, b in edges:
        graph[a].append(b)
        graph[b].append(a)

    visited = set()
    return bfs(graph, node_A, node_B, visited)

def bfs(graph, src, dst, visited):
    q = deque([(src, 0)])

    while q:
        node, dist = q.popleft()

        if node in visited:
            continue

        if node == dst:
            return dist

        visited.add(node)

        for nei in graph[node]:
            q.append((nei, dist + 1))

    return -1

I really like how natural this solution feels.

Every node carries exactly the information needed to continue the search.

Nothing more.

Nothing less.

Another Pattern I Reinforced

While revisiting this problem, I also realized something that applies to many graph problems.

The data stored inside the queue depends on what the algorithm needs.

For a normal BFS traversal, the queue only needs the node:

queue = deque([start])

For checking whether a path exists, the queue still only needs the node:

queue = deque([start])

But for shortest path, that is no longer enough.

The queue must store both the node and its distance:

queue = deque([(start, 0)])

That small change is what makes the algorithm correct.

My Takeaway

Revisiting this problem reminded me that understanding an algorithm is very different from remembering code.

The bug in my first solution wasn’t caused by forgetting Python syntax.

It happened because I forgot what the algorithm was actually measuring.

I was measuring how many nodes I had visited.

BFS measures how many edges it takes to reach each node.

Once I recognized that every node has its own distance, the implementation became straightforward.

This revision also reinforced something I’ve been learning throughout my DSA journey:

The hardest part is rarely writing the code.

The hardest part is identifying what information each state of the algorithm needs to carry.

Once that becomes clear, the implementation often becomes much simpler.

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
• Data Structures & Algorithms
• Artificial Intelligence and LLMs

I am currently preparing for Software Development Engineer opportunities while continuing to strengthen my understanding of computer science fundamentals through consistent practice and reflection.

Forever Learning. Forever Growing.

— Sai Pranav Moluguri