9 Out of 10 Developers Skip This Data Structure — Then Bomb Their FAANG Interview

Hi everyone, I am Trends 24/7 and in this blog, I want to talk about the one data structure that separates developers who get offers from Google, Meta, and Amazon from developers who walk out of those interviews wondering what just happened.

It’s graphs. And most people either skip it entirely or spend 20 minutes on it and assume they’re fine.

They’re not fine.

The number that should make you nervous

A July 2025 analysis of over 100 FAANG interview reports found that graph problems appeared in 30% of coding rounds. Trees showed up in 25%. Dynamic programming in 20%. That means if you sit through four coding rounds at a top company, there’s a good chance at least one of them hands you a graph problem.

The irony is that graphs are probably the most skipped topic in interview prep. Arrays are comfortable. Linked lists are manageable. Graphs feel abstract and unfamiliar, so people put them off, and then don’t get back to them.

After reviewing thousands of mock interviews from interviewing.io (which has hosted over 100,000 sessions with engineers from top companies), one mistake shows up more than any other in graph rounds: candidates forget to track visited nodes. They write a BFS or DFS that works on tiny inputs, then it infinite loops the moment there’s a cycle. Every graph traversal needs a visited set. Every single one. The interviewer has seen this exact mistake forty times. You don’t want to be the forty-first.

What a graph actually is (and why it’s not as abstract as it sounds)

A graph is just nodes connected by edges. That’s the whole thing. The reason it feels hard is that it models relationships, and relationships are messier than sequences.

An array assumes your data has order. A tree assumes your data has a hierarchy. A graph assumes nothing. It just says: these things connect to these other things, with whatever rules you define.

That looseness is why graphs end up everywhere.

LinkedIn has over 1 billion users. Each one is a node. A connection is an edge. When “People You May Know” surfaces someone you worked with briefly at a job you’ve half-forgotten, that’s a breadth-first traversal walking two or three hops across your connection graph, scored and re-ranked in near real-time as the graph updates. The system processes millions of graph updates per second.

Google Maps is Dijkstra’s algorithm running on a weighted graph where intersections are nodes and roads are edges with weights representing travel time. The algorithm that finds your route was published by Edsger Dijkstra in 1956. Google wrapped it in a beautiful interface and serves it to billions of people, but the core is unchanged.

Facebook built Apache Giraph, an entire distributed graph processing system, to handle friend suggestions at the scale of billions of connections. The “People You May Know” feature runs on graph traversal, mutual friend counting, and Jaccard similarity across overlapping connection sets.

Netflix maps users, content, and viewing history as a graph and uses that graph for collaborative filtering recommendations. Your “Because you watched…” row is graph math.

None of these are obscure research applications. They’re the products.

The five patterns that cover almost everything

Graph interview problems look varied on the surface but they cluster into five patterns. Getting fluent with these five is what the preparation actually looks like.

DFS (Depth-First Search) goes deep before it goes wide. You follow one path all the way until it dead-ends, then backtrack. Use this when you need to explore all possible paths, detect cycles, or find strongly connected components. “Number of Islands” is the canonical DFS grid problem and a genuine FAANG warm-up question.

BFS (Breadth-First Search) explores level by level. It guarantees the shortest path in an unweighted graph, which is exactly why it’s the right tool for “minimum steps to reach X” problems. If the problem says “minimum” and the graph has no edge weights, reach for BFS before anything else.

Connected Components asks how many separate subgraphs exist. You run DFS or BFS, mark everything you can reach, increment a counter, and find the next unvisited node. “Number of Provinces” and “Number of Islands” are both connected component problems in different disguises.

Topological Sort only works on directed acyclic graphs (DAGs) and produces an ordering where every node appears before the nodes it points to. The classic real-world use is dependency resolution: if package A depends on package B and package C, you install B and C before A. In interviews, this shows up as course scheduling problems. “Can you finish all courses given these prerequisites?” is topological sort with cycle detection.

