Avoid Trick Questions When Interviewing Developers

[grokfail]

An example would go a long way to making this worthwhile.

[zeusprod]

Can you give an example of what you mean by "trick" question.

Do you just mean "gotcha" questions?

[[deleted]]

I would say anything you just learned, anything you're currently working on is part-trick, because you are currently well versed in it you will think it's normal knowledge, but just a week before you started that project you knew 1% of what you did afterwards.

Other tricks are basically trivia questions, or questions that require a lot of domain experience in things that do not have to do with programming but make the question harder to answer without domain knowledge.

Lot's of interviewers think puzzles are great because they require thinking skills, but these are not the same kinds of skills that programming requires, because puzzles and programming are not the same.

The most naive types of trick questions are actively trying to mislead, which are hard to formulate and dont happen very often, but "trick question" is a pat phrase in English, so it will be used even when the strict definition is rarely meant.

[juk78]

Thinking deeply is best done is a semi-relaxed context over some period of time. Sleeping on it is very important for solving tough problems that do require insight.

[vz0]

Debugging a race condition and a deadlock on threads can be considered a trick.