The light bulb and the bridge riddle offer little insight into the problem solving skills of the interviewee: you either "get" the solution or not. There is not much room between the exact right answer and no answer at all.
The Boeing question on the other hand (like many other Fermi Problems [1]) might help you understand how the interviewee approaches a problem he doesn't know the answer to and whether or not he is capable of making sane predictions. But even though I think they are not completely useless, I expect a well prepared candidate to score better than some less well prepared, but in other regards superior candidates.
Yeah, I agree it measures preparedness more than skill.
Also, there is a difference between a great physicist with a playful mind asking those questions, and some nameless, annoyed interviewer whose only authority to ask such questions comes from the fact that he already has the job...
In other words, these riddles can be used to encourage creativity when used right. But they can also be used to put down the candidate no matter what the answer (what, you would put the expensive Boeing in water??? you must be crazy!).
My major at my college has a class that asks these kinds of questions on tests. It's widely considered to be one of the most difficult and painful weed out courses in the major. We were asked to describe how we would make an elephant fly, how much oil is used to make all the french toast for waffle house in a day, and other silly questions.
We were also asked to rewrite non-linear equations in new units, design simple industrial scale chemical processes, and generally do the kinds of problem solving engineering trains you to do.
These kinds of problems are relevant when done properly. The ability to reason with enormous quantities, think logically and out-of-the-box at once, make consistent complex plans, and, finally, explain these things to another person are often instrumental for solving problems and building new things. Those who passed and enjoyed this class are easy to pick out: they've been breezing through all of the upper level problem solving and group-based classes.
At the same time, I think something like that bike-for-the-blind answer is genius. Sometimes it does come down to rejecting the question or, perhaps better, redefining it in a way that is creative and useful. Who knows how well interviewers are prepared to respond to these answers though?
"These kinds of problems are relevant when done properly."
Yes, if done with the correct expectations. The real problems arose in that it is also a bit of a test for the interviewer too, in that the interviewer must understand the point of the questions, one which far too many of them failed. In the worst case, which happens far too often, you're sitting there trying to mind read the interviewer for the expected response: "How much does the plane weigh? I'd ask Boeing." "Nope, you can't." "What, why? The reason why that's not possible might factor into the answer...." "No, you just can't." "Well, I'd ask a librarian." "All the librarians are dead." "What, why?" "Doesn't matter. Do something else." "Well, I guess I could find a scale that might be able to handle the weight..." "No." "Why?" "You just can't." And so on...
(Because, honestly, "I'd ask Boeing or a librarian" really is the answer. Ask a better question next time.)
However, in the end my real problem with this style of questioning isn't that. It's the opportunity cost in the interview. While you're dicking around with the question of how much a plane weighs, you could be talking about their previous projects, or doing a programming problem, either one of which will teach you far more per unit time than a brain teaser. If you really want a brain teaser, ask a non-trivial programming problem. Anyone still asking these brain teasers might just as well yell out that they don't care about at least one of "your time" or "their time".
I don't need to filter people out based on their plane weighing skills. I want to know if you're going to spew cross-site scripting attacks into my websites, or if you're going to spew spaghetti code into my codebase because you can't do decent functional breakdowns, or if you think "var3" is an acceptable variable name, or if you're incapable of requirements analysis (the only thing those riddles tangentially touch, but not good enough for my tastes), or any of several other problems I've detected in interviews. There's better ways of obtaining all that information.
I enjoy interviews with these types of questions because I am nerdy enough to have wasted some of my youth buried up to the nose in logic puzzles and riddles, and sensible enough to research employers and interview tips to find out who asks these questions and which ones are commonly asked, and lucky enough to have studied mathematics and computer science at a university which teaches the birthday puzzle (probability) in its first term. Between all these, I'm not too bad at these questions, and very little of the reason for that is innate.
Anecdote: I was asked at interview "If I was in a room with 27 people and made a bet with you for $5 that no two people in the room shared a birthday, would you take the bet?". Answering "Yes", the reasoning being "I've done basic probability and covered the birthday puzzle, so know off the top of my head that you only need 23 people to get even odds" probably flagged me as arrogant (I had to explain why it was 23) but I felt good saying it. Interestingly the interview said only 1 in 10 people - interviewing for a fairly technical position that required a computer science degree - had encountered this before.
While I agree with the general thought about the interview, the last example question has nothing to do with riddles and falls into a completely different category: designing with constraints.
In a job where a significant part of your responsibility is figuring out how a feature should work, and balancing that with a variety of obligations (accessibility, security, resources, what partner teams need), asking a question like 'how would you modify a bicycle to make it suitable for the blind?' is a reasonable way to see a person's approach to working through various aspects of a design and weighing different features without relying purely on domain knowledge of a specific area of software.
The bike-for-the-blind question is a totally reasonable type of question, but a stupid example IMO. It could either be a common sense test or a constrained-thinking test, and isn't clear which it should be.
Well, that depends on the job... but indeed, the interviews most likely to ask these questions are exactly for the more pragmatic jobs. No university will ask prospective professors these things; instead, they will ask about what research they did in the past and what is their vision for future research.
Many of these are "think outside the box" type problems. For example, the one about the lightbulbs makes you think that the only information you get is binary - on or off. There are 4 possibilities - 0,1,2,3 on (position doesn't matter) but 6 configurations (123,132,213,231,312,321) making the problem impossible. The actual solution is to turn 1 on, turn a second on but turn it off just before you open the box, and leave a third off. Then it's a simple matter of checking which one's on, which one's hot and which one's off.
Interesting. I did not even think of that. I don't see many incandescent bulbs these days; the idea that a recently-switched-off light bulb was hot had begun to fade from my memory. I suppose that at the time of the question's heyday, however, your assumption of this second channel of information would have been a reasonable one.
Thanks for sating my curiosity though - I was reading this thread just to see if anyone had an answer to that seemingly impossible question. So that was the answer.
Of course they are relying on you to intuit some property of the situation that they don't mention. If they had said the box has three incandescent bulbs which become hot after they are switched on, most people would "get" the answer easily.
In a real application development situation, however, solving a problem based on what you assume to be true rather than what the customer asked for is usually a mistake.
I once applied for a job and got an email questionnaire back. On of the questions was, "Given 9 balls, one of which is heavier than he others, what is the minimum number of weighings to find the heavy ball? Write an algorithm."
I wrote back, "I have a question for you. What is the maximum number of balls from which you could find the heavy one in 5 weighings? If you know the answer to that one, then you know I know the answer to your problem."
Needless to say I didn't get the interview. Must have been written off as a smart-ass.
> "I have a question for you. What is the maximum number of balls from which you could find the heavy one in 5 weighings? If you know the answer to that one, then you know I know the answer to your problem."
I don't get it. What does that answer tell me? (Unless the answer I calculated for your problem was not the right answer, and the right answer would tell me something.)
If I walk up to the line and pick one ball at random and it is the heaviest by pure luck, that demonstrates it can be done in zero weighings - more than 10% of the time, even - so if your number was higher than zero it's not really a 'minimum'.
If you put all the balls on a stretched rubber sheet and picked the one with the deepest depression, would that be one weighing, nine weighings or no weighings?
Questions of that type often state that your only means of weighing the objects is a balance scale, i.e., you can put balls 1 and 2 on one side and balls 3 and 4 on the other to see which pair is heavier, and that's "one weighing". I'm guessing that's what russell's question is, at any rate.
I think it's implied that you want to know whether or not the ball you've picked is the heavy one.
What's not clear is whether "weighing" is a unary operation returning the weight of the ball, or a binary operation returning the heavier of two balls.
I just want to point out that not everyone who asks these questions is just a sheep following the herd. My last manager asked a few questions of this sort just to weed out the applicants who gave the "extremely overcomplicated solution for a completely non-existent problem."
While I personally enjoy Raymond Smullyan's logic puzzles, I don't think they are appropriate for an interview unless the job requires writing something along the lines of a Martin Gardner column.
Regarding bicycles for the visually impaired, I'd probably suggest a tandem model.
"the job will go to a candidate who manages to answer the question by designing an extremely overcomplicated solution for a completely non-existent problem. And that candidate will be the same person who designs their software."
I wont lie. I have been laughing for several minutes. We ALL know how awful that can be.
I would make the bike have three wheels for stability (the person is blind so they could potentially have trouble riding a normal bike) and give the bike AI. So the person is RIDING IT- not steering it. Oh gosh-that'd be like a blind person driving-no thank you
I'd put a wireless camera ala Justin.tv on the tricycle and hook the steering controls up to the internet.
Then outsource the driving to India. The blind person would state his destination and the Indian would drive him there using a mash-up of Google Latitude + webcam + wireless steering. The blind person would have to pedal.
I had a blind childhood friend who rode a conventional bike up and down his street, knew where his driveway was, could tell where trees were by their sound. He and I would ride all over town, he following me by the sound my bike made.
The interviewer's question is clearly not out-of-the-box enough itself, it is just in a little bigger box.
Pretty sure 13 minutes isn't possible. The constraints are: no more than two people on the bridge at a time, they have to walk together to share the necessary flashlight, and if someone doesn't have the flashlight, they can't cross.
i.e., if the 1 minute and 10 minute people cross first, it takes both ten minutes to cross. Afterwards, the 2 and 5 minute people are stuck without the flashlight, so before they can cross, someone has to carry the flashlight back to the other side.
It is a bit of a puzzle, but it's not really a very good one.
It's not a good puzzle at all - I kept on trying to think of the "trick" which would somehow make it faster than just the fastest person acting as the relay for all the other parties, but that really does seem to be the solution.
An excellent demonstration of why it's a bad puzzle--there's an obvious naive solution that most people get stuck at (the 19 minute one), and a single critical insight that reveals the otherwise simple optimal solution.
It's not testing logical reasoning ability; both solutions are "obvious", which one depending on if you know the trick.
It's not testing creative problem-solving; the solution is so constrained by ridiculous limitations that there's only one "correct" answer.
It's not testing skills for any sort of practical, real-life situation (I hope).
The main thing that questions like this reveal is whether or not the interviewee enjoys frivolous puzzles and riddles. Not the worst thing to select candidates based on I suppose, but probably not ideal, either...
As an aside, if "he was playing Monopoly" is indeed the expected answer I would be hard pressed to think of a worse type of question to ask at an interview. Using deliberately misleading phrasing to turn a trivial question into a riddle is not clever or insightful; asking a question like that at an interview goes beyond merely irritating to bordering on insulting. See also: http://xkcd.com/169/
Might as well ask the interviewee "What have I got in my pocket?"
If somebody loves riddles it only means that he loves to think and he possibly can solve really hard problems, where all others would give up...