I've been interviewed a lot and interviewed candidates. I've had phone interviews, coded on a whiteboard in person, coded on a web site that was viewable by the interviewer on the phone, had to debug code, been asked syntax questions, data structure questions, questions similar to the classic "How would you move Mt Fuji?", and my management style, etc. In one hellish day, I was once interviewed for 8 hours straight by a company (I wanted to check-up on a friend who's Dad had just passed away in the city where this company is HQ'd, and this company was willing to give me a free flight for the interview, so I figured I'd kill 2 birds with one stone. In the future though, I'll just buy a ticket myself instead of wasting a day of my life). I once scheduled a phone interview with a company while I was on a road-trip so I'd have something to do because this company was known for giving brain-teaser questions such as "How would you move Mt. Fuji?". It made the trip a lot more fun! Another time I was asked to basically implement a whole damn feature into a potential employers code. It took a whole weekend, and I ended up not getting the job, although there is a good chance that punk employer just wanted free labor. Grrrr...

What is the best way to interview a developer? I don't like syntax or data structure questions, or questions where you ask them to code something, because those are boring. Asking questions about moving Mt Fuji are fun, but pretty pointless. Chances are they didn't use the exact technology for the exact purpose you need them for, and even if they did, well, your environment and requirements will likely change, possibly even by the time they start working, so it isn't too helpful for them to know the finer details of some library or application.

For me, even if the candidate won't work out, I at least want to get something out of the interview for myself, so all my questions are going to be related having them teach me something. Jeff Atwood advocated this in his article On Interviewing Programmers back in 2005. I ask them what projects they worked on in the past and what role they played. Ask them what the biggest challenges were or what was something about the technology that they hated or was unexpected, and how they worked around it. For example, if you've ever tried to do something low-level with Java or tried to parse a binary format with it, you found out that Java has no unsigned bytes and you cried when you realized the only solution is to cast all the bytes into int's. If there isn't something you hate about some technology, you are not that deeply involved with it. It's like the old saying from political activists "If you're not pissed off, you're not paying attention". Ted Dziuba advocates this in his blog post How I Spot Valuable Engineers from 2009.

I want the candidate to tell me what blogs they read and what technical books they've liked so I can ensure they actually care about their craft outside of work, and maybe they'll end up making me a good recommendation.

I haven't tried this yet, but I'm also interested in what they configure on their boxes. First thing I do when I have to use Outlook on a job is turn off that horrible feature that does new message pop-up notification above the toolbar. Ted Dziuba complained about a similar feature in Ubuntu (Disable The Annoying Thing In Ubuntu Jaunty). When I install winmerge I immediately have to change the font to size 8 instead of 12. Different tools will require different adjustments but again I think this shows how much people care about their craft because it shows how much they care about the tools they use. A good carpenter knows not only the right tool to use, but also keeps his tools sharp and the way he likes them.

(Note to my current employer, don't worry, I'm not actively interviewing right now, just had this on my mind).