Question

I’m reading Cracking the Coding Interview, Fourth Edition: 150 Programming Interview Questions and Solutions and I’m trying to solve the following question:

2.1 Write code to remove duplicates from an unsorted linked list. FOLLOW
UP: How would you solve this problem if
a temporary buffer is not allowed?

I’m solving it in C#, so I made my own Node class:

public class Node<T> where T : class
{
    public Node<T> Next { get; set; }
    public T Value { get; set; }

    public Node(T value)
    {
        Next = null;
        Value = value;
    }
}

My solution is to iterate through the list, then for each node to iterated through the remainder of the list and remove any duplicates (note that I haven’t actually compiled or tested this, as instructed by the book):

public void RemoveDuplicates(Node<T> head)
{
    // Iterate through the list
    Node<T> iter = head;
    while(iter != null)
    {
        // Iterate to the remaining nodes in the list
        Node<T> current = iter;
        while(current!= null && current.Next != null)
        {
            if(iter.Value == current.Next.Value)
            {
                current.Next = current.Next.Next;
            }

            current = current.Next;
        }    

        iter = iter.Next;
    }
}

Here is the solution from the book (the author wrote it in java):

Without a buffer, we can iterate with
two pointers: “current” does a normal
iteration, while “runner” iterates
through all prior nodes to check for
dups. Runner will only see one dup per
node, because if there were multiple
duplicates they would have been
removed already.

public static void deleteDups2(LinkedListNode head) 
{
    if (head == null) return;

    LinkedListNode previous = head;
    LinkedListNode current = previous.next;

    while (current != null) 
    {
        LinkedListNode runner = head;

        while (runner != current) { // Check for earlier dups
            if (runner.data == current.data) 
            {
                LinkedListNode tmp = current.next; // remove current
                previous.next = tmp;
                current = tmp; // update current to next node
                break; // all other dups have already been removed
            }
            runner = runner.next;
        }
        if (runner == current) { // current not updated - update now
            previous = current;
            current = current.next;
        }
    }
}

So my solution always looks for duplicates for the current node to the end, while their solution looks for duplicates from the head to the current node. I feel like both solutions would suffer performance issues depending on how many duplicates there are in the list and how they’re distributed (density and position). But in general: is my answer nearly as good as the one in the book or is it significantly worse?

Answer 1

If you give a person a fish, they eat for a day. If you teach a person to fish…

My measures for the quality of an implementation are:

• Correctness: If you aren’t getting the right answer in all cases, then it isn’t ready
• Readability/maintainability: Look at code repetition, understandable names, the number of lines of code per block/method (and the number of things each block does), and how difficult it is to trace the flow of your code. Look at any number of books focused on refactoring, programming best-practices, coding standards, etc, if you want more information on this.
• Theoretical performance (worst-case and ammortized): Big-O is a metric you can use. CPU and memory consumption should both be measured
• Complexity: Estimate how it would take an average professional programmer to implement (if they already know the algorithm). See if that is in line with how difficult the problem actually is

As for your implementation:

• Correctness: I suggest writing unit tests to determine this for yourself and/or debugging it (on paper) from start to finish with interesting sample/edge cases. Null, one item, two items, various numbers of duplicates, etc
• Readability/maintainability: It looks mostly fine, though your last two comments don’t add anything. It is a bit more obvious what your code does than the code in the book
• Performance: I believe both are N-squared. Whether the amortized cost is lower on one or the other I’ll let you figure out 🙂
• Time to implement: An average professional should be able to code this algorithm in their sleep, so looking good