"Understand what kind of problem it is" could be reworded to "Find out what the interviewer wants from you, and don't make unstated assumptions", and could be t

"Understand what kind of problem it is" could be reworded to "Find out what the interviewer wants from you, and don't make unstated assumptions", and could be the subject of its own post. The biggest problem in technical interviews is when the candidate doesn't know what the interviewer wants from them. Maybe they want unit tests, maybe a rough functional spec... maybe what they really want to see is how you'd explain your algorithm to a junior developer. If, as a candidate, you think you've been given an egotistical interviewer that really just wants to see if you can read his mind, mentally reframe it as a test of your ability to not make unstated assumptions. I've had interviews when I've tried to clarify whether I need to do things a certain way or provide something like unit tests, and met with the response "I don't know - do you think that's the kind of thing you should do?" If you get this as a candidate, the best solution is to talk a briefly about what you'd do in a real-world scenario (where you have context, tools, connectivity, time and teammates). If that doesn't reveal anything, explicitly state an assumption and why you're making it and move on. If you give technical interviews, I implore you: when the candidate asks what you want from them, don't be coy or sneaky about it with the justification that figuring it out is part of the interview. Tell the candidate what you want. If what you want them to do is role-play a scenario where they extract requirements from you, tell them so. If you just want the damn FizzBuzz code so you can move on, tell them so.