On Whiteboard Interviews

I've been on both sides of Software Development interviews for years: as company/corporate interviewee but also as corporate interviewer. A quick and little honest spoiler is that while I've never failed as candidate (lucky me!), I might have failed as interviewer. There's surely a lot to improve in every interview process but today I'd like to underline, quite out of the crowd, why I believe the whiteboard is still good.

Flattened Skills

In Moto GP they say that rain is capable of leveling all racers, because technology there cannot do miracles or help creating performance gap. If you compare all races results you'll see that official teams are constantly on top. Every time it rains though, the pole position and quite often the podium too, will see participants usually forgotten behind the 6th place.
I like to think it's metaphorically similar in front of a whiteboard, where neither the candidate nor the interviewer can take advantage of their tools 'cause tooling is something that everyone could setup and should be completely out of the evaluation equation when it comes to hiring.

Instantly ready to go

Forget whatever waste of time a pointless and often religious war about Mate VS Sublime, Atom VS Visual Studio or Eclipse, Gulp VS Grunt, Bower VS npm, and all the BS we created around coding in these years ... you have a white paper or a whiteboard, and something to write on it.
This usually made me feel very comfortable because you know you don't want to even start talking about how cool is vi and that's all you need otherwise GTHO you are not a real coder ... etc ... etc ... it's usually not even an ice-breaker, interviewers are those feeling cool powerful individuals that will judge you from the framework of your choice, from the library you prefer, even from the Operating System you use because you just never bothered much as long as you could work.
Just avoid any opinion on tooling, try to understand what are interviewer preferences, and pretend to be interested about such good choice .. .seriously, get over ASAP any sort of conversation and look at the board asking: "shall we start?" with a kind attitude, regardless is the interviewer maybe irremediably asshole but hey, nobody is perfect!

No Keyboard Layout Barrier

Unless you can do the interview with your own laptop, something I've honestly never seen so far, you have no idea what kind of keyboard layout you'll find there. OK, you are in your own country maybe you don't care much, but I've interviewed in Berlin and coding with a German Keyboard has been the worst possible nightmare ever, and during the interview 'cause instead of focusing on the code I had to find out where the HACK all right keys where.
It's not that different if you have a UK keyboard and you code on a US laptop: watch out when you go face to face in the US from Europe folks, they often forget the rest of the world has different language which include a different keyboard layout. In case of UK, quite important chars such `, @, and $ are in completely different places and if the dumb interviewer ask you to use jQuery in his PC instantly memorize that's not the £ sign!!!
Or ... impress the interviewer asking to code at the whiteboard and every problem will be solved!

quick personal note for my Italians fellow: forget bloody Italian keyboard layout if you are a programmer, just buy a laptop with at least a UK one or a US keyboard layout and code there. You don't need triplo-salto-carpiato to write a back-tick and using the dollar will result the simplest thing on earth ( "yeah but I need to chit-chat with" ... NO! If you are a coder accents in letters are not important at all! but of course, do what you want ^_^ )

Smaller Tasks Due Constrained Space

Whiteboard is actually playing a decent role in keeping interviews tasks small enough in order to fit without doing gym. This is good because both the interviewer and the interviewee will have the whole task in front all the time. No need to scroll: it's there for you to keep in mind everything you are doing: the whiteboard is there to help focusing!

You Shouldn't Care About Typos

When I was interviewing for a vanilla front end JavaScript role, you know already 99% of candidates knew only jQuery but applied regardless the role was explicitly asking for vanilla JavaScript and DOM knowledge: they probably couldn't tell the difference.
However, knowing jQuery when the team was eating dragons each breakfast in order to have decent performance on first mobile phone browsers, was the most useless and pointless skill set we could have asked for: jQuery wasn't even targeting mobile browsers at that time and we needed someone medium/senior level ASAP!
This put me and others in a position where finding a good candidate became quite impossible, and we had to be less picky every time more about CVs we were receiving because ... well, no-hacking-body had experience in DOM and JavaScript (I'm fearing nowadays is every day even more like that, but that's another story ...)

