Left Side View of Binary Tree in DSA Rust - Time & Space Complexity

Time Complexity: Left Side View of Binary Tree

O(n)

Understanding Time Complexity

We want to understand how the time needed to find the left side view of a binary tree changes as the tree grows.

How does the number of nodes affect the work done to see the left side?

Scenario Under Consideration

Analyze the time complexity of the following code snippet.

fn left_side_view(root: &Option>) -> Vec {
    let mut result = Vec::new();
    let mut queue = std::collections::VecDeque::new();
    if let Some(node) = root {
        queue.push_back(node.as_ref());
    }
    while !queue.is_empty() {
        let level_size = queue.len();
        for i in 0..level_size {
            let node = queue.pop_front().unwrap();
            if i == 0 {
                result.push(node.val);
            }
            if let Some(left) = &node.left {
                queue.push_back(left.as_ref());
            }
            if let Some(right) = &node.right {
                queue.push_back(right.as_ref());
            }
        }
    }
    result
}
    

This code collects the leftmost node value at each level of the binary tree using a breadth-first search.

Identify Repeating Operations

Identify the loops, recursion, array traversals that repeat.

• Primary operation: Visiting each node once in a loop.
• How many times: Exactly once per node, as each node is added and removed from the queue once.

How Execution Grows With Input

As the number of nodes grows, the code visits each node once, so the work grows directly with the number of nodes.

Input Size (n)	Approx. Operations
10	About 10 visits
100	About 100 visits
1000	About 1000 visits

Pattern observation: The work grows linearly with the number of nodes.

Final Time Complexity

Time Complexity: O(n)

This means the time to find the left side view grows directly with the number of nodes in the tree.

Common Mistake

[X] Wrong: "The algorithm only looks at the left children, so it runs faster than visiting all nodes."

[OK] Correct: The code visits every node because it must check both left and right children to find the leftmost node at each level, so it still processes all nodes.

Interview Connect

Understanding this linear time complexity helps you explain how breadth-first search explores trees level by level, a common pattern in many problems.

Self-Check

"What if we used depth-first search instead of breadth-first search? How would the time complexity change?"

Practice

1. What does the Left Side View of a binary tree represent?

easy

A. All leaf nodes of the tree

B. Nodes visible when the tree is viewed from the right side

C. Nodes visible when the tree is viewed from the left side

D. Nodes at the deepest level of the tree

Solution

1. Step 1: Understand the view perspective

   The left side view shows nodes visible when looking at the tree from the left side.

2. Step 2: Identify visible nodes

   Only the first node at each level from the left is visible in this view.

3. Final Answer:

   Nodes visible when the tree is viewed from the left side -> Option C

4. Quick Check:

   Left side view = nodes seen from left [OK]

Hint: Think of standing on the left side and looking at the tree [OK]

Common Mistakes:

• Confusing left side view with right side view
• Including all leaf nodes instead of first nodes per level
• Thinking it shows deepest nodes only

2. Which Rust code snippet correctly declares a binary tree node struct for left side view traversal?

easy

A. struct TreeNode { val: i32, left: TreeNode, right: TreeNode }

B. struct TreeNode { val: i32, left: Box<TreeNode>, right: Box<TreeNode> }

C. struct TreeNode { val: i32, left: &TreeNode, right: &TreeNode }

D. struct TreeNode { val: i32, left: Option, right: Option }

Solution

1. Step 1: Check ownership and optional children

   Rust binary trees use Option for nullable child nodes.

2. Step 2: Validate correct syntax

   Option allows for null or Some(child), which is correct for left and right.

3. Final Answer:

   struct TreeNode { val: i32, left: Option, right: Option } -> Option D

4. Quick Check:

   Use Option for nullable children [OK]

Hint: Use Option for child nodes in Rust [OK]

Common Mistakes:

• Using direct TreeNode type for children (causes infinite size)
• Using references without lifetimes
• Omitting Option for nullable children

3. What is the output of the left side view function for this tree?

    1
   / \
  2   3
   \   \
    5   4

Assuming the function returns a vector of node values visible from the left side.

medium

A. [1, 3, 4]

B. [1, 2, 5]

C. [1, 2, 4]

D. [1, 5, 4]

Solution

1. Step 1: Identify nodes visible from left at each level

   Level 0: 1, Level 1: 2 (left child), Level 2: 5 (right child of 2)

2. Step 2: Collect visible nodes in order

   Left side view nodes are [1, 2, 5]

3. Final Answer:

   [1, 2, 5] -> Option B

4. Quick Check:

   Left side nodes = [1, 2, 5] [OK]

Hint: Pick first node at each level from left [OK]

Common Mistakes:

• Choosing right child nodes instead of left
• Including nodes not visible from left
• Mixing order of nodes

4. Given this Rust function snippet for left side view, what is the bug?

fn left_side_view(root: Option) -> Vec<i32> {
    let mut result = vec![];
    let mut queue = vec![root.unwrap()];
    while !queue.is_empty() {
        let level_size = queue.len();
        for i in 0..level_size {
            let node = queue.remove(0);
            if i == 0 {
                result.push(node.val);
            }
            if let Some(left) = node.left {
                queue.push(left);
            }
            if let Some(right) = node.right {
                queue.push(right);
            }
        }
    }
    result
}

medium

A. Calling unwrap() on root without checking if it is null

B. Using remove(0) on vector causes runtime error

C. Pushing right child before left child breaks left view order

D. Not returning the result vector at the end

Solution

1. Step 1: Check root unwrap usage

   Calling unwrap() on root without checking if it is null can cause panic if tree is empty.

2. Step 2: Confirm other parts are correct

   remove(0) works but is inefficient; order of pushing left then right is correct; result is returned.

3. Final Answer:

   Calling unwrap() on root without checking if it is null -> Option A

4. Quick Check:

   unwrap() on null causes panic [OK]

Hint: Check unwrap() calls for null before use [OK]

Common Mistakes:

• Ignoring unwrap panic possibility
• Thinking remove(0) causes error (just slow)
• Confusing child push order
• Missing return statement

5. You want to modify the left side view function to return the leftmost node values only for levels where the node value is even. Which approach is correct?

hard

A. Add a check inside the level loop: if i == 0 and node.val % 2 == 0, then push node.val to result

B. Push node.val for all nodes during traversal, then filter even values from result after traversal

C. Push node.val only if node.val is even, ignoring position in level

D. Push node.val if it is even and it is the rightmost node at the level

Solution

1. Step 1: Understand requirement for leftmost even nodes

   We want only the first node at each level if its value is even.

2. Step 2: Apply condition during traversal

   Check if i == 0 (leftmost) and node.val % 2 == 0 before pushing to result.

3. Final Answer:

   Add a check inside the level loop: if i == 0 and node.val % 2 == 0, then push node.val to result -> Option A

4. Quick Check:

   Filter leftmost nodes by even value during traversal [OK]

Hint: Check leftmost and even condition together inside loop [OK]

Common Mistakes:

• Filtering after traversal loses position info
• Ignoring leftmost position and filtering only by value
• Checking rightmost node instead of leftmost