Whiteboard and the Coding Interview
Why is coding without a keyboard helpful.
Skills to probe during technical assessment.
There are two universes of skills that whiteboard coding probes:
- Writing clean code from the very beginning, and
- Reasoning about how does the code work.
Both universes of skills are essential for a great software developer.
Both universes of skills are probed extensively by employing whiteboard coding.
Writing clean code from the very beginning.
Whether we like it or no, modern software engineering is largely about knowing enough patterns and applying the right ones in the right order.
The result of a few days or even a few weeks of work often is a code change just a few hundred lines long.
On the surface, it does not matter much what amount of support did the original developer need while composing that code. They may have all the pieces in their head down to a character before getting hands down to code. Or they may use API documentation, examples and language syntax tutorial for each and every line.
Looking deeper, however, there is a huge difference.
Understanding concepts is more important than understanding facts.
The more complex a piece of code becomes, the harder it is to develop and even understand it based purely on the knowledge of some development patterns.
A good whiteboard coding exercise opens a door to probe those skills of understanding concepts vs. masking the lack of fundamental knowledge by keeping a large enough number of patterns in mind.
When we ask “What programming language is your strongest?” we don’t really look for crispy clean syntax. We look for a starting point to get further and to figure out how deep the rabbit hole is.
Here is a short summary of the mapping from “what field is the candidate familiar with” to “what aspects should be touched during the interview”:
- OOP — Multiple inheritance, virtual functions, object construction/destruction order, exception handling.
- Frontend — Asynchronous logic and closures, REST API-s, components and usability, validating user input.
- Algorithms and Data Structures — Motivation, usage, average- and worst-case complexity.
- Backend and Infrastructure — Memory model, garbage collection, multithreading, locking mechanisms, benchmarking, profiling.
- Functional Programming — Lambdas, currying, sequencing actions, monads.
- Kernel Level — File system, networking internals, POSIX, protocols, standard tools to examine / troubleshoot those.
- Testing — Unit-, regression and end-to-end testing, imperative and model-based testing, test- and behavior-driven development, integration testing.
The best way to talk about the above with the candidate is to start from an example. And the best example is a short and simple one they write themselves.
In practice, most code snippets the candidates would write will be imperfect. Which is a great opportunity to explore the boundaries of one’s knowledge.
Whiteboard coding helps because:
- The physical space to fit the code in is limited.
- The “coding” speed is limited.
- “Editing” is painful and is best to be avoided.
- There is no completion, syntax highlighting and other fancy IDE features.
Reasoning about what does the code do.
Walking through how a code snippet works is an amazing exercise.
When doing technical interviews, it would be an absolutely wrong thing to skip.
If the code presents an algorithm, one could walk through the steps. One could consider corner cases. One could write down invariants and prove them. One could explain complexity based on each individual looping construct or a recursive call.
If the code is OOP, one could articulate what does it do under the hood. When and how are the object created. How are they destroyed. When are constructors / destructors called, and in which order. What if an exception occurs. How would the memory layout look like.
It does not matter much at this point whether the code is perfectly clean or contains obvious bugs.
Watching the candidate carefully explain what is the code supposed to do on each step gives quite a few insights into the way they think and talk.
As well as into what other areas are worth going deeper into.
And, at the end, those are the skills that are to be probed during a technical interview. Not the skills to use an API and the skills to use an IDE to produce the code that accomplishes certain task.
Whiteboard coding helps because:
- The contents of the whiteboard stays more or less immutable.
- Changing the marker to color code “original code by the candidate”, “interviewer comments” and “candidate comments” is a great way to visualize the conversation.
Is it possible to assess the above set of skills without the whiteboard?
Yes and no.
For the part of writing clean code, I have no problem with allowing the candidate to code on their laptop.
The constraints would be:
- The code is projected onto a huge screen.
- The font is extremely large.
- Most or all IDE features are turned off.
Keep in mind that coding on an unfamiliar OS, keyboard and even editor is a challenge that is comparable, if not worse, than coding on a whiteboard. Either let them use their own machine, or confirm that the setup you may offer is comfortable enough for them.
For the part of reasoning about the code, whiteboard really helps.
Ideally, if the projector surface is itself a whiteboard, I would gladly allow the candidate to get to the projected code and take it from there, with a few markers in our hands.
I would, however, make it very explicit that getting back to the keyboard and “quickly fixing” certain things would not be allowed.
If there are only two people talking, and the printer is nearby, printing out the code — in a huge font — and analyzing it with a few colored pens works very well too.
Teaching helps practice those skills.
I am often asked how can one master the skills above. One answer I like to give is: Teaching helps a lot.
It improves both the skills of being an interviewer and an interviewee.
Myself, I have a very simple standard of my own level of knowledge. I consider my knowledge in certain area deep if I can give a talk and explain it without preparation.
In software, among other things, this implies writing flawless code without hitting a backspace once, and then explaining what it does, step by step.
If you often are the person who is being called over to explain certain algorithm or API — then you would likely have no problems passing and hosting whiteboard coding interviews.
Resume: Is whiteboard coding a necessary part of an interview?
It certainly is very helpful.
But one can get away without it.
Especially if there is a big screen onto which the code can be projected. Especially if this screen itself is a whiteboard surface on which the logic of the code can be explained afterwards, with a few colorful markers.
I personally like to gently push people towards the whiteboard until it works. And see no reason to retire this approach☺
