It's Time to Retire the Whiteboard Interview

A completely inadequate way to evaluate coding abilities...

What’s Wrong With Whiteboard Interviewing?

It doesn’t test for coding ability, it tests for working under scrutiny.

The goal of course is to weed out frauds, applicants who have been untruthful about their skills and experience. And there are plenty such. But it’s not a good way to do even that. Neither is it a way to judge the ability of honest applicants.

For many entry level candidates the whiteboard interview is the first impression of the software industry and what it expects. The impressions it creates are false. They encourage bad work, bad priorities. 

The circumstances of the interview bear no resemblance to life in the workplace. Interviewers are usually untrained and out of their depth, repeating how they were interviewed (badly). Sometimes they enjoy the discomfiture of their candidate.The questions are predictable and often out of date.

Then why is whiteboard interviewing the universal evaluation tool of choice? 

We’ve always done it this way.

There is a lot more wrong with software development interviewing than using whiteboards; the entire procedure is deeply flawed. I’ll get to the whiteboard coding soon enough but first …

These are my personal views — I’m a developer who has worked for Microsoft and other companies as a software engineer for over 30 years. I’ve had abundant interviewing experience on both sides of the table. These are my views.

Incompetent Interviewers

A developer is told that a candidate is coming in for interview; the developer has no training in interviewing and isn’t given any guidance. Likely the candidate will be run through the mill, more than one interview session with no coordination between interviewers, so the candidate may in fact be asked the same question more than once. Yes it really is that bad.

The interviewer tries to relax the candidate by asking a few questions he thinks are innocent but which are actually illegal. 

• Anything about the candidate’s age or family size is risky, age discrimination is a real thing
• A candidate with children may have to lose time at work to care for them
• A candidate with no children might be gay

It is guaranteed that the interviewer, wholly untrained, has no idea that the innocent question had potential for a lawsuit. And some candidates do know what questions are illegal. “That’s none of your business” is an impertinent response, deserved though it may be.

And the interviewer is behind on his own work already (that’s likely why they’re hiring) and his ill-concealed resentment at an hour taken from his day doesn’t help.

The interviewer’s lack of skill creates its own tension; maybe he has an impenetrable accent and the candidate has to ask him to repeat, maybe several times. Now he feels insulted. Maybe he sniffs and fidgets and offers misleading suggestions when the interviewee pauses to think.

And it’s under these conditions that the candidate is expected to concentrate and show his best work? This is unreasonable. 

Resentful Interviewers

I hope this doesn’t come as a shock but some people are just jerks. In one interview years ago I had told the company before I drove in that I hadn’t studied COM yet; it was new at the time and while I knew about GUIDs and the three required methods I had never written a COM object. 

The interviewer, an overweight young man with a beard, immediately told me to (wait for it) write a COM object. I reminded him I hadn’t learned to do that yet. So he took the keyboard and put on a show of typing out a rudimentary COM class, acting smug and superior. 

What was the point of this? I had driven to this office, awaited my turn at bat, just so he could show off. He didn’t ask me anything else; having shown he knew how to do something I later learned in twenty minutes, the interview was over. He had me drive there, raising my hopes, just so he could do an insignificant boast.

Some people are astonishingly petty, condescending, or even sadistic, enjoying the discomfiture they can put into someone at a disadvantage. In the desperate days after the Lehman collapse when there were tens of thousands of engineers out of work in the Seattle area I was interviewing for a job I absolutely didn’t want and which paid half what I had been earning; my interviewer was appallingly condescending.

A hostile interviewer can turn your interview into an hour of hell. He may be so abusive that you just need to leave. And once you’re struggling to keep keep from teaching him some manners, you are not going to perform well on a whiteboard. In this case you should walk out, report your experience to the agency that arranged the interview. 

Just because you need a job doesn’t mean you have to put up with overtly abusive people.

Antiquated Questions

Then come the coding questions. There are a small number of questions that are used over and over, for example:

• reverse a linked list
• find the first repeated character in an array
• search a binary tree. 

Note what all these have in common; they are low-level algorithmic code, the kind that few of us ever have occasion to do anymore. This is where the ridiculousness becomes a tangible thing, with definable features. 

Legacy Interview Problems

Lists, arrays, trees … hardly anyone works at this level. I worked with linked lists twenty years ago, I’ve never worked with binary trees except in interview questions. All these primitive types have long ago been wrapped into classes that have thoroughly tested by thousands of users.

We don’t write much assembly language either.

But they’re still in interview questions. This is akin to interviewing an architect of consumer electronic designs by having him repair a broken VHS tape. Yes it is possible that at some point a developer will have to write some very low-level code, but what is the point of centering the interview around evaluating abilities that the candidate will likely never use? Have me write a lambda expression or optimize a query and explain why I did it that way. Interviewers rarely ask for explanations. 

Stock Interview Questions

