TL;DR
- Graphs are the right model whenever relationships are many-to-many instead of parent/child.
- I practice graphs through traversal, cycle detection, connected components, and dependency ordering.
- For senior frontend developers, this translates well to route dependencies, build graphs, module graphs, and workflow engines.
Context
Even if a product UI never renders a graph directly, graph thinking shows up in state machines, dependency resolution, permission propagation, workflow steps, and bundler/module relationships.
The Approach
Practice these 10 medium-level questions:
- Number of Connected Components — traversal plus visited set.
- Clone Graph — preserve identity and edges safely.
- Course Schedule — cycle detection in prerequisites.
- Topological Sort — order work given dependencies.
- Shortest Path in Unweighted Graph — BFS distance layering.
- Rotting Oranges / Multi-Source BFS — simultaneous frontier expansion.
- Count Islands — graph traversal over a grid.
- Pacific Atlantic Water Flow — reverse reachability from borders.
- Word Ladder — graph search over generated neighbors.
- Evaluate Division — weighted graph traversal over equations.
Try it in the browser
Browser Practice
Graph practice: connected components
Implement solve(graph) where graph is an adjacency list object like { A: ['B'], B: ['A'], C: [] } and return the number of connected components.
Sample Tests
2 checks
Function name:
solveBest for JavaScript / TypeScript / JSON practice snippets.Monospace editorRuns in browser sandbox
Trade-offs
- DFS is concise, but BFS is often better when shortest path or wavefront reasoning matters.
- Graph problems can look intimidating, but most of them reduce to “visit everything once, but with the right bookkeeping.”
References
- Related: Coding Practice: Trees
- Related: Coding Practice: Searching