Pointer Tracing

One Arrow Holds the Rest

You already know each node holds a value and a next reference. Here is the part that bites in interviews.

Often, the only way to reach the rest of the list is through that one next reference.

If you overwrite next before saving where it pointed, every node after it can no longer be reached. Half your list can vanish in one line.

Notice that nodes 2 and 3 still exist, but once node 1's arrow points to null, no arrow leads to them anymore.

Pointer tracing is how you catch this before it happens.

How to Trace on Paper

Pointer tracing means drawing the list and updating the drawing as your code runs.

Draw every node as a box with an arrow for next. Label the variables that refer to nodes, such as head, prev, curr, and next.

Then redraw the picture after each assignment.

One line of code, one new picture. That is the whole habit.

The Question Before Every Change

Before you change any next arrow, stop and ask one question.

Will I still be able to reach the node it points to now?

If yes, go ahead. If not, save that node in a temporary variable first, then change the arrow.

This habit prevents the most common linked list bug: a next link overwritten before it is saved.

Spot the Bug in Reversal

Imagine an internship interview. You are reversing 1 -> 2 -> 3 -> null, starting with prev = null and curr = node 1.

Buggy order: you write curr.next = prev first. Node 1 now points to null.

Now nothing points to node 2. Nodes 2 and 3 are lost.

Correct order: save next = node 2, set node 1's next to null, then set prev = node 1 and curr = node 2.

Trace the Whole Reversal

Repeat the correct steps and redraw after each round. Every round saves next, flips one arrow, then moves prev and curr forward.

Round 2 saves node 3, points node 2 at node 1, and moves curr to node 3.

Round 3 saves null, points node 3 at node 2, and curr becomes null. The loop stops.

Result: 3 -> 2 -> 1 -> null, with no nodes lost.

Trace the Edge Cases Too

Check edge cases with the same drawings. Three deserve a picture every time.

An empty list. A single node. And the last node, where next is null.

For each one, redraw after every assignment and ask the same question: can I still reach every node I need?

Interviewers often test these cases first, so trace them before you say you are done.

Why Drawing Pays Off

In an interview, talking through your drawings shows the interviewer how you reason.

Tracing also makes later patterns easier to get right: two pointers, reversal, merging, cycle detection, and dummy nodes.

Each of them changes pointers, so each can lose nodes the same way.

Your takeaway: draw first, ask the reachability question, save before you overwrite, then code.

A list is A -> B -> C -> null, and A.next is the only reference to node B. You run A.next = null without saving B anywhere. Can your code still reach nodes B and C?

• Yes
• No

Answer: No

No. A.next was the only path to B, and B.next is the only path to C. Once A.next is overwritten, nothing points to B, so B and C are cut off and lost. Saving B in a temporary variable first would have kept them reachable.

Complete the flowchart for safely modifying linked list pointers.

Answer: Save in temp, Redraw picture

If a node will not be reachable after redirecting an arrow, save it in a temporary variable first. After updating the pointer, redraw the diagram to reflect the new state.

Tap the line where nodes are cut off and lost because a next pointer is overwritten before being saved.

Answer: curr.next = prev

Setting curr.next = prev before saving curr.next in a temporary variable severs the connection to the rest of the list, permanently losing access to node 2 and beyond.