Dijkstra’s Algorithm handles weighted graphs where you need the shortest path by total edge cost rather than by number of hops. It uses a min-heap (priority queue) to always process the cheapest-to-reach node next. “Cheapest Flights Within K Stops” and “Network Delay Time” are the two LeetCode problems that show up most often in this category.

A real code example: the one that trips people up most

“Course Schedule” (LeetCode 207) is one of the most frequently asked graph problems at Amazon, Google, and Meta. The question: given a list of courses and their prerequisites, can you finish all courses?

This is cycle detection in a directed graph. If there’s a cycle in the prerequisite graph, you can never start, because every course in the cycle requires something in the same cycle to be finished first.

Here’s the DFS approach in Python:

def canFinish(numCourses, prerequisites):
    # Build adjacency list
    graph = {i: [] for i in range(numCourses)}
    for course, prereq in prerequisites:
        graph[course].append(prereq)

    # 0 = unvisited, 1 = in current path, 2 = fully processed
    state = [0] * numCourses

    def has_cycle(node):
        if state[node] == 1:  # Currently visiting = cycle found
            return True
        if state[node] == 2:  # Already processed = no cycle here
            return False

        state[node] = 1  # Mark as in current path
        for neighbor in graph[node]:
            if has_cycle(neighbor):
                return True
        state[node] = 2  # Mark as fully processed
        return False

    for course in range(numCourses):
        if has_cycle(course):
            return False
    return True

The three-state tracking (unvisited, in-path, done) is what most people get wrong. They use a simple visited boolean, which can’t distinguish between “I’ve fully processed this node and it’s safe” and “I’m currently visiting this node and found a cycle.” That distinction is the whole problem.

If you can implement this cleanly in under 15 minutes and explain the three states while you type, you’ve already passed the graph portion of most mid-level interviews.

The representation question interviewers actually care about

Before you write any traversal code, you need to build the graph. Interviewers watch how you do this.

An adjacency matrix uses a 2D array where matrix[i][j] = 1 means there's an edge from node i to node j. It's O(V²) space, which is fine for dense graphs but wasteful when most node pairs have no connection.

An adjacency list uses a dictionary or array where each node maps to a list of its neighbors. It’s O(V + E) space, which scales much better for sparse graphs (most real-world graphs are sparse). When in doubt, use an adjacency list. The interviewer wants to see you reach for the right tool, not the one you memorized.

For grid problems (like “Number of Islands”), the graph is implicit. Each cell is a node, and its neighbors are the four adjacent cells. You don’t build a separate data structure; you just traverse the grid directly, which is a cleaner approach and shows you recognize the structure.

Why this matters outside interviews too

I want to be honest about something: graph problems are hard partly because they’re genuinely harder to think about, not just harder to memorize. You have to hold the structure in your head while tracking your position in it.

But the reason companies keep asking these questions is that graphs show up constantly in real work. Dependency resolution in package managers, detecting circular imports in Python, modeling network topology for debugging, building recommendation systems, tracing request flows in distributed systems — all of it uses graphs. An engineer who can’t reason about graph structure is going to hit a wall in a lot of real work, not just in interviews.

The “Course Schedule” problem isn’t there because someone at Google thought cycle detection was a fun puzzle. It’s there because real systems deal with dependency cycles all the time and detecting them quickly matters.

Where to actually start

If you’ve been skipping graphs, here’s a reasonable order based on what shows up most often:

Start with “Number of Islands” (grid BFS/DFS, connected components). Then “Course Schedule” (cycle detection, topological sort). Then “Word Ladder” (BFS, shortest path in an unweighted graph). Then “Network Delay Time” (Dijkstra, weighted shortest path). Then “Cheapest Flights Within K Stops” (Dijkstra with a constraint on path length).

That’s five problems. They cover the five core patterns. Once you can solve all five cleanly and explain your approach, you’re prepared for the graph round at most top companies. Not because you’ve memorized answers, but because you’ve seen what each pattern looks like and can recognize it when it shows up in a different costume.

Graphs in 30% of rounds. Most candidates showing up with zero preparation on this topic. That gap is the opportunity.