I agree: the hard mental work is in recognizing that a fuzzy, client-provided problem description is merely a disguised form of a well understood problem -- ie, getting it to the point where you can google easy solutions at all.

But then in that case, the problem as given is still bad, because it gives that part away! If you want to test this ability, you shouldn't frame the problem in terms of linked lists. As another poster here suggested, you should ask something like "The customer gave a list of everyone and who they report to. How would you sanity check the hierarchy?"

That then requires the candidate to identify cycles as something they'd want to look for, and then this problem as a special case of "find a cycle in a linked list".

Oh I agree. That's exactly the stuff I keep in my brain instead of linked list algorithms, which have a mathematically proven optimal solution. Remembering them when I don't use them regularly would be a waste of brainpower which could be better used for solutions to business/UX/architecture problems, which one cannot solve with pure logic.

I am not so sure. It's not just about solving the problem, but sometimes it's also the willingness and mentality to tackle something that's outside your comfort zone, as well as the approaches.

For example, given the loop in linked lists question, even if a candidate is not able to solve it completely, a reasonable approach would be to break the general case to more specific, trivial cases, such as: what if the loop has known length, what if the loop starts at a known location, etc. Interview questions are not binary decisions, you can learn a lot from a candidate just by seeing how they respond to a question.

(Just to be clear, as this is a permanent and public record, I'm perfectly capable of doing this kind of thing. It's not really an unreasonable question to ask. I'm just being facetious because it's friday afternoon.)