Cracking The Coding Interview Together – Problem 2.3: Delete Middle Node

I hope you’re doing well and finding time to practice a little bit every day. Today’s problem looks deceptively simple on paper, but it hides a very important lesson about constraints, assumptions, and thinking within boundaries — exactly the kind of thing interviewers love to test.

In this session of Cracking the Coding Interview — Together, we’ll work through Delete Middle Node, a classic linked list problem that forces you to stop relying on “normal” linked list operations and really think.

As always, we’ll follow the same structure that you would use in a real interview.

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 delete a node in the middle (i.e., any node but the first and last node, not necessarily the exact middle) of a singly linked list, given only access to that node.

Analyse the problem statement together

Example:

Input:
The node c from the linked list
a → b → c → d → e → f

Result:
Nothing is returned, but the new linked list looks like:
a → b → d → e → f

At first glance, this sounds straightforward. We’ve all deleted nodes from linked lists before. But pause for a second — there’s a very important constraint hidden in plain sight:

👉 You are given only access to the node that needs to be deleted.

You are not given:

• The head of the linked list
• The previous node
• The ability to traverse from the beginning

That single constraint completely changes how we approach the problem.

Questions for the interviewer

Before jumping into solutions, this is the moment where you speak up. Interviews are not exams; they are conversations. Clarifying assumptions is a strength, not a weakness.

Here are the questions I would ask:

1. Can the given node ever be the first or last node?
2. Is the linked list singly linked or doubly linked?
3. Are node values unique, or does it not matter?
4. Should the function return anything, or just modify the list?
5. Can the list contain only one or two nodes?

And based on the problem statement, the interviewer would likely answer:

• The node will never be the first or last node
• The list is singly linked
• You only need to modify the list, no return value
• Node values don’t matter for the solution

Good. Now we know exactly what we’re dealing with.

Think about the Solution

Before reading further, stop here for a minute.

If you had only a pointer to node c, and no way to go backward, how would you delete it?

This is the point in the interview where silence is okay. Thinking out loud is encouraged. The interviewer wants to see how you reason, not how fast you write code.First Instinct: Count the Length

Let’s reason through this together.

In a normal linked list deletion, we do something like this:

prev.next = current.next

But here’s the catch:
👉 We don’t have prev.

We only have access to the current node — the one that needs to be deleted.

So how can we remove c if we cannot change b.next?

At this point, many people get stuck. But the trick is to stop thinking about deleting the node itself and instead think about removing its value from the list.

What if, instead of deleting c, we:

1. Copy the data from the next node (d) into c
2. Skip over the next node

Effectively:

• c becomes d
• d is removed from the list

Let’s visualize this.

Step-by-Step Example

Original list:

a → b → c → d → e → f

We are given access to node c.

1. Copy data from d into c
2. Set c.next to d.next

After step 1:

a → b → d → d → e → f

After step 2:

a → b → d → e → f

Notice something important:

• We never actually “deleted” c
• We overwrote it
• From the outside, the list looks exactly as required

This is the key insight the problem is testing.

Brute Force Thoughts (Why They Don’t Work)

It’s also useful to explain why obvious approaches fail, because interviewers care about that.

Brute Force Idea

Traverse from the head, find the previous node, and delete normally.

Why It Fails

• You don’t have access to the head
• The problem explicitly forbids it

Explaining this shows that you understand the constraints instead of blindly coding.

Write code and explain

Now that we understand the idea, the code itself becomes surprisingly small.

Java code

class ListNode {
    int data;
    ListNode next;

    ListNode(int data) {
        this.data = data;
        this.next = null;
    }
}

public class DeleteMiddleNode {

    public static void deleteNode(ListNode node) {
        // Edge case protection (should not happen per problem statement)
        if (node == null || node.next == null) {
            return;
        }

        // Copy data from the next node
        node.data = node.next.data;

        // Bypass the next node
        node.next = node.next.next;
    }
}

Time & Space Complexity (and why this matters)

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

Walk Through the Code (Interview Explanation)

Here’s how you would explain this to the interviewer:

• Since we don’t have access to the previous node, we cannot remove the current node directly.
• Instead, we copy the data from the next node into the current node.
• Then we skip the next node by adjusting the next pointer.
• This effectively removes the given node’s value from the list.

This explanation is short, clear, and shows strong problem understanding.

Final Thoughts

If this problem felt tricky at first, that’s a good sign. It means you’re learning.

What matters is not memorizing the trick, but understanding why it works. Once you get that, you’ll never forget it.

In the next sessions, we’ll continue pushing deeper into linked lists and beyond. Until then, take a few minutes to re-explain this problem in your own words — that’s how concepts really stick.

See you in the next one. 👋