Trees & Graphs

A Notion page is a tree of blocks before it is anything else. A paragraph, a heading, a to-do item, an image, a database row, and a subpage are all the same primitive. Each carries a small set of properties, an ordered list of child blocks, and a pointer back to its parent. That block tree is what the client walks to render a page top to bottom, and it is the model the coding round reaches for again and again. When a prompt talks about pages, blocks, nesting, or dependent automations, it is almost always asking you to traverse a tree or a graph and combine something as you walk.

The rounds run on CoderPad, live and executable, and they often open with an empty file. There is no node class waiting for you, no adjacency list, no parser to turn the input into a structure. You define the block, you build the test input, then you solve. The bar sits at a solid medium. The set underneath is standard once you see past the framing. Depth-first and breadth-first traversal, each iterative and recursive, plus the two graph workhorses of reachability and dependency ordering. What makes it Notion is the wrapper, a block tree in place of a generic n-ary tree and a graph of formula references in place of an anonymous set of edges.

The Notion angle

Model the block before you touch the algorithm. When the editor is blank, start with the scaffold. That's a block with an id, a parent pointer and an ordered list of children, or a defaultdict(list) keyed by parent id for the reconstruction. Say why as you build. A block holds any number of children, so this is n-ary and never binary. A page is loaded by walking the ordered content downward, while the parent pointer exists mainly so permissions can flow down the tree. A graph of references needs a visited set because a formula can point back through a chain and you must not loop forever.