Serious question, if whiteboard interview aren't the best or helpful at all, what are the successful/useful alternatives for engineering interviews?
During my recent job search I was asked many questions I didn't know the secret algorithm to, but if those companies had given me the problem ahead of time and allowed me to research it -- just like what happens in real life -- I could have coded solutions to all of them.
And if you're worried about people just plagiarizing existing solutions, have them talk through it, as you say. Should be fairly clear if they understand each line or not.
1) Whiteboard
2) Review and technical discussion of existing code or projects
3) Paid take-home project
4) Pair programming on live code
5) Technical discussion only for rare cases for those Top Secret/NDA candidates that really can't discuss their past projects but are also time constrained
Some people do actually like to whiteboard. Keeping it around is kind of like legacy support for people who practiced hard to excel in those interviews.
This is pretty much the union of technical interviews that are well-known. If you switch out a technical interview format and can't get meaningful insights into a candidate, you're testing for the wrong things.
Most of what we do as engineers is trying to read code to figure out what it's doing, how to fix it and how to enhance it. Going through real code with a candidate and assessing their ability to understand brand new code (and what questions they ask) seems like it would give good insight to how they would perform on the job.
I've been on dozens of interviews, and that's the only time I've ever encountered that, but I think it does a really good job representing the job, as that's invariably what I'm going to have to do when you hire me, is sit down and familiarize myself with the code base.
He also asked me a handful of questions, said "Okay I know you know enough to do the job, let's see how much you really know," asked me a bunch of really low level stuff, and proceeded to teach me concepts when I told him I didn't know certain things. I walked out of that interview knowing more than when I walked in, something else that has never happened in all the other interviews I've had (except maybe I learned a new term that I never heard before that I was apparently supposed to regurgitate back because that's what was written down as the answer on HR's answer sheet).
Most whiteboard questions are always some esoteric algorithm any engineer worth their salt would in real life would look up before ever consider using to verify their own understanding before using it.
Putting someone on the spot saying whiteboard x is not ok.
However if the test is to see if they can take part in a meeting, then by all means do a white board, but ask them draw a workflow diagram or some other 40,000 foot type of diagram. Do not ask them to put code on a whiteboard.
(and if you wonder how anyone ever gets hired there, the answer is: by cheating. If you're going to interview at one of those places, odds are their interview problem and an accepted solution will be online somewhere, so you just go look up and memorize)
Our field is full of some of the smartest morons on the planet.
So much of the technical hiring process tends to be about trying to find people that match what you expect people to be. Which might be fine, you need to fill a particular position which requires a specific set of skills. You need to validate those skills. You do that by doing something semi realistic while trying to minimize the pressure of an interview situation.
But, then there is the other kind of approach where you are looking to see what the candidate can offer, trying to find people who know different things to you and do things differently than you, in this scenario you are more inquisitive and let the candidate direct the interview process and get them to show you things that sound interesting (including coding).
The first approach is all about finding specific skills. The second approach is all about being clear about the values you are looking for.
The second approach requires more skill and more time while wearing the hat of a technical recruiter.
You may need a little bit of both approaches.
So the big thing is to be clear about who you want to work with at the end of the process.
You end up spending all your time dicking around with missed semicolons and looking up library routines and shit like that. Sure, it's all stuff you have to do as part of a job, but it's also all trivial stuff.
The last time I had to do this, I spent time googling how to open up a port in python, and then read from stdin. It's just a waste of time.
All this does is test the wrong things.