4 ms·

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 c

by giaour 11y ago

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. When a candidate is struggling or even just asks me, "is there a trick to this that I'm not seeing?," I will give them pretty big hints. They get bonus points for knowing when to ask for help and/or for being able to incorporate new information into their code quickly. I've always been offered the same courtesy when on the other side of the table. That said, I personally don't give much weight to challenges or tests and would be surprised to hear if anyone considered them more important than relevant experience.

bostik 11y ago
> * 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.

by giaour 11y ago

bostik 11y ago

> * 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.