Before you can traverse, search, or rebalance a tree, you need a precise vocabulary for its parts. A binary tree is built from nodes, and each node is a small, self-contained unit: a field holding the data (often called the key or value) and two reference fields pointing to a left child and a right child. When either reference is null, that side of the node is empty — and a node with two null references is a leaf. Everything else about tree structure follows from how these nodes are linked together.
From those links come the relationships and measurements you will use all semester. One node is designated the root (the only node with no parent); every other node has exactly one parent and up to two children. The depth of a node is the number of edges from the root down to it, the height of a node is the number of edges on the longest downward path to a leaf, and the height of the tree is the height of its root. Any node, taken together with everything beneath it, forms a subtree — which is why so many tree algorithms are naturally recursive. Nodes sharing the same depth form a level, and a tree is considered balanced when the left and right subtrees of every node have heights that differ by at most a small constant.
These ideas are not just terminology. Tree height directly determines how long a search or insertion takes, so the difference between a balanced tree and a degenerate, list-like tree is the difference between logarithmic and linear performance. As you watch the videos below, pay attention to three things: how height and depth are defined (some sources count edges, others count nodes, so note which convention is used), how a recursive height computation mirrors the subtree structure, and what makes the minimum and maximum possible heights of an n-node tree so far apart.
This video works through the classic problem of computing the height of a binary tree, framed as a coding exercise within a larger data structures course. Based on its title and description, it should walk through the recursive idea that a node's height depends on the heights of its left and right subtrees, then build that into code. Expect a concrete, step-by-step treatment rather than a purely theoretical one.
It directly targets the height subtopic and makes the recursive subtree decomposition visible, which is exactly the mental model you need for later traversal and balance work. As part of a sequenced DSA course series, it assumes the same node-with-two-pointers structure introduced in this topic.
A short, lecture-style treatment of the minimum and maximum height a binary tree can have for a given number of nodes, delivered with slides by a university instructor. It should establish the lower bound achieved by a full or complete tree and the upper bound reached by a degenerate chain of nodes. The emphasis is on reasoning about bounds rather than on writing code.
This is the conceptual bridge between tree anatomy and performance: it explains why balance matters by showing how far apart the best and worst possible heights are. The academic framing and slide-based presentation make it a good complement to the more code-focused videos.
Part of Geekific's tree series, this video addresses what it means for a binary tree to be balanced and how to compute the minimum depth of a tree, presented with Java solutions to the corresponding LeetCode problems. It should contrast depth measured to the nearest leaf with height measured to the farthest leaf, and show how a balance check compares left and right subtree heights at every node.
It covers the balance and depth subtopics together and clarifies the depth-versus-height distinction that students most often confuse. The short runtime and accompanying GitHub repository make it easy to pair the explanation with runnable code.
Together these videos build the structural vocabulary MO1 requires — nodes, root, parent and child links, leaves, subtrees, depth, and height — with each term grounded in a worked example rather than a definition list. Because every tree algorithm you will write later is recursive over subtrees, the height computation shown here is the same pattern you will reuse when tracing traversals (MO2) and implementing insert, search, and delete (MO3, MO5). Most importantly, the height-bounds and balance discussions set up MO4 directly: once you can see that an n-node tree may be as short as roughly log n or as tall as n, the gap between best-case and worst-case BST performance, and its dependence on insertion order, follows naturally.
These videos were chosen from YouTube on October 2, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.