Cracking The Coding Interview Together – Problem 2.2: Kth to last

Hope you’re doing well. Today’s problem is one of those deceptively simple ones that shows up everywhere — interviews, code reviews, and even real production discussions when people talk about streaming data or memory constraints. On the surface, it feels straightforward. But like many linked list problems, the devil is hidden in how you approach it and what assumptions you make.

So let’s slow down, take this step by step, and solve it the way an interviewer would expect you to.

We always follow the format as follows

1. Understand the problem statement together
2. Ask any questions, that you would like to ask the interviewer
3. I would urge you to take your time here and try to come up with your own solution before going forward
4. Think how you would go about solving the problem(you would be talking out loud in front of the actual interviewer)
5. Write code and understand how it works and explain it to your interviewer

Problem statement

Implement an algorithm to find the kth to last element of a singly linked list.

Analyse the problem statement together

In simpler words:
Given a singly linked list and a number k, return the node that is k positions from the end of the list.

For example:

List: 1 → 2 → 3 → 4 → 5
k = 2

Output should be:

4

Because 4 is the 2nd element from the end (5 is last, 4 is second to last).

Before touching any code, let’s make sure we’re not fooling ourselves into solving the wrong problem.

Key observations:

• This is a singly linked list (you can only move forward).
• You are asked for the kth to last element, not the kth index.
• You are not given the length of the list upfront.
• There’s no mention of modifying the list — so assume read-only traversal.

Already, this should trigger a thought:

“If I can’t go backwards, how do I know where the end is until I reach it?”

That question is the entire problem.

Questions for the interviewer

Never skip this step. Interviewers expect you to clarify assumptions.

Here are the questions I would ask:

1. Is k zero-based or one-based?(Most interviewers assume 1-based, but never guess.)
   • Does k = 1 mean the last element?
   • Or does k = 0 mean the last element?
2. What if k is larger than the length of the list?
   • Should we return null?
   • Throw an exception?
3. Can the list be empty?
   • If yes, what should we return?
4. Are we allowed to use extra memory?
   • HashMap?
   • Stack?
   • Recursion?

These questions don’t make you look weak. They make you look careful.

For the rest of this discussion, we’ll assume:

• k is 1-based
• If k is invalid, return null
• The list can be empty
• We’ll explore both buffered and non-buffered solutions

Think about the Solution

Before scrolling further, take 2–3 minutes and think:

• How would you solve this?
• What’s the most obvious approach?
• What breaks when constraints change?

This habit matters far more than memorizing solutions.

First Instinct: Count the Length

My first thought is simple:

1. Traverse the list and count the total number of nodes.
2. Compute position = length - k.
3. Traverse again to that position.

This works. It’s easy. It’s readable.

But it has a cost:

• Requires two passes over the list.

Is that bad?
Not necessarily. But interviewers love asking:

“Can you do it in one pass?”

So let’s keep this as a baseline solution, but not our final answer.

Can We Do Better? (One-Pass Solution)

Now comes the interesting part.

If I can’t know where the end is until I reach it, what if I delay my answer instead of calculating it upfront?

This thought leads us to the two-pointer technique.

The Two-Pointer Intuition

Imagine this:

• You have two pointers, fast and slow.
• You move fast ahead by k nodes.
• Then you move both pointers together, one step at a time.
• When fast reaches the end, slow will be exactly at the kth to last node.

Why does this work?

Because the distance between fast and slow is always k.

This is one of those elegant tricks that interviewers love because it shows:

• You understand pointer movement
• You can reason about relative positions
• You can optimize without overcomplicating

Write code and explain

Let’s start with the simpler and more practical solution.

Solution 1: Two Pass Solution

How It Works

1. Traverse the list once to get the length.
2. If k > length, return null.
3. Traverse again until you reach length - k.
4. Return that node.

Java code

public static Node kthToLast(Node head, int k) {
    if (head == null || k <= 0) {
        return null;
    }

    int length = 0;
    Node current = head;

    while (current != null) {
        length++;
        current = current.next;
    }

    if (k > length) {
        return null;
    }

    current = head;
    for (int i = 0; i < length - k; i++) {
        current = current.next;
    }

    return current;
}

Solution 2: One Pass Solution

Java code

public static Node kthToLast(Node head, int k) {
    if (head == null || k <= 0) {
        return null;
    }

    Node fast = head;
    Node slow = head;

    // Move fast pointer k steps ahead
    for (int i = 0; i < k; i++) {
        if (fast == null) {
            return null; // k is larger than list length
        }
        fast = fast.next;
    }

    // Move both pointers until fast reaches the end
    while (fast != null) {
        slow = slow.next;
        fast = fast.next;
    }

    return slow;
}

Time & Space Complexity (and why this matters)

Let’s be very clear here, because interviewers love this comparison.

Two Pass Solution

• Time Complexity: O(n)
• Space Complexity: O(1)

One Pass Solution

• Time Complexity: O(n)
• Space Complexity: O(1)

Final Thoughts

This problem is a great example of why linked lists are tricky — not because they’re hard, but because they limit your movement. You can’t jump, you can’t index, you can only walk forward and remember what you’ve seen.

The two-pointer technique is something you’ll reuse again and again:

• Detecting cycles
• Finding middle elements
• Removing nth nodes from the end

If you truly understand this problem, you’ve leveled up your linked list intuition.

If you’re enjoying this series, let me know. And if there’s a problem you want us to crack together next, drop it in the comments.

Until then — keep practicing, and enjoy the journey.