[krutulis]

If the motive is laziness or the objective is to trick or intimidate a candidate, then I agree that the method deserves scorn. But I disagree with your position the technique is never reasonable. I like to hire people who know more than I do, and in this circumstance puzzles occasionally help learn about a person.

As a candidate I'm not particularly good at solving puzzles in this kind of situation, but I'm not bothered when people present them because the discussion and interaction about the puzzle matters more to me than getting the answer.

As an interviewer it is important to ask questions that a candidate cannot answer to see how they react. Since I'm a slow thinker myself, I must sometimes resort to "unfair" questions. I don't expect an answer, I expect a reaction.

After establishing a friendly rapport, finding common technical background, presenting an "unfair" puzzle, and discussing the puzzle a bit, then a discussion like this is golden:

Candidate: "Do you believe my ability to solve this puzzle indicates how well I could do this job?" Me: "No. Though I often enjoy puzzles, I'm not particularly quick with them myself." Candidate: "Then why ask a question like this?" Me: "Because I want to see how you react when you don't know an answer right away. In your case, I had to resort to tricks."

[derefr]

> As an interviewer it is important to ask questions that a candidate cannot answer to see how they react.

In the context of an interview, that would just make me horribly frustrated--because my default response to not knowing the answer to a question, nor even being able to perceive a method to resolving my ignorance, is to go out and research the problem.

Whether on the Internet, or by asking my coworkers, or finding an expert, or just running actual experiments and seeing a pattern in the large pile of data generated, this is usually "the" way to get a problem solved, and what I spend nearly 80% of each working day doing.

I don't rely on "sudden gusts of inspiration blowing through me" to solve problems, because the time that could take to happen is unbounded, and it can't be made to scale, unlike research, which can be delegated as you please.

But obviously, research is a tool entirely taken away from you in an interview. The only thing you can do to find out more about the problem is to ask the interviewer themselves--at which point you're basically playing a game of 20 questions, where instead of getting all the data you'd realistically expect in response to each query, you get dealt out precise quantities of informational entropy to string you along.

This contrived situation is not one that applies to the average day in the workplace, and being made annoyed by it is no useful measure of how one reacts to real non-obvious problems.

[krutulis]

Answering "In the context of an interview, [I get] frustrated because my default response to not knowing the answer to a question ... is to go out and research the problem [and I cannot do that in an interview]" is a nice response to not knowing an answer and would get bonus points for honesty and self-awareness.

The best candidates will recognize and comment on the ways in which frustration can be either constructive or destructive.

"This contrived situation is not one that applies to the average day in the workplace," is a serious over-generalization. Enormous amounts of code are written based on contrived beliefs about the way business does or should operate. The world would be much better off if programmers were better at recognizing and constructively commenting on these artificialities.

[tensor]

I personally think that "I would go out and research the problem" is the best answer. Introspection about response to feeling sounds like a huge waste of time and something best suited for people's psychiatrist.