I've spent time on both sides of the interviewing table and I think there are some misconceptions in this thread. Generally an on site interview is the last in

I've spent time on both sides of the interviewing table and I think there are some misconceptions in this thread. Generally an on site interview is the last in a series of steps for the candidate. They've already passed the early screening process and the company is investing serious resources in the recruiting process at this stage. Almost everything in an on site interview comes down to fit. The point of whiteboard exercises isn't to see how pretty your writing is or to make you stumble on brainteasers. It's to see how you think. The real key is to think out loud as you go through the problem. How are you approaching it? Have you seen a similar problem before? Can you find an easier version of the problem and try to get some intuition (ex 2d vs 3d)? What do you do when you get stuck? Asking questions to clarify things is usually encouraged. If you're nervous I'd recommend practice with thinking out loud while you solve problems. There are plenty of books full of interview level problems. Grab one and work through them while saying everything you think. Once you're used to that do more with a friend pretending to be an interviewer. If you find yourself getting stuck a lot I'd recommend reading How to Solve It by Polya. Sometimes you'll be asked to write code on a whiteboard. This is really unnatural. The interviewers also know that it's really unnatural. Unlike gcc whiteboard compiler is very forgiving. Usually people are looking for a couple of key things. Have you handled all of the corner cases? What about invalid inputs? Do you use reasonable variable names? Is your algorithm horribly inefficient? There probably are companies that give brainteasers type questions too much weight. They heard places like Google and Facebook use them so they will too. I'd treat this as a red flag and not want to work there. Unfortunately, there aren't a lot of better options for interviewing. Any problems given have to be relatively trivial due to time constraints. I've had interviews where you sit and write a test or code at the start and the next step goes over your answers. The problem with this is that you have to leave the candidate doing nothing for 30-60 minutes while someone goes over what they wrote. Tests you do on your own also have limited value. They're mostly useful as a low pass filter. They weed out the really bad candidates but can't tell you much more than that.