There are a dozen or so such questions that are circulated in these interviews, and a lot of false positives come from phonies who have memorized the answers. Since the interviewer has no training and has little time to prepare he will just trot out a few of these stock questions. Questions for which the interviewee has researched online and memorized the answers. This yields a false positive; he passed the coding test. It is likely the last time he will ever work at this level. 

Until his next interview.

Make no mistake; it’s important to be able to do this kind of work. But where in the early days of C, from whence the whiteboard interview originated, we all had to be able to do this. If it comes up again then yes, we should be able to think closer to the binary level.

But why make uncommon work the centerpiece of almost all interviews? Isn’t it much better to explore the candidate’s wisdom?

Optimize! Optimize!

Real developers with any experience (other than slavishly following team standards) know that solidity and stability are more important than speed. 

Nobody remembers if a page load takes a few extra milliseconds; nobody forgets crashes and broken functionality. Optimization is more a design- and query-level than a code-level operation.

Overemphasis of Optimization

I’ve never had a whiteboard interview where I wasn’t asked to “make it run a little faster.” This is the strongest imperative in whiteboard programming; take shortcuts, shave off a microsecond here, break the rules there.

It makes little sense to evaluate a candidate by seeing evidence he can do things we mostly stopped doing a quarter century ago.

Optimized code is by definition rule-breaking code. Optimized code is more fragile. 

Optimization should be reserved for the small percentage of code where performance is actually critical. And any developer worth his salt know that the place to improve performance is at the level of design. I can improve a page load a hundred times more with a query optimization than with a low-level code hack.

Bad First Impressions

Since the interview is an entry-level applicant’s first exposure to software as profession, this imperative to optimize is taken as an important lesson. 

Thereafter all his energies go into shaving off microseconds, applying code-level optimizations absolutely everywhere. Our industry is overridden by performance-obsessives who never notice how much of their carefully optimized code runs at user speeds. This is not only destabilizing, not only wasted time, but pulls attention away from the kind of optimization that actually matters. Do a low-level trick to populate a list … but put a network call into the loop that fetches its data.

Wrong Tool for the Job

A whiteboard isn’t a text editor. It forces the interviewee to write on a wholly unsuitable medium holding a solvent-scented marker that gives him a headache. Inserting code does not push down a closing brace and it requires him to plan spacing in a way that isn’t a consideration in work, not ever. 

We want to see how you work under pressure

Unrealistic Pressures

Saving the best for last. In a whiteboard interview the candidate is under constant scrutiny. In my first such interviews programming was a hobby to which I had no sense of personal attachment and I breezed through the process, easily thinking on my feet and ignoring the other person in the room who sought to throw me off guard with his misleading questions and his fidgeting. Later my work was more and more part of my identity, my sense of authenticity and I began to freeze up from being watched.

The justification for this is “we want to see how you work under pressure.” Well, “pressure” is a polysemous noun, and the pressure that we feel trying to meet a critical deadline has no more to do with the pressure of working under scrutiny than it has to do with the pressure in a hyperbaric chamber used to reverse the bends in a diver who has surfaced too quickly. As justification, this is dishonest.

As I became more experienced, better at solving problems, wiser in my work, my ability to concentrate under these conditions left me completely. 

I couldn’t think at all, I would blow the interview, and on my way back to my car even awash with bitterness I would solve the same problem three separate ways in my head in a few seconds. Once in a while it worked during the interview, but most times I simply froze up and couldn’t concentrate at all, and I know many others who have had the same experience. This is a false negative.

(Photo by You X Ventures on Unsplash)

Alternatives to Whiteboards

The best interviews I have ever had, the kind where I have always been the winning candidate, are the ones where we talk about problem solving, about software design, about striking balance between stability and performance. 

1. In one we designed a memory manager and after half an hour had ideas about garbage collection and free-space coalescing that would have worked very well in implementation. Hired. 
2. In another we talked about when and why to do code-level optimization rather than actually writing any optimized code. Hired. 
3. In yet another we talked about ways to do site queries with serial fetches of more data than needed but discarding the unused, and re-fetching aggregated data rather than doing single calls with complex JOINs. Hired. 

All of these were discussions between two experienced and insightful people, one the -er and one the -ee. And neither a whiteboard nor marker pen in sight.

If someone has been in positions of increasing responsibility for decades it’s pretty damned unlikely that he has been unable to write code that whole time. Deceptions of skill level have a shelf life of weeks at most, days more likely.

Not years. Not decades.

Wisdom Beats Cleverness

I have conducted dozens of interviews, never once sending the candidate to the board. 

Many times I rejected an applicant whose answers showed he hadn’t really learned anything; however The Team did their work was how he would do his. Conformity was his highest virtue. He had no real understanding of what he was doing. Other times I gave the up-thumb to applicants who hadn’t learned that much yet but showed promise because they were already thinking about their work and trying to find balances.

Jettison the whiteboard interview.