Lesson 18 of 30
Binary search trees as a family tree with one strict rule added — smaller values go left, bigger values go right — and why that rule is what makes searching fast.
11 min read
Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.
This topic is about judgment and practical tradeoffs more than a single right answer — a mock interview is the better way to test yourself on it.
Be interviewed on this →Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.
Sign up freeWhat interviewers actually ask about this, and what a strong answer has to cover.
A strong answer covers
Likely follow-ups
You now know two things separately: the guess-the-number game, where guessing the middle cuts your remaining options in half each time, and the family tree shape, where one item branches down into children. A binary search tree puts those two ideas together.
Picture the same family-tree shape from the last lesson, but with a strict house rule at every single branch: anything smaller than this node goes in the left branch, anything bigger goes in the right branch. Every node, all the way down, follows that same rule — not just the root.
Here's why that rule matters. If you're searching for a value and you're standing at a node, the rule tells you exactly which way to go, immediately. Looking for something smaller than the current node? Go left — there's no reason to ever check the right side, because the rule guarantees nothing you want lives there. That's the guess-the-number halving trick again, except now it's built into the shape of the tree itself instead of you doing the halving with your own math.
Also worth naming directly, because it trips people up: "binary" here means "at most 2 children per node" — not "made of 1s and 0s." Every node has room for a left child and a right child, and that's the maximum. A regular tree, from the last lesson, could have any number of children; a binary tree is the specific, stricter version with a cap of 2.
// Each node: a value, a left child (smaller), and a right child (bigger).
function makeNode(value, left = null, right = null) {
return { value, left, right };
}
// A small binary search tree, built by hand to show the rule in action.
// 8
// / \
// 3 10
// \
// 6
const tree = makeNode(8,
makeNode(3, null, makeNode(6)),
makeNode(10)
);
function search(node, target) {
if (node === null) return false; // fell off the tree — not found
if (node.value === target) return true; // found it
// The rule: smaller goes left, bigger goes right.
if (target < node.value) {
return search(node.left, target);
} else {
return search(node.right, target);
}
}
console.log(search(tree, 6)); // true — 8 -> 3 -> 6
console.log(search(tree, 5)); // false — 8 -> 3 -> (nothing there)
Trace the search for 6: start at 8. 6 < 8, go left to 3. 6 > 3, go right to 6. Found it — 2 steps, without ever glancing at the 10 branch, because the rule already ruled it out.
This lesson is where two earlier ideas in this track meet. The halving instinct from the guess-the-number game is still doing the work — every step down a binary search tree throws away one whole branch, the same way every guess in that game threw away half the numbers. What changed is the container: instead of guessing the middle of a sorted list yourself, the tree shape from the family-tree lesson encodes that middle-guessing rule directly into its structure, so following the rule at each node does the halving for you.