Skip to content
Forge Learn/Tree Traversal

Pre-order, In-order, Post-order & Level-order

6 min read

You'll learn to

  • -Describe what each of the four traversals visits, and in what order
  • -Explain why in-order traversal of a BST always yields sorted output
  • -Explain why level-order traversal needs an explicit queue instead of recursion

A traversal is simply a rule for the order in which you visit every node in a tree exactly once. That sounds like a small detail, but different traversals unlock different guarantees and different use cases - the "right" traversal depends entirely on what you are trying to do with the tree. Three of the four traversals below are variations on depth-first search (go deep before going wide), and differ only in when they record the current node relative to recursing into its children. The fourth, level-order, is breadth-first instead, and needs a fundamentally different tool to implement.

Pre-order: Node, Then Children

Pre-order records the current node before recursing into either child. This is the traversal to reach for when you want to reconstruct or clone a tree from scratch, since a parent is always emitted before its children - reading the output back in the same order naturally rebuilds the same shape.

Pre-order - node, then left subtree, then right subtree

In-order: Left, Node, Right

In-order visits the entire left subtree, then the current node, then the entire right subtree. Applied to a BST specifically, this produces every value in fully sorted order - a direct consequence of the invariant from the previous module: everything to the left is smaller, everything to the right is larger, so visiting left-node-right at every level threads the values together in ascending order.

In-order on a BST - guaranteed sorted output

Post-order: Children, Then Node

Post-order visits both children fully before recording the current node. This ordering is what makes it the safe choice for deleting or freeing an entire tree: by the time a node is processed, both of its children have already been fully handled, so there is never a dangling reference to a child you have not dealt with yet. The same idea shows up in evaluating expression trees, where an operator node needs both of its operand subtrees fully evaluated first.

Post-order - both children before the node itself

Level-order: Breadth-First With a Queue

The first three traversals are all depth-first - they follow one branch all the way down before backtracking, which is exactly the shape recursion (and its implicit call stack) naturally provides. Level-order is different: it visits every node at depth 0, then every node at depth 1, then depth 2, and so on - breadth, not depth, first. Recursion has no natural way to pause a branch and jump to a sibling at the same level, so level-order needs an explicit FIFO queue instead: enqueue the root, then repeatedly dequeue a node, record it, and enqueue its children (in left-to-right order) for later.

Level-order (BFS) - an explicit queue instead of recursion

This queue-driven, level-by-level pattern is not unique to trees - it is exactly the same shape you will use for breadth-first search on general graphs a few modules from now, just with a `visited` set added to handle cycles that trees, by definition, don't have.

Check Yourself1 / 3

Why does an in-order traversal of a binary search tree always produce values in sorted order?

Ready to Build This?

Level 64: Tree Traversal Toolkit asks you to implement preorder, inorder, postorder (recursive) and level_order (BFS with a queue) over a given TreeNode class - exactly the four functions above.

ScaleDojo Logo
Initializing ScaleDojo