Take yourself back to 1989 or so when very few companies asked brain teaser questions so therefore there were very few people who studied brain teasers specifically to ace job interviews. The question for an interviewer was whether being good at brain teasers correlated to being good at a programming job in a statistically significant manner. Now combine that with a number of other interview techniques, each of which correlates well and you may have had something.
If you must search for reasons and meanings, it was probably because the kind of people who studied brain teasers for fun also happened to have a certain knack for the math-y problem-solving part of programming. Or they actually enjoyed solving problems for fun. Or both. I am not suggesting that we need to prove that the skill of solving a brain teaser was an important programming skill, it could be there was a root talent which expressed itself in programming and brain teaser abilities simultaneously. Or that some event in their past opened them up to learning two different and unrelated skills. All that mattered was whether you could measure a correlation.
But that was then. Today, I avoid such questions entirely. However, that is because IMO it no longer correlates well. Mostly because it has become popular enough that interviewees game the system by swotting up on brain teasers, so being good at them no longer means you have innate talent for math-y problem solving, nor does it mean you enjoy solving problems for fun.
So in summary I say that being good at brainteaser problems in a job interview no longer even proves that you're good at brain teaser problems, or like solving them for fun, but I disagree that it has never conveyed useful information to an interviewer.
The post was primarily based on my (limited) experence with good hackers I know and their ability to solve brain teasers. Most of them, incidentally, are not very good at it. The sample base is small though, so it might be skewed.
Also, in my opinion a lot of them are "aha" questions - once you get them they're obvious. They don't require deductive thinking, but rather that you "get" this particular question. A good example of this might be "Why are manhole covers round?" The answer is that round covers are bigger than the hole no matter how you turn them, and thus can't fall in. It's hard to deduct your way to this conclusion, yet once you get it it's obvious.
Questions such as "how many pianos are there in New York?" require a bit more deductive thinking, but I'm sceptical as to how much they say about someones ability to code.
But, as you point out, if there's a correlation, hoowever small, and you get other loosely correlated data it adds up.
I agree that this type of question isn't helpful because it's so easy to memorize the 'tricks' instead of thinking about the solution, but I find it fairly simple to deduct the reason for manhole cover shapes:
First, determine the requirements of a manhole cover (strong enough for semis to roll over it, movable for access, big enough for most people to fit in the hole) and the possible issues (theft, wear/tear/destruction, falling into the hole).
With these requirements, it's pretty easy to design an acceptable manhole cover:
1. The manhole cover must be at least 2' in diameter to allow people to go into the hole.
2. The manhole cover should be thick metal, both to increase life and to prevent theft (some manhole covers weigh more than 80 lbs).
3. The manhole cover should have a hole/catch mechanism in it to help open it.
4. The manhole cover should not be able to fall into the hole, so should be a shape that can't fall into itself (circles are the only shape I know of that follow this).
In the real world, many manhole covers do not follow all of these requirements (I've seen triangle-shaped ones), but this design outline describes the manhole covers near me pretty accurately.
I would argue the 'spirit' of the question (determining whether or not the applicant can use deduction to find an answer to a tricky problem) is still extremely important--it's just that this type of problem (and especially the manhole cover example) has been gamed.
I love discussing the manhole question because the alleged answer is not the point. The point of such a question is for the candidate to think aloud and walk you through their problem exploration process. Such questions select for people who are a little meta about themselves, which is why they can think about something and talk about their thinking at the same time.
But that really illustrates the trap of almost all interview questions. The interviewer is obsessed with the correct answer, when in reality it's the process of arriving at any answer that matters.
My personal beef with "Aha!" questions is that if given one that I actually solve on the spot, I can't tell you much about how I got it. It just came to me.
The only exception I can remember is a question about finding whether a linked list has a cycle in it. The "proper" answer involves a pair of cursors, one of which operates at double the speed of the other. I came up with a much less efficient but equivalent solution because the problem reminded me of something we did with Turing machines in college back in the 80s.
So in that particular case I could actually explain how I arrived at an answer. Now that I think about it, I think I'm a pattern-matching machine. My algorithm for solving problems is to perturb them until they resemble something I've seen before.
- The manhole cover should be thick metal - in some third world countries this is actually a problem because the heavy manhle covers have a substantial value as scrap metal, and thus get stolen. The heavier they are, the more cash they will bring in.
- circles are the only shape I know of that follow this - a reuleaux triangle can't fall into the hole either. Incidentally this is also the shape used for the turning part of a wankel engine. (http://en.wikipedia.org/wiki/Reuleaux_triangle)
Take yourself back to 1989 or so when very few companies asked brain teaser questions so therefore there were very few people who studied brain teasers specifically to ace job interviews. The question for an interviewer was whether being good at brain teasers correlated to being good at a programming job in a statistically significant manner. Now combine that with a number of other interview techniques, each of which correlates well and you may have had something.
If you must search for reasons and meanings, it was probably because the kind of people who studied brain teasers for fun also happened to have a certain knack for the math-y problem-solving part of programming. Or they actually enjoyed solving problems for fun. Or both. I am not suggesting that we need to prove that the skill of solving a brain teaser was an important programming skill, it could be there was a root talent which expressed itself in programming and brain teaser abilities simultaneously. Or that some event in their past opened them up to learning two different and unrelated skills. All that mattered was whether you could measure a correlation.
But that was then. Today, I avoid such questions entirely. However, that is because IMO it no longer correlates well. Mostly because it has become popular enough that interviewees game the system by swotting up on brain teasers, so being good at them no longer means you have innate talent for math-y problem solving, nor does it mean you enjoy solving problems for fun.
So in summary I say that being good at brainteaser problems in a job interview no longer even proves that you're good at brain teaser problems, or like solving them for fun, but I disagree that it has never conveyed useful information to an interviewer.