Earlier quoted context omitted.
It might be the difficulty of actually getting it right (if by "right" we mean that all 52! permutations are equally likely. Or perhaps it is more accurate to say the ease of not getting it right. Something like this: 10 pick a number from 1 to 52 20 if not already printed it 30 print it 40 if we have printed 52 numbers 50 halt 60 goto 10 works, but could take arbitrarily long time. Most people prefer bounded run tim…
I like to use problems like this too. What’s nice about this example is it provides lots of scope for discussion (as you did) without requiring much domain experience. If the person can’t program their way out of a paper bag you’ll find out right away. If they are a junior hire, any working answer is fine. If they have more experience they can start to talk about why they chose the approach they did. If they are quit…
Instead, we'd pick whichever of the problems they find most interesting discuss the problem specification, and how we might approach it. We'd discuss what difficulties and special cases we anticipate. Then we'd look at the answer together and see if it seems to make sense. In these discussions I'd try to let them take the lead but would contribute enough to get things moving if they are getting hung up on something.
Finally, we'd go to the most valuable part of LeetCode, the discussion forum for the problem. In the discussion many people post their solutions and a lot of them are wrong. We'd look at a few of those and review them, again with me letting the candidate take the lead.
The great thing about the discussions is that the answers people post contain a wide variety of mistakes. Some don't solve the right problem. Some do get the right answer but don't meet the time or space constrains from the spec. Some miss edge cases. Some fall apart if the problem is too big (e.g., if an input array is big enough that every unsigned integer the language supports is a valid index).
Before we started I'd tell them we are going to do that, so when they hear the word "LeetCode" they don't have to worry even for a moment that I'm going to spring some hard trick question on them and expect to solve it under pressure. I'd probably even ask them if they have any LeetCode problems they have seen or did before and would like to use for this discussion. Since I'm not asking them to solve them, it doesn't matter if they've already seen them.