Ever been to an interview for a coding job where the interviewer doesn’t know squat?
Maybe you’ve had to patiently sit there with a look of faux-engagement on your face as they rattle on about why the role requires 10 plus years of experience in a particular coding language – only to politely point out that said programming language was only created 5 years ago.
Then again, odds are that your future employer knows their stuff – and will test your coding prowess.
So, the whiteboard coding portion of the interview is — arguably the most pointless and stressful way to incorrectly assess the coding prowess of the applicant. That being said, it’s best to come prepared if you’re to have any hopes of impressively dominating the dojo. To give you an idea of what to expect, your future employer probably wants to get an idea of how well you write code, and their skewed way of doing it is to put you on the spot.
Think of it like auditioning for the orchestra. Imagine you’re a violin player, except the interviewer hands you a trombone. They assure you that even a 1st year trombone player can follow the sheet music, and that you have an hour to familiarize yourself with the piece and play it flawlessly when you come back. You have no issue with the music itself, it’s just that you have no idea how to play brass when you’re all about those string instruments. The interviewer argues that a musician should know music, and in one way you do, but you’re unable to express it with the tools at hand.
In a sense the coding equivalent would be to issue a difficult problem in X coding language the evening before the interview, when you’re proficient in Y coding language. You rock up to the interview with the solution committed to memory, only to be handed a laptop with a text file on the screen. The kicker is that the keyboard has a different letter assigned to the QWERTY pattern displayed on the keys themselves.
Whiteboard coding isn’t quite that bad, but it’s not far off. The interviewer is conducting an audition, not an interview, by putting your coding know how on the spot and assessing it in real time. At the end of the day, whiteboard coding demonstrates how well a candidate writes code on a whiteboard, it has absolutely nothing to do with coding in a compiler or a development environment.
What Is a Whiteboard Interview?
In basic terms, the whiteboard interview is your shot at demonstrating how you apply your technical knowledge and inherent ability to solve a coding problem. The interviewer will ask you to use a whiteboard and marker to write out your lines of code while the panel watches you like a hawk and interjects with rapid fire questions about why you’re solving it a certain way and not another.
Whiteboard coding is something that every software engineer fears, on at least some level. The problem itself is meant to be familiar and doable for anyone who is competent – coming up with algorithms to draw a circle on a grid, or how to find the longest palindrome in a string.
The ever popular and easily beatable FizzBuzz test is one such example of a whiteboard problem, though its use has waned due to readily available solutions plastered all over the internet.
Why Do Companies Use Whiteboarding Interviews?
The whiteboard interview problem can take an hour or more to solve – which is a long time for anyone who is shy or who doesn’t enjoy the pressure of being put on the spot. This doesn’t really have anything to do with the code itself, it’s more a measure of your problem-solving abilities – only it’s not an accurate representation as you’re not working comfortably.
Some companies may even issue the problem ahead of time, as it’s not about the answer, but the thought process you use to get there. A whiteboard marker is a far cry from the tools you’re usually acquainted with coding wise – there’s no laptop here with a bunch of presets and syntax cheat sheets.
What you’re being assessed on is how you cope under pressure, and how you deal with the mistakes that you’ll inevitably make. Imagine there is a bug in your code that doesn’t pass testing – if you go to pieces at the first sign of trouble instead of getting to work to rectify the issue, chances are you won’t perform well in that role.
How To Prepare For Your Whiteboard Interview:
1 – Simulate:
So, it might sound crazy, but simulating the experience by buying your own whiteboard and markers is actually a pretty smart move. It’s a little different to writing with a pen on paper, so best get used to it.
2 – Practice Questions:
No one can predict the whiteboard interview problem (unless you’re a clairvoyant), but by making a list of popular options you can practice on your whiteboard at home so when it’s time for the real thing you know what’s what.
3– Film It:
As you work away on the whiteboard, film yourself. Getting an idea of how you look, and consciously being aware of certain things, will make the main event even easier.
4– Think Aloud:
The whiteboard interview won’t be an opportunity for you to concentrate and quietly go about your work. By thinking out aloud, you show the interviewer that you have the ability to work through something in a rational and efficient manner.
5– Sleep on It:
Resist the temptation to cram study the night before your whiteboard interview – your brain will need sleep to operate at peak performance the following day.
Tactics To Improve Your Whiteboard Interview:
Repeat The Question:
It may seem like a no brainer, but if you don’t understand the question, and if there is any confusion or ambiguity about what’s been asked of you – how can you hope to succeed? Repeat the question, and don’t be afraid to clarify anything you’re not sure of before you even take the cap off the pen.
Write Out Examples:
Before you write even one line of code, take a few minutes to make up a 2-column table – one side for the parameters you’ll pass into your function, and the other of what you expect to get out of them.
It’s also a good way to get the conversation flowing with the interviewer, as you check that your understanding of the task is up to scratch.
Describe Your Approaches:
Remember when you practiced thinking out aloud? Now’s the time to describe how you approach each facet of the problem, making a point to really emphasize why you’re going about things a certain way, and why you wouldn’t do it differently. Gauging the interviewer’s reaction will give you subtle clues as to whether you’re on the right track or not – giving you ample time to re-adjust your game plan.
Write Your Code:
Now that the planning and theory is all out of the way – it’s time to finally get to coding! But the way you go about it speaks volumes for your character, so there’s a few things to look out for.
Leaving sufficient space between each line gives you an opportunity to go back and neatly insert extra steps if they’re needed, or to move things around without using garish arrows pointed into occupied space.
Being confident is key, if the situation arises where you can’t remember the name of a function, or which function does what, simply write down what you want to do in plain English – remember you’re being graded on the process first, and the actual code second. Pseudocode is absolutely fine so long as the interviewer understands what you’re trying to get across.
Test The Code:
How on Earth do you test code on a whiteboard, without a compiler? Run through the lines of code with a different colour marker, putting a dot under the functions as you’re running examples through them to check the logic. It’s likely the algorithm won’t be 100% right the first time around, so this gives you a chance to mark your own work before your future employer gets a chance to go ham with the red pen.
Optimize:
Why say something in 3 lines of code, when 1 will do? Show you have a high-level understanding of coding by revising your work and seeing if there are any efficiencies in the code to make it shorter – less is more right.
The truth of it all is that although the whiteboard interview is, for the most part, a colossal waste of time – it’s just one of those necessary evils that you have to prepare for and may have to overcome to get that dream role you want.
Take the time to plan out your method of attack, don’t rush, and only begin writing the code when you’re confident and absolutely sure you’ve worked through what’s being asked of you, and how to get to the finish line.
Not knowing the answer is fine, you can still get the job – all you have to do is show your working, the rationale behind your approach to the problem and its now elusive solution. Being honest will get you everywhere but keeping your thoughts all bottled up and away from the ears of the interviewer will almost certainly get you nowhere.
Next Steps
Still confused or need some extra help? Check out our blog on FizzBuzz: Why It’s Used in Interviews and How To Solve It.
Kofi Group is proud to be a source of knowledge and insight into the startup software engineering world and offers a multitude of resources to help you learn more, improve your career, and help startups hire the best talent. If you are interested in learning more about what we do and how we can help you then get in touch or watch our Youtube videos for additional information.