Whiteboard coding is really awful.

A plea for sanity

“I don’t want to be on an engineering team with people who were primarily chosen by their ability to write code on a whiteboard.” — Unknown

There has been a trend in the modern technical hiring process that I’ve come across while on a job hunt. I’m referring to the screening process for developers which now consists of either a quiz about your technical understanding of a language (Javascript, PHP, etc.), or the good old whiteboard coding.

I get the thought process behind these challenges. You want a candidate who can think on their feet and react to unexpected challenges. You also want a developer who has the technical knowledge to be able to construct complex functions on the fly.

The problem I have with this practice is that though I write code in many different languages across multiple platforms, there is only so much I can rattle off the top of my head at a given time. Here’s a visual for you:

Its no secret that as developers, we owe our careers to Stack Overflow. Many times throughout the day, we want to do a certain thing and can’t exactly remember how to write it, or have never done it before and want to learn how. This is how we grow ourselves and our company.

For example, I still have to look up how to write the font-family style syntax even though I’ve written it thousands of times. This doesn’t mean I don’t understand its values or properties, it simply means that the spelling of sans-serif always slips my mind.

“Just because you don’t know what is on page 200 of the dictionary doesn’t mean you’re not a writer.” — My wife

When I’m put up against a whiteboard and asked “how would I make this function perform in a certain way?”, I can think of a dozen ways that it might work, but perhaps this job has number 13 written down as the correct way.

A better way

There are a slew of better methods to test your developer.

1 . Give your developer a piece of code and ask them to look for errors and debug it. Preferably, on a laptop with a compiler that isn’t the human memory.

2. Have your developer write a real function with a base markup file to work from. Let them use a computer with everything ready to go to give them a natural environment to work in.

3. Show your developer some bloated, outdated code and ask them to improve it to a smaller, cleaner size. Give them a baseline if you must (file size must be under 5k for example), and let them take the time to figure it out.

This process feels like taking a wild animal and judging it on how it behaves on a leash. Put your developer in their natural environment, give them a real-world problem, and let them prove that they will be a valuable part of your team.

Like what you read? Give Drew Parroccini a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.