Enough with the whiteboard coding during interviews

A part of my job is to interview people for software development positions.

Actually, I love interviewing people, my previous team was referring that as the "gbin's treatment".

The scary part they are referring to is when I try to push the candidate to the limits of what he knows on a specific subject. I do that to see if he has the "feeling" about how stuff is working when he actually doesn't know. It goes like this "It is ok not knowing this, but can you guess ? How would you implement it ?"

Beside testing the technical background/culture of the candidate, I also test there the attitude this person when he doesn't know something. I try to get some insights about him fitting or not the "Humility, Respect & Trust" values I want to build for the team.

Anyway, when it comes to test the coding abilities of this person, the last thing I would ever do is to put him in front of the dreaded whiteboard to code.

I mean by this, the practice probably condemned by Amnesty International to leave someone standing and thinking out live in front of a totally abstract problem with only one tool in his right shaking hand : the red marker. (*)

Let's take a Darwinian approach here and see which part of the programmer's "gene pool" is promoted by this.

The perfect whiteboard programmer will be :
1. smart as math-IQ-smart
2. self confident otherwise you panic and you cannot think
3. will think "out of the box" because the problem is never real and it is encouraged to find an original solution

Let's see how all this applies to a real programmer now.

1. interesting but is it the first trait you need ? How often in your daily developer life you really have to tackle a problem that needs this level ? And are you left alone thinking ?

2. bummer, usually good programmers are introverts and this is not by mistake. They could fail this miserably even with an IQ of 140.

3. This one is my personal favorite. You basically select people that generate strange solutions to never happening problems. This is exactly the opposite of a good team player for a software team. In the field, you need to produce code easily understandable by your colleagues so they can recognize which problem you wanted to solve and if a standard solution fits, which one you took. Ie. somebody that "think in the box" first !

So if you want to test the coding ability of someone, I would suggest to give him the chance to tackle quietly and alone a real mini project with :
- his favorite IDE
- google
... and enough time !

And make him use the whiteboard as you do within your team : to make him explain his architecture choices.

You will get a way better picture about how is it to work with this person.

(*) you never noticed that ? there is always one stupid working marker left and it is red.