Vanquish whiteboard interview puzzles with test-driven development

Whiteboard coding puzzles are of course utterly terrifying and totally unrealistic, which does not recommend them as an interview procedure. Yet they are still commonly used, which means the next time you interview for a programming job you might find yourself asked to solve an algorithmic problem with a 30 minute deadline, no text editor and a stranger who will decide your future employment staring at you expectantly.

Personally this is where I start to panic, just a little: am I fraud? Can I really write software?

I can, in fact, and so can you. And one of the techniques you can use to develop software will also allow you to go from a blank whiteboard to an impressed interviewer.

Let’s see why focusing on the puzzle is the wrong approach, and then move to explaining how you can achieve your real goal: impressing the interviewer.

Why solving the puzzle isn’t enough

The most important thing you need to understand is this: the puzzle is a distraction.

You want to spend the next 30 minutes impressing the interviewer. Ideally you will also solve the puzzle, but that is not your goal; your goal is to impress the interviewer so you can get a job offer. And if you do it right, sometimes you can even fail to solve the puzzle and still succeed at your goal.

Simply trying to solve the puzzle may fail to impress your interviewer:

Interviewer: … and so you need to find the optimal route for the salesman between all the cities.
You: OK, so… <stare at the whiteboard>
Interviewer: I’m getting bored. Here’s a hint!
You: <write some code>… OK, maybe that works?
Interviewer: Foolish interviewee, you have missed a bug that is obvious to me since I have given this puzzle to dozens of other candidates, most of whom were more impressive than you.
You: Let me fix that.
Interviewer: You are out of time. Next up, lunch interview!

Impressing the interviewer requires more: you need to show off your thinking and process, and take control of the conversation.

How to impress your interviewer

The details are important, but at a high level you must follow a four-step process:

1. Explain the steps of your process to the interviewer.
2. Write some test cases on the whiteboard.
3. Try to implement a solution.
4. Run all the test cases against the implementation. If the implementation fails the tests go back to step 3.

Step 1: Explain what you’re about to do

You don’t want the interviewer interrupting you mid-thought, or deciding you’re floundering. The first thing you do then is explain to the interviewer the process you are about to follow: writing tests, then doing a first pass implementation, then validating the implementation against the tests, then fixing the bugs you find.

Step 2: Write some tests

Write a series of test cases on the whiteboard: this input gives that output. Start with simple edge cases, and try to find some more interesting cases as well. Thinking through the transformations will help you get a better sense of how to solve the problem, and writing them on the whiteboard will demonstrate progress to the interviewer. Make sure to narrate your thought process.

Step 3: Initial implementation

Start solving the puzzle by writing code. To ensure you don’t get interrupted too soon, remind the interviewer that next you will be testing the code with your pre-written tests. If you get stuck, return to your test cases and see how you can change the code to do what they suggest. Make sure to narrate your thought process.

Step 4: Testing and bug fixing

For each test case, compare the output you expect to what your current code does. This will help you catch bugs on your own and again demonstrate progress to your interviewer. If you find a bug then rewrite the code to fix it, and then start testing again.

An example

Let’s listen to an interview that follows these four steps; your code may be the same, but you sound more confident and professional:

Interviewer: … and so you need to find the optimal route for the salesman between all the cities.
You: Let me explain how I will go about solving this. First, I will write down some test cases. Second, I will write a first pass implementation; it will probably be buggy, so third, I will run the test cases against my implementation to find the bugs and fix them.
Interviewer: OK, sounds good.
You: <write some test cases>… OK, next I will write a first pass of code. Remember that when I’m done I won’t be finished yet, I still will need to run my tests.
Interviewer: <This candidate will write high-quality code!>
You: <write some code>… and now to run my test cases. Feed this input, x is multiplied, run through the loop… this one gives expected result! OK, next test case… hm, that doesn’t match. Let me see… ah! OK, that’s fixed, let’s run the tests again…
Interviewer: Unfortunately we are out of time, but I can see where you’re going with this.

Go forth and interview

Next time you’re interviewing for a programming job remember these four steps: explain, test, code, debug with tests.

You will face your next puzzle armed with a process, helping you overcome your anxiety. By writing tests you are more likely to solve the puzzle correctly. And most importantly you will impress your interviewer, and maybe even get a job offer.