[sergiosgc]

They aren't using the brain teasers right. The Idea is not to create a barrier to entry, nor is it to stress the candidate. The objective of the brain teaser is having the candidates think slow enough that the interviewer can observe how he approaches a problem.

It's hard, when using problems that are common, to really understand how the candidates gets to the answer. Often, he's building on pre solved sub problems he encountered on his professional life, so the resolution process didn't even occur at the interview.

I personally don't use brain teasers, because they stress out valid candidates who do not work well under pressure. However, I think teasers, when properly used, are valid tools in an interviewers toolbox.

[dasil003]

Totally agree with this. The essential skill of a software engineer regardless of position is to be able to approach any problem no matter how unfamiliar or intractable and formulate a means of attacking it and verifying the solution. The right type of brainteaser can be a great way to demonstrate this provided: A) The interviewee hasn't heard it before B) It's meaty and not relying on some flash of insight (the manhole cover question is absolute garbage) C) you are able to capture the thought process in sufficient detail, either through verbally talking it out or writing down or whatever.

This has the potential to reveal a certain high level problem solving ability which the lack thereof will not necessarily be revealed by more concrete "write pseudocode for X" type of interview questions. What I mean by that is that there is a continuum of skills ranging from rote copying of solutions all the way through synthesizing solutions to business problems and designing architectures to fulfill a malleable list of requirements. A mediocre engineer can inch their way up the continuum through raw pattern matching ability (which humans excel at) without ever attaining mastery of the high level abstraction that are driving the implementation detail. Such engineers can appear tremendously productive at the ground level, but they are dangerous for an technical organization to have many of them because they tend not to see where technical debt is piling up and can often paint themselves into corners because they're not considering the bigger picture. Knowing someone has strong reasoning skills from very high level human tasks down is a good hedge against this.