Select Page

White boarding is wrong

Written By James Perkins

October 29, 2019

White boarding is the worst thing you can do in an interview. I have a passion about this and have always fought tooth and nail to get it removed from any company I have worked at. White boarding can show one thing about a developer, that they have memorized how to find the depth of the binary tree or reverse a singly linked list. It shows they have prepared for the white boarding by googling ‘interview whiteboard question examples’ and then done a bunch of them until they can figure out what 90% of the questions are asking.

Why I am against it

I am against it because it doesn’t show enough range of the developer, it doesn’t give the developer fair opportunity to show their skills and it I have yet to meet a developer in the universe who remembers every method in core Java or everything React does without having to Google something at some point. Some developers are algorithm wizards, others are great at implementing API’s with extendable and growth in mind, some developers are cool as a cucumber in an interview and others might be a sweaty mess.

What I propose

Developers should be given the freedom to work a holistic issue that is aimed at seeing if their skill set fits into the problem you are trying to solve by hiring them. The last place I worked I floated the idea of using a take home project vs having them come in and whiteboard.

The hiring manager was willing to give it a go, so we weeded out the candidates to a top 3, spun up an API for them to hit. Sent over the details for the project. We gave them a full week to complete the project, at minimum they had to hit 3 points. It had a UI, it hit an API, and they had to use Java + UI Framework that we were forced to use. That was it, we didn’t give them strict instructions that said ‘THE UI must have a lazy loading list of options’ or ‘The backend must be in spring and contain these methods and do these things before sending data down to the db’

The reason the freedom is there is because we wanted the ability to give the developer time to construct an idea in their head of how they would like to see how to create this as the end user and the freedom to spread their developer wings as far and as wide as they wanted.

What was returned

With the limited amount of instructions, we were given a wide variety of solutions to the problem. We had heavily UI designed projects that had bells as whistles with a simple backend, one with a simple and sleek UI with a fantastic backend and finally ones where they did the minimum only.

This gave us the ability to look at their solution from the UI and UX all the way to how they handled sending and receiving it from the backend. We didn’t care how they got to the end and submitted but when they did we could see how their minds worked and how they approached a development problem that would be similar to what they would see day to day.

When we talked to the candidates about their approach afterwards and had them explain why he chose to do something in a particular way it gave us even more insight into their ability, problem solving and could they explain why and how they implemented something. When we selected the candidate in question, he was a lot less experienced then the others but his natural ability and drive to learn new things was head and shoulders above the rest. I truly believe if we gave him just the run-of-the-mill whiteboard he would have failed, and we would have missed out on a better candidate.

You May Also Like…

Are you sorted?

Are you sorted?

Go sort package implements sorting for builtins and user-defined types. It's flexibility makes sorting a breeze!...

Looping in Go

Looping in Go

Looping in Go is fairly similar to any other language that you may of seen in the past, with some slight variations...

Git Command Line Basics

Git Command Line Basics

It's 2020, you have started to lean coding it's great to use an GUI like gitKraken however in some roles you might not...


Submit a Comment

Your email address will not be published. Required fields are marked *