July 25, 2011 on the IndexTank blog, now down. Reposting it here so I don’t lose it.]
If you are reading this there is a chance you may not know who Steve Vai is. In my opinion, he’s the owner of the most gifted musical brain in the world. You may not like the style of music he plays or his guitar pyrotechnics. However, there is no question that most bands would kill to have someone like him on stage. David Lee Roth and Frank Zappa surely agreed with this statement. Here’s what Steve himself has to say about his audition with Zappa:
Now imagine for a minute that this audition had taken place in an office, and that Frank had told Steve: draw this song on the board and explain to me how you’ll play it. Well, you get my point.
There’s a lot of superstition in engineering interviews, and here’s where I need to pull my credentials. I’ve been interviewing software engineers since the 90s. I’ve interviewed hundreds of them if not over a thousand. One thing I can say with 100% certainty is that making someone code on the board won’t give you any information that you couldn’t get from a phone conversation. You won’t learn if the person is awesome or if he/she could build anything to save their lives.
The point of an engineering interview is to figure out if you want to hire a person or not. Obviously you want to minimize false positives and false negatives. Many companies tend to focus on eliminating false positives at the expense of having too many false negatives. This is because hiring the wrong person could be extremely damaging to a company. This is all well and good in a market where there is an abundance of qualified candidates. What if your system yields 80% false negatives and you can get one interesting candidate per month? Not hiring anyone is also extremely damaging. For a startup especially, not taking risks means dying.
The holy grail of interviewing is to remove noise. Ideally you want to evaluate a person’s capacity to perform their expected duties. Now, think about the last time you wrote code on the whiteboard at your current job. In my case, let me think… NEVER! Diagrams, architectures, design, etc. Code? F-NO!
Today, here are the things that I look for in a candidate:
1) Did he ever build anything? A Github account (or any other public code) is a plus.
2) Can he communicate? I want to see a blog and/or a Twitter account.
3) Does he live in the past? A good LinkedIn profile is worth 1000 resumes.
Past that barrier, of course I want to see for myself. I’m not saying that a software engineer candidate shouldn’t code at an interview. Far from it.
When you come to an interview with IndexTank, bring your laptop. Be ready to sit down and create working code. You don’t have a laptop? That’s a handicap, but not a big deal. You can use one of our Macbooks. Let us know if you want vi, emacs, Eclipse or even TextMate on it. Java, Ruby, Python and C will be available.
One thing we won’t do is ask “aha” brainteaser questions. Sure, being able to get four dudes across a rickety bridge is a proxy for a high IQ. Big deal. I know lots of people who are awesome at chess, Sudoku, etc. but will never hack for 48 hours nonstop because they are dying to see something working. Join the Triple Nine Society for example and you’ll meet some of them (there are great coders there too).
Over the years software companies have developed a cargo cult of interviewing people for raw intelligence and the ability to think quickly on their feet. People, get with the times. Teach your engineers how to run an interview, because it’s not trivial. Remove noise. If you don’t do all this, do not complain that it is a tough market for hiring engineers. Also, do not make fun of people who are not good fits for the job.
At this point I could go into many colorful anecdotes (e.g. my terrible experience interviewing at Netscape in the summer of ’98) but I won’t. One final word:
I sincerely apologize to the people I interviewed in the past five years who had to code on the whiteboard. It’s not happening again 🙂 Come chastise me on Twitter