Trees & Graphs

Trees and graphs sit in the middle of MongoDB's coding loop rather than at the front, but they earn real prep time because every shape here has an obvious home in a document database. A BSON document is a tree of fields. An index is a search tree the query planner walks. References between documents form a graph, and MongoDB even ships an aggregation stage that traverses one. So when an interviewer reaches for a tree or graph problem, it usually carries a whiff of that world, and the framing below leans into it.

The good news is that almost everything in this family runs off one skeleton: a depth-first or breadth-first walk that remembers where it has already been. Trees let you drop the visited set, because there are no cycles and every node has one parent. Graphs put it back, because references can point in circles and two paths can reach the same node. Get that one distinction reflexive and most of the cluster collapses into the same loop with different bookkeeping.

The MongoDB angle

A BSON document is a tree, which makes tree traversal the most native skill on this page. Every document is a root object whose fields hold scalars, arrays, or nested sub-documents, and a dot-notation path like address.city is just a walk from the root down to a leaf. When the database transforms, validates, or projects a document, it is running a depth-first pass over that tree. Interviewers who build this for a living tend to reward a candidate who traverses cleanly, names the empty and single-node cases before writing the loop, and keeps recursion depth in view. A pathologically nested document is a real input their engine has to survive without blowing the stack.