When you run a growing consulting company, you do a lot of hiring. We’re mainly hiring for Hadoop. Rather than being silly and trying and poach from the few hundred people with actual Hadoop experience, we look for people with certain prerequisites and train them.
Along with the usual HR interview, we have a typical three-pass process: a technical phone chat, a face-to-face interview, and the submittal of code samples or a sample project.
I generally start an interview with softball questions to lure my prey into a false sense of security (kidding). What I really mean is I want the interviewee to be as comfortable as possible, so I can evaluate their overall ability to communicate -- not just how nervous they get during interviews.
From there I ask a lot of basic technical questions to ensure the resume isn’t full of buzzwords they don’t know the meaning of. There are still people who put “Java” on the resume but simply mean they ran Java rather than know how to code in it (though I haven't run across one of those since hiring an HR person). There are people who have used all of the tools, but lack the depth to do so without deep supervision; for example, they may have used an RDBMS but don’t know how locking works or why their query might be slow. I can usually figure that stuff out quickly.
I don’t usually bother to ask basic syntax questions or other topics you could Google quickly without understanding the concept. Instead, I ask about matters you should know if you’ve been working in the technologies you say you've been working in.
The three most important questions I ask require a person to be able to think critically, even if the response is a lie.
1. "Describe the project you've worked on that you're most proud of. What did you do that worked out particularly well?”
This tells me a lot about what they know, what they value, what actual positions they've held on a team, and whether they actually think about what they're doing.
2. “Describe the project you've worked on that you're least proud of. What would you do differently?”
I need people who can learn, and learning means making mistakes, recognizing that, and doing a better job next time.
3. “If I have a Web application that I find is still running (via top/ps/whatever) but users are getting ‘connection refused’ when trying to access it, how would I go about diagnosing the problem?”
With the answer to that question, I get to hear about the interviewee's thought process, favorite diagnostic tools, and biases, as well as whether they really know how to solve problems. Getting the “right” answer isn’t important, but it tells me about how the person thinks and how well they've familiarized themselves with the tools they use.
What do you look for in a developer? What questions do you think tell you what you want to know beyond the basic technical aptitude topics?