Interview Questions by the Vampire

Ted Hardy

Jun 26, 2013 • 3 min read

The first time I heard about the interview questions asked during Google's interview process, I had a few thoughts that basically went like this...

Whoa… that's crazy cool.
You know, I'm not sure I would be able to come up with a good answer to those questions.
Wait… what exactly are they trying to find out with those questions?

In all the job interviews I've been in, on both sides of the table, never once have I asked or been asked questions like the ones that Google asked. Yet, I've been very successful in my career, hired some fantastic employees and steered away from a ridiculous number of potentially disastrous (or even mildly annoying) roles or individuals, all without resorting to questions of this nature.

So when it came out recently that Google has stopped this process because it proved to be no better at helping select the best candidates, I felt a bit vindicated in not having tried this myself. Its awesome that Google came public about no longer following this practice, but even better, they let us know why, that it didn't work, they were stopping the practice. Google clearly looked at their performance data, compared it to the rest of the world and realized that these questions were not the way to really make a difference in their hiring.

There were lots of tech blogs and sites that picked up this news and posted about it. One in particular though, really caught my attention for a couple points it made. Here's the first one:

I built a custom a tool a few years ago that combines images into rectangular textures. It's not a big program--maybe 1500 lines of Erlang and C. There's one little twenty line snippet that does the rectangle packing, and while it wasn't hard to write, I doubt I could have made it up in an interview. The rest of the code is for loading files, generating output, dealing with image properties (such as origins), and handling the data flow between different parts of the program. This is also the code I tweak whenever I need a new feature, better error handling, or improved usability.

Its great to see someone give a real world example of why trick questions really don't match up with the reality of the jobs for which people are interviewing. Matching up your questions with the job the candidate will be performing and the culture of your organization is vital. If a potential employee isn't a fit for both of those, why would you care how great they are at answering brain teasers?

But the most important quote is this one, from the end of the article:

That's representative of most software development.

…and he just lost me. Google's trick questions may not have helped find better candidates, but the one thing you've got to admit about the company, they don't generally try to do what would be considered 'most software development.' Good C++ code is good C++ code, regardless of what company you work for. That doesn't change. But its what you do with that good code that makes all the difference in the world to your company. Companies all over the world write code; this is nothing special. Most companies probably have some level of code development even if they have a vendor doing it for them. That is 'most software development', but most software development is not what Google, or any really great software company, does.

So while the strategy of these crazy questions wasn't effective at picking the best candidates, Google was right to at least try something to make the process produce better results. I can't fault them for the desire and the attempt, even if the results were less than they had hoped for. Google wants employees who produce spectacular results, not who participate in 'most software development.' I'm sure that Google will move forward with a new strategy to improve their hiring practices and they are right for doing so. I can't wait to see what they come up with next. Maybe this time it will be something that helps us all.