> * You're right to think that's there's almost always a trick, but interviewers generally are more interested in watching your work process than in seeing if y

> * You're right to think that's there's almost always a trick, but interviewers generally are more interested in watching your work process than in seeing if you can get it.* This is true, and certainly my approach to doing interviews. I tend to ask two kinds of questions. There are easy ones, with lots of different solutions. On those I do want to see a working answer (because they are supposed to be easy), but I explicitly track how the candidate arrived at their particular answer. I get an idea how they think, and what kinds of solutions they consider, not to mention how they deal with bad approaches. And then there are the hard ones. They usually have exactly one correct solution, but finding that is not required. Instead I focus on how the candidate approaches the problem, and how they deal with different tradeoffs. The interesting bits are generally false path eliminations, the kinds of hints they need, and quite often how they formulate the problem to themselves. Once a candidate has shown that they pass a definite baseline requirement for proficiency, the rest is mostly about trying to see how they approach problem solving in general.