Forem: Alex Mateo

Graph Algorithms for Coding Interviews: When to Use BFS, DFS, or Dijkstra

Alex Mateo — Thu, 23 Apr 2026 08:12:38 +0000

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:

Signal	Algorithm	Reason
Unweighted graph, need shortest path	BFS	Expands level by level — first reach = shortest
Minimum number of steps / hops	BFS	"Steps" = edges = unweighted
Weighted graph, all weights ≥ 0	Dijkstra	Greedy expansion via min-heap
Weighted graph with negative edges	Bellman-Ford	Dijkstra's greedy assumption breaks
Cycle detection	DFS	Track visited + in-stack state
All paths, not just shortest	DFS + backtracking	BFS doesn't enumerate all paths
Connected components / flood fill	DFS or BFS	Either works — DFS simpler recursively
Topological sort	DFS or Kahn's BFS	DFS post-order = reverse topological order

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:

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.
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.
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.
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

Why LeetCode is So Hard — and Why Grinding More Problems Won't Help

Alex Mateo — Tue, 21 Apr 2026 08:23:18 +0000

Here's why grinding leads to memorization, not understanding, and what to do instead.

You've solved 150 problems. You read the editorial. You watched the NeetCode video.

And then a slightly different problem appears in the interview and you blank.

It's not you. It's what you've been practicing.

The real reason LeetCode feels impossible

When developers say LeetCode is hard, they usually mean the problems are tricky or
they can't figure out the right approach. But there's a third reason nobody talks
about — LeetCode only shows you the answer, not the thinking.

Submit a solution. Green checkmark. Move on.

What the platform doesn't show you is what happened inside the algorithm: which
variable changed, why a pointer moved, what the data structure looked like at step 3.
You only ever see the output.

This matters because coding interviews don't test if you know the answer.
They test if you can explain the reasoning.

When an interviewer asks "why did you use a hashmap here?", the correct answer
isn't the solution — it's the thought process behind it. LeetCode trains you to
produce solutions. It doesn't train you to understand them.

What LeetCode shows you	What you actually need
✗ Input and output	✓ What the algorithm does at each step
✗ Runtime and memory stats	✓ Why a specific data structure was chosen
✗ Green or red checkmark	✓ How the state changes with each decision
✗ The accepted solution (after you fail)	✓ The intuition that transfers to new problems

That gap between "submitting a solution" and "understanding an algorithm" is why
LeetCode feels hard even after hundreds of problems.

What grinding actually does to your brain

The conventional advice is: do more problems. Grind 75, then 150, then 300.
The theory is that pattern recognition emerges from volume.

Here's the problem: pattern recognition requires understanding, not repetition.

You can't recognize that a problem needs a sliding window if you only know that a
previous problem that looked similar used a sliding window. That's memorization.

It breaks the moment the problem is phrased differently.

The grinding trap: You solve problem #47 and feel like you understand
two pointers. Three weeks later, a different two-pointer problem appears and
you can't start it. You go back and re-solve problem #47. The cycle repeats.
You're not building understanding — you're fighting the Ebbinghaus forgetting
curve with repetition instead of comprehension.

The developers who pass FAANG interviews typically haven't solved more problems
than the ones who fail. They've understood fewer problems more deeply.

The difference between memorizing and understanding

Here's a concrete example. Most developers who have done LeetCode know Two Sum.

Ask them to solve it: they'll write a hashmap solution in two minutes.

Now ask them: "If the input array is sorted, which approach is better?"

Many will still reach for the hashmap — because that's what they practiced.
They memorized the solution, not the reasoning behind choosing it.

Understanding means being able to trace through the algorithm at each step:

nums = [2, 7, 11, 15], target = 9

Step 1: L=0, R=3 → sum = 2+15 = 17 > 9
        → Too large. Move R left.
        → WHY: sorted array, moving R left always decreases sum.

Step 2: L=0, R=2 → sum = 2+11 = 13 > 9
        → Still too large. Move R left again.

Step 3: L=0, R=1 → sum = 2+7 = 9 ✓
        → Found it.

Key insight: sorted input makes two pointers strictly better than hashmap.
O(n) time, O(1) space vs O(n) space. The code is almost identical —
the understanding is completely different.

The difference isn't the code. It's being able to explain why the approach
changes when the input is sorted.

Understanding an algorithm means answering 3 questions at any step

What is the current state? Where are the pointers, what's in the queue,
what does the data structure look like right now?
Why did the last step happen? What condition triggered this move,
this push, this comparison?
What will happen next? Given the current state, can you predict the
algorithm's next decision before it happens?

You can't answer any of these by reading the accepted solution. You need to
see the algorithm run.

What to do instead of grinding

1. Learn patterns, not solutions

Most coding interview problems are variations of 7-10 core patterns: Sliding Window,
Two Pointers, BFS, DFS, Binary Search, DP, and Dijkstra. Learn them at the
pattern level — not the problem level. When you recognize the pattern, the
solution follows.

2. See execution, not just code

Before writing anything, trace through the algorithm manually. Watch the state
change. Understand why each step happens. Only then write the code.

3. Solve fewer problems, more deeply

One deeply understood problem — where you can explain every step, every decision,
every tradeoff — is worth more than 10 memorized solutions.

4. Practice explaining out loud

After solving, close the editor and explain the solution as if talking to an
interviewer. If you can't explain why each line exists, you memorized it.

FAQ

Is LeetCode worth it?

LeetCode is worth it if you use it to build understanding, not just to accumulate
solved problems. Used correctly — slowly, with deliberate tracing — it's a useful
problem bank. Used as a grinding machine, it builds recall that breaks under
interview pressure.

How many LeetCode problems do I need for Google or Meta?

There's no magic number. Being able to trace 50 algorithms step by step and explain
every decision beats having memorized 300 solutions. Interviewers evaluate your
reasoning, not your problem count.

What is grinding LeetCode?

Grinding LeetCode means solving a high volume of problems (150-300+) with the goal
that pattern recognition emerges from volume. It's the dominant prep approach, but
it fails when problems are phrased differently or when interviewers ask you to
explain your reasoning.

I built Expora specifically because I was that developer —
I had Grokking Algorithms, the algorithm bible, three courses, and 200 LeetCode
problems solved. I still froze in interviews because I was memorizing, not
understanding.

Expora's visual debuggers let you step through algorithms one operation at a time —
watching the graph update, the queue fill, the dp table populate — with your own
code. It's the difference between reading about an algorithm and watching it think.

If you've ever felt like grinding isn't working, you're probably right.
The problem isn't your intelligence — it's the feedback loop you're practicing in.

Originally published at tryexpora.com/blog/why-leetcode-is-hard