Back in topic, you got the scene, now imagine this: I've never even considered an error the usage of jQuery itself to solve any problem I could ask during these interviews and I've never cared if the whiteboard was full of mistakes, imperfections or syntax errors and trust me, I'm quite good as human linter!

The real lesson here is that you shouldn't care about mistakes and you shouldn't care about writing down correct API methods as long as you know there is some solution and, if you don't, you reason why solving that way is a good thing. That's literally it!
Why would I even care about errors when of course in front of your laptop you wouldn't have done that?
Why would I pick on a library API when all I'm interested on is how good at basic performance common-sense/improvements are you? Use jQuery or anything else I can understand on the board, and show me you have at least an idea on how to solve the problem.
Here again the board will help because nobody it's going to copy and paste (AKA transcribe) all that stuff and verify, you are there as candidate to show you are confident with what you know as developer, and you are there as interviewer to analyze skills beside the tooling and the perfection 'cause maybe you caused a disaster-bug the day before so you shouldn't feel too cool there behind your "powerful hiring role", right?

For those waiting for the end of the little story: Yes, we found someone at the end, and a good one that learned indeed in few days how to forget about jQuery and why it was necessary, in those cases, to forget about it.
The candidate has been a huge help for the team for the entire time I've been there so: thank you!

Is "Can't Google" The Problem?

Beside the autocomplete, and the fact you might have some API suggestion once you type a dot, but again I've just explained having a fully perfectly working result in my opinion is less important than going through the solution understanding chosen patterns while writing shenanigans on the whiteboard, if you need the internet because when you code daily you use the internet all the time in order to document yourself, we've got a problem.
Actually, to be fair, we've got two possible problems:

• the interviewer is simply showing off, asking something that difficult or unusual not even she/he would know if not out of experience happened by accident or finding it via Google: don't worry, you can clearly state "I'm afraid I've never encountered this specific situation, I might need to document myself before blindly trying to reinvent the wheel with a rock-solid solution".
  If whoever in front of you wouldn't appreciate such answer, you really don't want to be there and work with these kind if jerks around. Feel free to thank and leave the room (honestly? please do that, they'll be so pissed forever it'll be a pleasure)
• you actually don't know something you supposed to know for such role. This is the not so trivial part: admit you have no bloody idea what they are asking you, and if you need Google per each question maybe you applied for the wrong position? It's true that whoever interviews usually is the asshole with the knee pointing at your side, but let's be honest when it's hard it's hard. I've appreciated million times a candidate that after 10 minutes clearly told me it was probably a bad idea to apply cause not a single thing I've asked or mentioned made sense (I swear I wasn't drunk!). We used the time to chat about possible alternatives, talking about real experience and out of coding skills.

It's tough to fail and while I've said it never happened to me at the white board, simply because I luckily got hired at the end every single time, I have failed more than once few tasks. I didn't feel ashamed, it has actually always been an opportunity to learn something more! Learn every single interview, even with the worst person in the world, so that you can eventually prepare for someone even worst or succeed next time a similar task will come up.

Going Through, Instead Of Running The Task

I've also done interviews with the interviewer computer, and it was OK. Although I've also notice a huge difference: the interviewer never paid much attention to what I was doing, mostly waited for the final result to work and that's it. There was no going through each line explaining or commenting, cancelling with a wipe and rethinking with some hint,it as rather a cold "let's see if this works", but as candidate, I'd expect that whoever is interviewing me would know if my answers, and my skills would work, not just a possible typo written in a rush, during a surely more than usual nervous time ... we're humans, after all.

It's Gorgeous

This is the last point that might make no sense to most of you, but I wish in my life I'll become at least half as good as passionate professors are in front of a board: they know their shit, they can write in front of thousands without failing a single equation, and they'd be best mates to learn from, and to create with new wonderful stuff!