Richard Wiseman has a nice retelling of the apples-and-oranges puzzle (which incidentally was a regular interview question at a company I used to work for):
Yesterday I saw a drinks machine that had three selections – Tea, Coffee or Random (Tea or Coffee). However, the machine was wired up wrongly so that each button does not give what it claims. If each drink costs 50p, what is the minimum that you have to put into the machine to work out which button gives which selection?
What I like about this is that it makes more natural several of the constraints of the original puzzle (a crate of apples, a crate of oranges, and a mixed crate):
- Why can’t I just peer into the crate and look at the contents?
- Why only draw one fruit at a time?
- Why do I care how many fruits I have to sample?
It also makes more sense of the effectively-unlimited supply of fruit that is implied by the question: if it’s the wiring that’s at fault and not the hopper of tea / coffee, you could refill it as many times as you want without affecting the wiring.
The puzzle, of course, hinges on the listener not paying attention to the crucial fact: the wiring for each button (or the labelling on each crate) is known to be wrong, not just unknown. It’s one of the neat things about this puzzle that an intelligent solver may well mishear it, but can easily prove it’s impossible if the wiring is entirely unknown. In point of fact, it’s a fairly simple to show that if it is possible, then the answer must be one: we can’t necessarily distinguish a random stream from a constant stream with any number of samples. Constructing a proof that one sample will suffice is fairly easy, given that there are only three possibilities of which to sample, and by symmetricity only two possibilities that differ.
Does this make a good interview question for a software developer? I’m not at all convinced it does. It feels like a meta-puzzle: you reason through it by knowing the implicit rules of the game of puzzle-writing (one obvious one being that the answer can’t be impossible, and it can’t rely on luck or “good enough” solutions like 1000 random samples). Good software engineering often involves judgment calls where such rules don’t exist, and great software engineering often involves rethinking the rules of the game entirely.