Remove Nth Node from End of List in DSA Rust - Time & Space Complexity

Time Complexity: Remove Nth Node from End of List

O(n)

Understanding Time Complexity

We want to understand how the time to remove the nth node from the end of a list changes as the list grows.

How does the number of steps grow when the list gets longer?

Scenario Under Consideration

Analyze the time complexity of the following code snippet.

fn remove_nth_from_end(head: Option>, n: i32) -> Option> {
    let mut dummy = Box::new(ListNode { val: 0, next: head });
    let mut second = &mut dummy;
    let mut first = &*second;

    for _ in 0..n {
        first = first.next.as_ref().unwrap();
    }
    first = first.next.as_ref().unwrap();

    while first.next.is_some() {
        first = first.next.as_ref().unwrap();
        second = second.next.as_mut().unwrap();
    }

    let next = second.next.as_mut().unwrap().next.take();
    second.next = next;

    dummy.next
}
    

This code removes the nth node from the end of a singly linked list by using two pointers moving through the list.

Identify Repeating Operations

• Primary operation: Two loops that move pointers through the list.
• How many times: The first loop moves n steps; the second loop moves through the rest of the list until the end.

How Execution Grows With Input

As the list size grows, the total steps grow roughly in a straight line with the list length.

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

Pattern observation: The number of steps grows directly with the list size, so doubling the list roughly doubles the work.

Final Time Complexity

Time Complexity: O(n)

This means the time to remove the nth node from the end grows linearly with the list size.

Common Mistake

[X] Wrong: "The operation takes constant time because we only remove one node."

[OK] Correct: Even though only one node is removed, we must first find it by walking through the list, which takes time proportional to the list length.

Interview Connect

Understanding this linear time complexity helps you explain why two-pointer techniques are efficient for linked list problems and shows your grasp of pointer traversal skills.

Self-Check

"What if we used a doubly linked list with a tail pointer? How would the time complexity change?"

Practice

1. What does the problem Remove Nth Node from End of List ask you to do?

easy

A. Reverse the linked list up to the nth node

B. Add a new node at the nth position from the start

C. Delete the node that is the nth from the end in a linked list

D. Find the value of the nth node from the start

Solution

1. Step 1: Understand the problem statement

   The problem requires removing the node that is nth from the end in a singly linked list.

2. Step 2: Clarify the operation

   We do not add or reverse nodes; we specifically delete the nth node counting from the list's end.

3. Final Answer:

   Delete the node that is the nth from the end in a linked list -> Option C

4. Quick Check:

   Remove nth from end = Delete nth from end [OK]

Hint: Focus on 'remove nth from end' means delete that node [OK]

Common Mistakes:

• Confusing nth from end with nth from start
• Thinking the problem is about reversing the list
• Assuming insertion instead of deletion

2. Which Rust code snippet correctly declares a singly linked list node struct for this problem?

easy

A. struct ListNode { val: i32, next: &ListNode }

B. struct ListNode { val: i32, next: Option }

C. struct ListNode { val: i32, next: Box<ListNode> }

D. struct ListNode { val: i32, next: Option<&ListNode> }

Solution

1. Step 1: Recall Rust ownership for linked lists

   Rust uses Option to allow nullable next pointers with ownership.

2. Step 2: Check each option

   struct ListNode { val: i32, next: Option } uses Option which is correct. Options A and D use references without ownership, which is unsafe. struct ListNode { val: i32, next: Box<ListNode> } lacks Option, so no null end.

3. Final Answer:

   struct ListNode { val: i32, next: Option } -> Option B

4. Quick Check:

   Rust linked list node = Option [OK]

Hint: Use Option for nullable owned pointers in Rust [OK]

Common Mistakes:

• Using references (&) instead of Box for next
• Omitting Option causing no null end
• Forgetting ownership rules in Rust

3. Given the Rust code below, what is the linked list output after removing the 2nd node from the end?

let mut list = Some(Box::new(ListNode { val: 1, next: Some(Box::new(ListNode { val: 2, next: Some(Box::new(ListNode { val: 3, next: None })) })) }));
// Remove 2nd from end
let result = remove_nth_from_end(list, 2);
// Print list values

medium

A. 1 -> 2 -> 3 -> null

B. 1 -> 2 -> null

C. 2 -> 3 -> null

D. 1 -> 3 -> null

Solution

1. Step 1: Identify the list and node to remove

   The list is 1 -> 2 -> 3. Removing 2nd from end means removing node with value 2.

2. Step 2: Remove the node and update links

   After removal, list becomes 1 -> 3 -> null.

3. Final Answer:

   1 -> 3 -> null -> Option D

4. Quick Check:

   Remove 2nd from end removes '2' [OK]

Hint: Count from end, remove that node, link neighbors [OK]

Common Mistakes:

• Removing the wrong node counting from start
• Not updating next pointers correctly
• Confusing 2nd from end with 2nd from start

4. The following Rust function aims to remove the nth node from the end but has a bug. What is the bug?

fn remove_nth_from_end(head: Option, n: i32) -> Option {
    let mut dummy = Box::new(ListNode { val: 0, next: head });
    let mut first = &dummy;
    let mut second = &mut dummy;
    for _ in 0..n {
        first = first.next.as_ref().unwrap();
    }
    while first.next.is_some() {
        first = first.next.as_ref().unwrap();
        second = second.next.as_mut().unwrap();
    }
    second.next = second.next.as_mut().unwrap().next.take();
    dummy.next
}

medium

A. Using unwrap() without checking may panic if list is short

B. second is immutable, cannot modify next pointer

C. first is an immutable reference, cannot advance correctly

D. dummy.next is returned before modification

Solution

1. Step 1: Analyze unwrap usage

   The code uses unwrap() on next without checking if next exists, which can panic if n is larger than list length.

2. Step 2: Confirm other references are valid

   first is immutable reference but used only for reading, second is mutable for modification, dummy.next returned after modification.

3. Final Answer:

   Using unwrap() without checking may panic if list is short -> Option A

4. Quick Check:

   unwrap() without safety check causes panic [OK]

Hint: Check unwrap() calls for possible panics [OK]

Common Mistakes:

• Confusing mutable and immutable references
• Ignoring unwrap panic risks
• Assuming dummy.next is returned too early

5. You want to remove the nth node from the end of a linked list in Rust. Which approach correctly handles the edge case when the node to remove is the head node?

hard

A. Use a dummy node before head and adjust dummy.next after removal

B. Directly remove head without dummy node by shifting head pointer

C. Traverse twice: first to count length, second to remove node without dummy

D. Convert list to vector, remove element, then rebuild list

Solution

1. Step 1: Understand the edge case

   If the node to remove is the head, removing it directly is tricky because head pointer must change.

2. Step 2: Use dummy node technique

   Adding a dummy node before head simplifies removal by always having a previous node to update, including when head is removed.

3. Final Answer:

   Use a dummy node before head and adjust dummy.next after removal -> Option A

4. Quick Check:

   Dummy node handles head removal edge case [OK]

Hint: Add dummy node to simplify head removal [OK]

Common Mistakes:

• Not handling head removal separately
• Forgetting to update head pointer
• Using inefficient vector conversion