Previous: see part 2 here
In my first post on this topic, I gave some general pieces of advice that should not have come as a surprise to anyone. Know how to do the stuff you are being interviewed for.
In this post, I will cover a particular aspect of interviewing that you may find in the technical interviews of many software companies: coding on a whiteboard.
I will not go into the specifics of why companies ask candidates to do this, or provide a comprehensive list of the companies that do this, but the fact remains that you may be asked to do this, and should therefore be prepared.
My advice for coding on a whiteboard can be broken down into the following topics:
- Coding on a whiteboard is very different from coding in an editor or IDE
- This is your opportunity to show the interviewer that you can write code
This is not an IDEThis means you have several disadvantages compared to when you are writing code at a computer. You need to keep a few things in mind in order to be able to put your thoughts onto the whiteboard efficiently.
Plan ahead - a whiteboard is a finite amount of space. Every time you have to go back and add variable declarations, or add another line of code to the end of a for loop you've already finished, is going to cause mess and delay if you have to erase and rewrite the nearby code or scrunch your writing to fit it in. If you put the closing curly brace at the end of the method before you've added its body, you should have a really good idea of how much space you need to write that method.
Know your language - you are going to be writing code without the aid of auto-completion, inline type checking, and other tools that an IDE provides. Nonetheless, you should know how to write syntactically correct code in at least one major programming language without relying on an IDE to fix mistakes as you go. You should know that Java's int primitive type does not have methods, or that C++'s pointer syntax uses a ->, not a .
This may be your only code sample
This may be the only code the interviewers are going to use to judge whether or not you meet their technical bar. As such, you should pay attention to what you are doing and how this will be viewed as a reflection of your coding ability.
Use reasonable coding style - I am not talking about whether you place your curly braces on the same line as an if-statement, or on the next line. I am talking about choosing variable names and using them consistently. Use abstraction where appropriate. Create methods. Use comments. Your code should be as easy to read from a whiteboard as it would be from a computer screen.
Check your work - As you write the code, be on the lookout for ways your code might break. When you are finished, take a look through it to make sure you don't have any glaring errors. Did you remember to return a value from functions that are supposed to return a value? Did you pass parameters where they needed to be passed? Running some sample input through your function might reveal any weaknesses you missed when writing it.
Practice - If you are preparing for technical interviews, practice writing code. It doesn't have to be on a whiteboard, a sheet of paper is fine. The point is to shore up any places where you would ordinarily rely on your programming environment (IDE, etc) to solve basic programming problems.
