Whiteboard Skills

http://www.coderust.com/blog/2014/04/10/effective-whiteboarding-during-programming-interviews/

Notes and figures on the side

Use one corner of the whiteboard to note down the requirements you have heard or an example figure that your interviewer has drawn. As you are thinking and asking clarifying questions to your interviewer take notes there. These can just be one-word bullets to make you remember all the scenarios.

Edits are part of the game

Don’t be afraid to change code. Several times, interviewers would modify requirements to see how you handle a slightly different or challenging variation of the same problem.

You will also have to edit your code if you find a bug during testing. In such cases, instead of overwriting or crossing out code, it’s better to erase and re-write that part of the code.

Before someone take a picture of the code, be sure you have written good/complete code.
https://writing.pupius.co.uk/whiteboarding-4df873dbba2e

Slow Down

Slow-down, chill-out, and try to write as neatly as possible. This will help you stay organized and focussed and will also helps the interviewer understand whether the code actually does what it is meant to.

Ask questions
Many interview questions are intentionally vague; the interviewer wants to see how you handle uncertainty and what assumptions you make. If you are implementing an algorithm, what are the constraints? Memory, runtime, size of inputs, etc.

As you are answering the question talk through what you are doing and what your thought process is. The interview is as much about the how you get to the answer as the answer itself.

Code how you’d normally code
One of the most common mistakes I saw was candidates getting lost in their answer. Hopefully you wouldn’t write a 50-line function in “real” life, so don’t do it in an interview. In many ways it is even more important to break up your code when working on the whiteboard; you don’t get to cut-and-paste, and in the heat of an interview it is easy to lose track of state.

Check your work
When you think you are done, check your work.

Most errors will happen at the termination cases. The best way to do this is to take a minute to run through the code with some sample input. It’s not unlikely you’ll have missed a case or introduced an off-by-one error, your interviewer won’t mind you taking time to do this, in fact, they’ll probably be impressed.

Also, check how your code handles unusual inputs and edge cases? Think about how you would unit test the code and write them up on the board.

When you think you’re done, take your code and see if it actually runs. Learn from what didn’t work.

Research

Presumably you want to work at the company you are interviewing at, so try and seem interested and enthusiastic about what they do.

You’ll undoubtedly get asked about the company’s products and “why you want to work here”. It can be hard to come up with good answers on the spot, so research the company and figure out what you’d say ahead of time.

Have fun

More than anything, try to have fun. Be curious and enjoy the challenge. You’ll get more out of process and probably come across better all the more because of it. As well as seeing whether you are capable, the interviewer is also looking to see if they would want to work with you.