20bits - Latest Comments in Interview Questions: Loops in Linked Lists

Re: Interview Questions: Loops in Linked Lists

Vidar Hokstad — Mon, 20 Jun 2011 10:44:13 -0000

Just checked my Disqus profile and found this old reply...

Reasoning out the "Tortoise and hare" solution is not that uncommon - I've not had people do it in an interview myself, but I've talked to enough people who have found the solution independently to not think that the solution requires any particularly outstanding intelligence to come up with. I did in fact have no idea that Bob Floyd invented this algorithm until just now. Once I figured it out I didn't think any more about it because of the simplicity of it; I'm used to "inventing" algorithms that turn out to have been invented a long time ago and reinvented by every CS or maths student, graduate or self taught programmers ever since. Most people who study technical subjects or work with them end up doing this sooner or later.The solution flows fairly logically from a few simple observations, and the hard part is making the first few of those observations - pure chance alone would make a reasonable number of people figure out enough of the starting points to be able to figure out that solution.(and this is a major reason why expecting the *answer* to these types of questions, regardless how hard or easy the problem is is the wrong approach to using them in interviews)Generally, for the people I've talked to who has figured out this solution, the process is generally to try to figure out what makes a cycle different, and then try realize that if you can first make sure that the node you're on is inside the cycle if there is one, then the problem is trivial. Then all that is left is to figure out how to move to a node inside the cycle without getting stuck in a loop while trying to check the node you're moving across. Finally, you need to realize that it's not a disaster if you traverse a node more than once without figuring out if there's a loop the first time around - once you do that, it all just snaps into place. Give enough people this question, and someone will eventually muddle through it without any great insight or intelligence at all, just by stumbling onto these few realizations.Your appeal to authority and assumptions of how much time they must have spent solving a problem with no justification for why they would be particularly good at solving this type of problem, nor for why you think he must have spent so much time on it speaks volumes.(oh, and it's quite distasteful to accuse someone of lying while hiding behind anonymity, and also to jump to conclusions about how I supposedly "make job candidates suffer" for it. Particularly since in this case I've never excluded any candidates for failing to solve this problem, but I have *hired* candidates in several instances where a significant part of what convinced me was the way they've answered this question despite not solving it)

Re: Interview Questions: Loops in Linked Lists

vidarislying — Thu, 01 Jul 2010 16:22:54 -0000

Sorry to say vidar you're blowing hot air out some orifice! the tortoise and hare solution you claim to have "reasoned" out in an interview was invented by Bob Floyd who won the Turing award which means he was a computer science genius - I really doubt even he figured it out in 15 minutes which is by far the maximum time interviewers would allow you to solve a problem. People like you who pretend to be smart are the worst interviewers because you lie to yourself about your abilities and make job candidates suffer for it.

Re: Interview Questions: Loops in Linked Lists

axvpast — Tue, 23 Feb 2010 00:45:58 -0000

For my opinion the best solution (good balance) is just extend Node by additional attribute (visited).
After that we have really simple linear algorithm complexity without performance and resources problems. In first case we need more memory (because use additional array and SEARCHING something in this array!) or more CPU time (more assembler operations).
In 2 000 000 nodes we have:
8 000 000 pseudo operations in my solution
and
10 000 000 pseudo operations in suggested solution
means potentially my solution is in
20% faster

def has_loop?(node)
x = node
until x.next.nil? do
return true if (x.visited== true)
x.visited = true
x = x.next
end
false
end
---
2 conditional operations
2 assignment operation per node
1 memory region
Minimum random memory access (because algorithm memory usage (read ahead) easy predictable)

def has_loop?(node)
slow = node
fast = node
until slow.next.nil? or fast.next.nil? do
slow = slow.next
fast = fast.next.next
return true if (slow == fast)
end
false
end
---
3 conditional operations
2 assignment operation
3 memory regions

Re: Interview Questions: Loops in Linked Lists

jc — Fri, 06 Jun 2008 12:09:01 -0000

In the 'easy solution' you also first need to check for a list that has 2 nodes that are in loop.

Re: Interview Questions: Loops in Linked Lists

Jesse — Wed, 14 May 2008 13:14:49 -0000

Shaneal,

You're right.

Re: Interview Questions: Loops in Linked Lists

Shaneal Manek — Wed, 14 May 2008 08:51:53 -0000

I believe you have an error in your analysis of the 'easy solution.'

It runs in O(n^2) time, not O(n). I think since you are using an array to store the nodes already seen,for an n item list it will take take a total of
n + (n-1) + (n-2) + ... + 1 operations,
to determine if a given node has already been seen.

This is an arithmetic progression sums to n*(n+1)/2 = 1/2*(n^2+n) which is O(n^2) complexity.

I believe you can get an O(n) time complexity if you use a hash table to store the nodes already seen instead of an array.

Re: Interview Questions: Loops in Linked Lists

Jesse — Tue, 29 Apr 2008 01:35:35 -0000

Jim,

1) I never said it ran in constant time. I said it took constant memory, which is true.

2) <tt>has_loop?</tt> expects a Node object to be passed in, so it should never be nil. In a real-world situation I'd of course have exception handling, but the examples were meant to be illustrative rather than complete.

