I had to do that at my last interview. I got through it ok-ish. The more interesting question was a more general system design question - how would I architect a system to do X, under constraints Y and Z. What would I do if a new constraint came up? Ok, now how would I make it more resilient? There, the whiteboards is just a tool I can use, not the primary focus.
But it's the interview equivalent of your driving instructor making sure you adjust your side and rear view mirrors before you start the car.
Honestly, we all might as well read chicken entrails because that would be about as predictive as our current interview practices.
Can't do that in a whiteboard session.
Vast majority of the technical problems have been solved and its delivery a solution to a business problem that is the most important aspect.
Yes, I've been turned down for jobs over the white board but I've had more positive results than negative.
My sister, a pediatric ER nurse would disagree with you. The interviews are largely behavioral and are a breeze. No dummy is wheeled in with head trauma, random "new" diseases aren't invented and asked to be treated, etc. The simple fact of the matter is if hospitals hired in the same way, they would have no staff.
I know it's totally anecdotal, but we've all heard horror stories about candidates who couldn't write a for loop; some of us have witnessed these things first hand. And yes, phone screens should be filtering out those sorts of candidates long before they start sweating with a dry-erase marker in their hand, but, well.
How likely is an applicant for a nursing job to flat out not know how to stitch up a wound, or to take a patient's pulse and temperature?
"I know it's totally anecdotal, but we've all heard horror stories about candidates who couldn't write a for loop; some of us have witnessed these things first hand. And yes, phone screens should be filtering out those sorts of candidates long before they start sweating with a dry-erase marker in their hand, but, well."
Yes, it is a failure of how you have set up your hiring pipeline which you are now band-aiding. The majority of those folks can be screened by one look at a resume or in the first 30 seconds of the phone interview. Other hiring managers in our company repeatedly had this problem until we got them to focus of the right candidate qualities and ask the appropriate questions.
Take for example your local symphony orchestra; they have the same problem where people with visions of "making it" show up not being able to play at all. Want to audition? Send us an audition tape and a check. When you show up for the audition, you'll play a selection from these pieces and be asked to sight read this music. It is ironic that for an industry that is in a sense so subjective that the gates in the hiring process are more concrete.
To make an analogy, the software world is akin to:
Interviewer: "I see you are interviewing for the 1rst chair violin. The 3rd chair tuba player is really into experimental music, he would like to transpose Vivaldi's Four Seasons into a new scale with 12.5 notes per octave with a slight progressive jazz leaning. Oh, and since we all know there is pressure in performing in front of an audience, you have 30 seconds to think before the 2nd chair begins to throw rotten food at you. Reaction to stress and all you know...here is your tuba."
"But I don't play tuba...Are you asking me to play tuba? Am I going to be playing this nutcase's new music as part of our program?"
"Sigh...you don't know music do you?"
"Here's a couple of pages of unfamiliar sheet music that a second-year student should be able to play. You have an hour to figure out how to muddle through it on an instrument of your choice."
People hiring musicians don't do that, because they instead prefer to give candidates 16 bars of complex sheet music, and expect them to play it perfectly during the audition.
The programming equivalent would be to give someone a hard take-home problem, let them stew on it, bring them into the interview, and ask them to type in their solution, from memory, into a text file, on a keyboard with a broken Backspace key. That they will then compile, run, and compare the result of to that of the other 60 candidates auditioning for the role.
Are you sure you want to do auditions, instead of interviews?
> It is ironic that for an industry that is in a sense so subjective that the gates in the hiring process are more concrete.
That's because there's fifty thousand correct ways to solve a trivial programming problem, but only 'one' way to correctly play second violin in Vivaldi Four Seasons.
Music is a subjective art. Playing music is a mechanical process. My iPod can play music. My iPod can't implement a sorting algorithm.
Not a significant enough majority, imo.
I have no idea what the candidate did in their CS undergrad. Maybe they cribbed all their work from their roommate. Maybe they went to a party school. Maybe they spent the last 4 years as a 'Senior Developer' at FooCorp copying files from hard drives to floppy disks, and posting a few paragraphs a day on the company's WordPress install. Maybe they are an Architecture Astronaut who can talk for six hours about how great Haskell is at doing multi-manifold monadic trivariable entaglement, but has no idea how to do any real work.
Or maybe they spent the last decade building Bigtable and MapReduce, and Spanner, and TensorFlow at Google. I'm not an expert on Bigtable, or MapReduce, or Spanner, or TensorFlow, though - and I can't definitively, in 60 minutes, tell if the person I'm talking to is bullshitting me. I can't tell if they actually did any of that work, or they coasted. I can't tell if the complicated problem they are describing to me is actually hard, or if they are embellishing it. Even if I felt confident that I could make that conclusion, my opinion would be incredibly colored by personal biases.
Oh, I should check their GitHub, you say? Well, guess what - Jeff Dean - the guy who did spend the last decade building Bigtable and Mapreduce, and Spanner, and TensorFlow - doesn't have a GitHub account. Presumably because he has better things to do with his free time, then work on OSS.
Oh, I should hire fast and fire fast? Don't get me started on why that doesn't work...
Once you're an RN or an MD with all the appropriate qualifications, assuming you're not outright faking them, they can be reasonably confident that you are, in fact, a competent nurse or physician and move on from there.
We don't have that, and so we have to spend a lot of time making sure that a prospective candidate even has the basic skills and qualifications of a software engineer.
I'm not opposed to white-boarding, but to reinforce this point I'll note that I would have done much better on some of these problems when I was just out of college than I would today, because they were all fresh in my mind.
I assure you I wasn't a better programmer or employee then.
Not always a whiteboard, either; one of the best engineers I ever knew flunked a Google interview because of a situation where he had to write a bash script and read it over the phone to the interviewer, who apparently didn't transcribe it correctly on the other end. But "they only hire the best", you know, and their practices are rock-solid and proven.
https://www.youtube.com/watch?v=V7MXfg2wt28&list=PLqJcvcLs4C...
I, too, have a side project I'd love to quit my job to work on, but I think it's less monetizable than an actual game.
I've _never_ seen someone, or have asked to participate in, some sort of whiteboard coding thing. Even with pseudo code. That just doesn't seem helpful to me, at all.
Actual Code? Not a chance. Portability, Durability, Efficiency - It's the worst of all worlds.
> I am a quote
This makes the quotation doubly-distinct, and still readable on mobile devices.
===
To the actual point I wanted to make: plenty of engineers at companies code on a whiteboard. They schedule a meeting, grab a room, and talk things out, while making notes, diagrams and sometimes even actually writing out some code on a whiteboard.
I hope nobody asks people to write compilable code on a whiteboard, but asking a person to talk through a problem and jot down some pseudocode doesn't seem like an awful thing to me. Communication is a pretty critical part of our job.