How to get through whiteboarding interview (and have fun with it)
So you’ve got through the seemingly endless screening calls, listened to the recruiter shpiels and finally, you’ve got the message saying they want to bring you into the office for the in-person technical interview. Congratulations! Now, the next hurdle you need to get through is the often dreaded “whiteboarding” interview.
“Whiteboarding” is a kind of technical interview when the candidate is writing code on the spot, either on the white board (hence the name) or on a piece of paper, or (quite often) using the provided laptop.
Depending on the company and the individual style of the interviewer, the whiteboarding session can turn into a pressure-cooker that can destroy even the most experienced developer – I’ve had the “pleasure” to have a few of those and still remember them many years later. Despite those horror stories though, most whiteboarding sessions I had, turned out to be positive and even fun believe it or not. Over the years, whiteboarding interviews became my favorite for one simple reason – with the right approach, they are the easiest to navigate and give you far more chances for redemption than any other interview type.
One of the keys to a successful coding interview is to understand why they want you to do it in the first place. Yes, your interviewer is curious to know whether you can write decent code but most of the time, they go into the interview assuming that you can – otherwise they would not bother bringing you for in-person. The most important thing that your interviewer is trying to gauge is to see how well you can solve a problem and figure out your process, the way you think, communicate and work your way out of a tight corner.
That is the most important thing to keep in mind – you are not expected to deliver production-quality code. They want to see how well you can think on your feet and how well you communicate. If you deliver the goods on these two points, you can often get away with a few glitches in your code and still succeed.
With that in mind, the following five common sense steps will help you to make the whiteboardng session much less stressful and a lot more fun!
One: digest and restate the problem
This is the first thing to do before even touching the markers (or the keyboard) and it is going to make the rest of the interview easier plus score you some brownie points. Remember, the interviewer wants to see how well you can think and it is your job to demonstrate it.
Often the problem you are given will be loosely defined or even vague – it could be coding a simple “game” or simulating traffic lights, or anything else. Do not rush. Don’t try to code yet. This is your chance to show off constructive thinking. Begin with digesting the information you are given and then repeat the problem in your own words. Ask the interviewer if you are correct so far. If you are – good, you are on the solid ground. Now start filling in the gaps asking clarification questions (e.g. “do we need to have XYZ pause between the moves?”) until you have a good mental picture of the problem in your head.
At this stage, you are trying to demonstrate your thinking and communication skills. Both are crucial to the success of your interview so don’t try to cut it short and jump right to the coding – take your time to investigate the problem thoroughly, and to engage with the interviewer. Not only it paces the interview and reduces the stress, it also scores you bonus points. Win-win.
Two: remember the edge cases
This step is a continuation of the previous “problem investigation” phase. Try to think of possible border cases and bring them up with the interviewer: “what if the value drops below zero? Do we need to handle this case?” Often, you will get a pass on the non-essential edge cases (which means less coding later) while still scoring points for thorough analysis and good communication. Win-win.
Three: take time to talk about real life (aka tests)
Not every problem needs tests. Many of the interview problems are hypothetical and it is assumed that the resulting code will never run in production. Still, if you have a slightest suspicion that the code you are writing may be related to a real life problem, then it would not hurt to show that you care and ask whether/how the code is expected to be deployed and tested. A bonus point is a bonus point.
Four: write pseudo-code (with a lot of comments)
Now it’s finally the coding time. This part is where the rubber meets the road. By now, you should have a solid idea of what you need to do and at least some idea of the algorithm you’d like to begin with. The key point here is not to jump ahead of yourself. Always remember:
- Start with the easiest approach
- Work in iterations
- Always explain your idea and/or approach BEFORE writing any code
It is very common for the interviewer to start with a relatively simple “baseline” problem and keep on throwing curve balls trying to find a crack in your solution (e.g. “now let’s assume we have four cabins instead of two and they pause between the floors. How does it change your design?”). Using pseudo-code allows you to stay flexible and not to spend too much time worrying about the specific programming language syntax etc.
You should never assume that the problem you are given is the final one – it is virtually guaranteed that by the time the interview is over, the problem will morph quite a bit and so will your solution. The key here is to clearly explain each and every of your steps, HOW you arrived to the solution and WHY. Even if you don’t have the solution, do your best to show your way of thinking – think aloud if you have to.
A word of caution: it is often tempting to jump right into the coding, especially when the interview is computer-based (as in “here is your laptop, this is the compiler we use, now let’s code”). Resist the urge. Try to follow the same steps: start with the big picture and pseudo-code/pseudo-structures, then drill down in iterations until your pseudo-code is ready to become the real one. Remember, you are trying to showcase your thinking, not your typing skills.
Five: the final code
You may be wondering why did we spend so much time pseudo-coding and talking about approaches and algorithms? The short answer is: because it is the core of the interview. It allows you to showcase your technical chops without being bogged down with semicolons and angle brackets. Another consideration is limited time – most interviews take longer than planned and it is not unusual to run out of time right in the middle of the coding session; having a thorough pseudo-code solution will give you a lot more points than an incomplete or buggy “real code” one.
But let’s assume the stars aligned the right way and you have enough time to finalize your code. If everything went well, this is the simplest part of the process – your pseudo-code should be detailed enough to allow for line-by-line conversion to the actual programming language of your choice. Win!
Can you have fun while whiteboarding?
Of course! All you need to do is to pace yourself and follow the simple steps we just went over. To sum it up:
- Do not get ahead of yourself. Do not try to come up with the perfect solution right out of the gate – it will only result in unnecessary stress and errors
- Start with the simplest approach and work in iterations. Don’t get too hung up on the edge cases, you will take care of it on the next iteration(s)
- Be creative. Don’t be afraid to restate the problem or even bend it a bit if it allows for a better/more elegant solution
- And above all – communicate, communicate, communicate. Ask questions, explain your thinking, be yourself!
Even though the whiteboarding interview is ostensibly all about coding, it usually involves a fair bit of talking and I can’t stress enough the importance of that. Not only it gives you a chance to present yourself in a better way, it is also a great way to lower the stress and maybe trade a few jokes or past war stories (situation permitting, of course) creating a positive memorable interview. Win!