Graphs are the most feared topic in coding interviews — not because they're impossible, but because most people learn BFS, DFS, and Dijkstra in isolation without understanding when to use each one.

This guide gives you the decision framework that turns graph problems from guesswork into a systematic process.

---

The three algorithms every interviewer expects you to know

BFS — Breadth-First Search

Data structure: Queue (FIFO)
Complexity: O(V + E) time, O(V) space

Use when:

• You need the shortest path in an unweighted graph
• You need the minimum number of steps to reach a target
• You need to explore nodes level by level

Don't use when: the graph has weighted edges — BFS treats all edges as equal cost.

Classic problems: Binary Tree Level Order Traversal, Rotting Oranges, Word Ladder, Shortest Path in Binary Matrix.

Interview tip: Always say explicitly: "I'm using BFS because I need the shortest path in terms of edges, and BFS guarantees the first time I reach a node it's via the shortest path." That sentence shows you understand the why, not just the how.

---

DFS — Depth-First Search

Data structure: Stack (implicit via recursion, or explicit)
Complexity: O(V + E) time, O(V) space

Use when:

• You need to detect cycles
• You need to find all paths (not just shortest)
• You need to check connectivity or count connected components
• You need topological sort

Don't use when: you need the shortest path — DFS doesn't guarantee it.

Classic problems: Number of Islands, Course Schedule, Clone Graph, Pacific Atlantic Water Flow.

Interview tip: The most common DFS bug is forgetting to mark nodes as visited before recursing. Always set visited[node] = true at the start, before processing neighbors.

---

Dijkstra's Algorithm

Data structure: Min-heap (priority queue)
Complexity: O((V + E) log V) time, O(V) space

Use when:

• The graph has weighted edges with non-negative weights
• You need the shortest distance from source to target (or all nodes)

Don't use when: the graph has negative edge weights — use Bellman-Ford instead.

Classic problems: Network Delay Time, Path With Minimum Effort, Cheapest Flights Within K Stops.

Interview tip: The Dijkstra pattern is always the same: push (cost, node) to the heap → pop cheapest → skip if visited → process neighbors. Know O((V+E) log V) and be able to explain why.

---

The decision framework

When you see a graph problem, run through this before writing a single line of code:

The single question to ask first: "Does the graph have weights?"

• No → choose between BFS (shortest path) and DFS (full exploration)
• Yes → Dijkstra (non-negative) or Bellman-Ford (negative weights)

That question narrows the decision from three options to two in almost every case.

---

What interviewers actually look for

Senior interviewers rarely test whether you can implement BFS from scratch. They test whether you can reason about graph problems systematically.

What separates strong candidates:

1. Clarifying the graph structure before coding. Directed or undirected? Weighted or unweighted? Can there be cycles? These change the algorithm — asking shows you're not pattern-matching blindly.

2. Explaining why you chose the algorithm. "I'm using BFS because the graph is unweighted and I need minimum steps" is a complete answer. "I'll use BFS" is not.

3. Recognizing implicit graphs. Many problems don't say "graph" — they present a grid, a word transformation, a dependency list. Rotting Oranges is multi-source BFS. Word Ladder is shortest path on an implicit graph.

4. Knowing complexity without being asked. O(V + E) for BFS and DFS, O((V + E) log V) for Dijkstra. Being able to derive these (not just recite them) is the difference at top companies.

---

How to study so graph algorithms actually stick

Most resources explain algorithms in isolation — here's how BFS works, here's DFS — without building the mental model of when to use each one.

What actually works:

1. Watch execution before writing code. For BFS, watch the queue grow and shrink level by level. For Dijkstra, watch the min-heap pop nodes in cost order and the distance table update. This visual step makes implementation feel natural.

2. Implement on the same graph. Take a 5-node, 7-edge graph. Run BFS, then DFS, then Dijkstra (with weights). Seeing three different traversal orders on the same graph makes the differences concrete.

3. Practice on grid problems. A 2D grid is a graph where each cell is a node and adjacent cells are edges. Grid problems are the most common disguised graph problems in interviews — the pattern transfers directly.

4. Build the decision reflex. After solving, write one sentence: "This is BFS because the graph is unweighted and I need shortest path." Train the recognition, not just the implementation.

---

FAQ

When should I use BFS vs DFS in a coding interview?

Use BFS when you need the shortest path in an unweighted graph or the minimum number of steps. Use DFS when you need all paths, cycle detection, or connectivity. If shortest path isn't required, both work — DFS is simpler to implement recursively.

What is the difference between BFS and Dijkstra?

BFS finds shortest path by number of edges (unweighted, every edge = cost 1). Dijkstra finds shortest path by total weight (weighted, uses min-heap). BFS for "minimum hops", Dijkstra for "minimum cost."

Can DFS find the shortest path?

No. DFS finds a path, not necessarily the shortest. Use BFS for unweighted shortest path, Dijkstra for weighted.

---

I built Expora to solve exactly this — the gap between knowing how an algorithm works and knowing when to use it. Expora's visual debuggers show BFS, DFS, and Dijkstra executing step by step on real graphs, so you build the decision intuition that interviewers test, not just the ability to implement from memory.

---

Originally published at tryexpora.com/blog/graph-algorithms-coding-interview