Cheers,
Jesse

Re: Interview Questions: Loops in Linked Lists

Jim — Tue, 29 Apr 2008 01:01:03 -0000

It's O(n) time, not O(1) time. Also, your tortoise/hare program will die on nil values (e.g. if fast.next.next is nil).

Re: Interview Questions: Loops in Linked Lists

Bruno — Fri, 18 Apr 2008 13:53:46 -0000

That's a very cute solution, the hare will eventually get to the end or catch the tortoise in at best n, at worst 1.5*n iterations.

Re: Interview Questions: Loops in Linked Lists

Jesse — Thu, 17 Apr 2008 18:34:15 -0000

If I want to see how people think I ask them questions with many moving parts rather than a very small question like this. In my mind questions like this are designed to see whether the person has a basic level of programming competency or not, but since the exercise has an "ah-ha!" solution it's not very fair.

In that vein asking how to reverse a linked list is better if you're going to be asking questions about linked lists.

In general if I'm not testing basic competency I want real-world examples. So, if I were hell-bent on asking about cycle detection I'd think of a scenario where cycle detection is an important part of the system (e.g., a question about dependency trees).

Re: Interview Questions: Loops in Linked Lists

Vidar Hokstad — Thu, 17 Apr 2008 18:10:55 -0000

Jesse,

It does/can have a path depending on how it's asked. There are many ways of finding the loops, and and generally most developers I've worked with can come up with several of them off the top of their head. The problem is when you specifically ask for a space efficient one.

When I've used this question I've always been careful to state up front that I care more about people telling me how they're thinking about it than the actual answer. With some prompting and discussion most good candidates can throw out good ideas, and many of them get pretty close.

I agree it's not a good question if it's asked in its most precise form and the interviewer expects the interviewee to come up with the good answer entirely on their own, though.

The first time I heard the problem was actually in an interview, and I did figure it out, but I also went through a number of other solutions first, and what ultimately got me on the right track was reasoning more or less like this:

- There are two possible situations: There is a loop or there's not a loop. If there's not a loop you'll eventually hit the end by following the list, so you only need to worry about what happens if you don't reach the end.
- Well, the most immediate thing that happens if you don't reach the end is that you revisit old nodes. This is obvious to most people, hence the number of people that suggest keeping a list of all visited nodes as one of the first suggestions.
- Whats your ideal scenario then if you can't keep all the nodes? It is to know that you have previously seen the node that marks the start of the loop.
- If you can't know what node is the start of the loop, is it ok to know _any_ node in the loop? Yes, because if you keep iterating you'll eventually hit it.
- That reduces the problem to finding a node that is guaranteed to be inside the loop if there is one.

- At this point I was stuck for a while, but the logical next step is to consider if you can divide the problem further. Well, you can try to divide the list. But you don't know how long it is. However, does it matter?
- It matters if you don't step into the loop. If you don't move your marker into the loop, you'll never see it when iterating over the list.
- How can you make sure you eventually get into the loop? You can keep moving the marker. But how do you ensure you see the marker when iterating over the list? You make sure you move the marker "slow enough", in other words slower than the speed you are iterating over the list with.

It is interesting to look at some of the methods used to solve it more than the solution:
- Divide the problem if possible. In this case the case with a loop and without. The case without a loop is trivial.
- Identify the consequences of the goal. In this case: you see old nodes again.
- Reformulate that as a goal. In this case: Find a way to recognize an old node.
- Simplify the goal. In this case: Determine whether a specific node is needed, or if any or all nodes are needed. In this case, any node in the loop is what you need to find.
- Divide the problem (or at least try). In this case: What happens if you try to consider part of the list? In this case that doesn't in itself work so well, but it is a good step towards the realization that you don't need to solve the problem for each part the first time you divide, or even to know how to split it in two - you just need to continue to get closer to the solution. Once you reach that realization you're on the home stretch with this problem, and the rest is just details.

Signs of understanding how to divide and conquer, and analytically approach a problem in ways that drive you towards a reasonable solution is what I look for when I ask a question like this, or similar ones. If someone provides the answer immediately it doesn't tell me anything, and I'd have to find something else to ask.

Re: Interview Questions: Loops in Linked Lists

Jesse — Thu, 17 Apr 2008 13:22:31 -0000

Vidar,

The first time I was asked this question I was unable to give that answer, too. I don't think it's a very good question, personally.

Good interview questions have multiple levels or some sort of path the interviewee can be lead down. You either know this solution or you don't. I didn't, and that's probably just because I've never had need to know if there's a loop in a linked list.

Re: Interview Questions: Loops in Linked Lists

Vidar Hokstad — Thu, 17 Apr 2008 04:57:38 -0000

I've asked a number of people that question over the years, and I've actually yet to meet someone who's given the "tortoise and the hare" version without a _lot_ of prompting and hints. It's only a good interview question if you use it to engage in a conversation, because frankly a lot of the people I've asked it that have been unable to answer have been fantastic developers. However it does give you an idea about how people react in the face of a tough problem - some people clam up and seems like they've just been defeated in personal combat, while others will instantly get interested and start throwing out ideas, and ask probing questions to try to figure it out.