By no means will I say I’m an expert at doing interviews.  I’ve certainly screwed up my fair share (both giving and receiving).  However, through all of those mistakes, I’ve learned a few core principles that have helped me with selecting qualified people.

1.  Go with your instincts

This is number one, for what should be obvious reasons.  Most of the time your first impressions of a candidate are fairly accurate, insofar as how they will approach  the job, interact with other developers, and generally contribute to the workplace.  I left out engineering skill in the previous list as I think that may not necessarily be as clear really quickly.  A lot of a candidates technical performance during an interview depends on the interviewer, but more on that in a minute.

Certain qualities of a candidate reveal themselves almost immediately.  Things like how they are dressed, how they handle the pressure of the situation (and whether they feel any or not), and whether they are a developer for the love of developing, or just kind of “fell into it”.  I think you can probably guess what I find to be the better candidate.  Dress reflects the persons opinion of what is acceptable at a work place.  At the very least, they should be showered and wearing clean clothes.  Does it mean they are not a good developer if they don’t?  No, they could be brilliant…. and require a cube in the basement (without the red stapler).  I also have found that candidates that are not at least somewhat nervous, tend to not care about doing a good job.  This is a small generalization, but those who are a bit nervous want the job more, they’ll work harder (because they appreciate the opportunity), and they will tend to grow faster because they don’t assume they know everything (which is why they are nervous).  This dove-tails nicely into the motivation behind being a developer.  The best developers I know are those who are so passionate about the web that they would be building their own apps at home if they had a different job.  They tend to be early adopters of stuff and know what “lolcatz” are… (next thing to ask is whether they find them funny or irritating, or the hidden third option of claiming they thought of it first).

2.  Ask useful questions

Sometimes during a technical interview it is easy to fall into the trap of wanting to ask  screw-you-over-because-I’m-smarter-than-you questions.  I won’t lie, I’ve done it before.  You might as well just thank the person for coming in, give him a wedgie, and push him out the door…because at that point the interview is over.  Even if they do well, your need to insure they are lower on the pecking order than you already shows your inability to work with other people (and probably relates to your pent up rage at the jocks from high school, college, possibly even preschool).

Often the need to ask those kinds of questions is disguised as a belief that you are probing them to find out the depths of their knowledge.  It’s not.  If you want to probe their knowledge, start with bite-sized questions that gradually get harder, and build on a scenario.  Get them talking, not sweating, you’ll learn more about how they approach problems (the really valuable part of the interview), and you can more easily simulate a team approach (which is what it’d be like anyway… unless you regularly tell your coworkers, “oh you don’t know that?  well, thank you for coming in. Have a good afternoon.”)

3.  Ask technical questions with multiple possible solutions

More often than not, I see on many companies’  sites in the job sections, fun brain-teasers.  Microsoft is famous for this (the man-hole cover question… the term “man-hole” should really be changed).  I find many of these puzzles fun, but not very helpful in determining qualifications.  Often the puzzles entail some kind of trick or specific approach to get the right answer.  People argue that watching how someone approaches these problems reveal how they will develop software.  I don’t think so.  I think they tend to cause more stress, because the questions are out of the scope of what they are normally asked to think about.  On a daily basis the developer is going to spelunking into other peoples’ code, designing classes, creating db schema’s, and so on… they aren’t going to be asked to apply their mental framework for graph theory to determine the shortest path between here and Tokyo, given the westerly winds, and recent global temperature vectors.  Seriously, ask relevant questions.

Ok, so now I’m off my soap box on what not to ask… here is what you should ask.  Solvable, bite-sized, problems with many possible answers (some of which you do know).  Here are some examples:

• Take the string “I can has Cheezburger?” and reverse it (except punctuation) to say: “Cheezburger has can I?” (use any language. Try without built in functions like string tokenizers, etc.)
• Write a regular expression to parse 3 common phone number formats. (Assuming US phone number)
• Implement a basic session storage component.

Each of those questions has a world of possible follow-up questions which can add to the difficulty.  The key thing is to not spew your wad up front.  Don’t give them a stumper questions right away, start them into the problem with something they can wrap their minds around.  Then add to it.  This will yield a positive response, create at atmosphere of solid thinking, and really test their ability to contribute to the team.

4.  Don’t be a jerk

I covered some of this earlier, but I wanted to focus on this specific point.  You don’t encourage quality people to join your team by being a jackass. Your goal should be to interact with them on somewhat of the level of a coworker (or boss).  You are trying to get a sampling of what they would be like to work with.  So friendly conversation is fine.  Joking (appropriately) is fine.  Remember, besides relying on them for their work, you will be exposed to them for large portions of your forseeable life.  Personalities matter, including yours.  If they don’t know an answer, move on.  Don’t make the jackass comments like “oh, really? wow… um ok…”.  They may still be a good candidate.  They may have panicked, despite knowing the answer because their mind was still on the last problem, etc.  Everyone (yes, even you) couldn’t recall something when put under pressure.

5.  Let them shine

People like to talk about themselves, and this is often very revealing.  Ask the candidate to talk about their experience, what excites them, etc.  This will give you lots of chances to ask insightful stuff like, “so what did you do after you burned down the building?”.  Seriously, though, it will allow you to probe them on the “fuzzy stuff” like how they like to work, what environments suit them the best, etc.  Since you’ve been working for a while at your current location, this information can help you determine whether the environment at your workplace is close to the one that cause them to set fire to the building, or not.

Conclusion

You will hire crappy people if you don’t follow at least those 5 steps I’ve listed.  You can add to the list, but if you subtract, you will regret it.  Why?  Because I’ve seen it happen.  Many times.  The worst thing in the world is to work with, work for, or have working for you, someone who is unqualified (but really cool, so you feel bad when their enlarged-foreheaded ass can’t figure out how to normalize the damn db).  Almost as bad is to work with the know-it-all jackass who delights in pointing out that increments should be done as a ++i rather than an i++ as it translates to a slightly more efficient block of code when compiled (as they smack you with their mental salami-like-dong in front of the hot coworker that doesn’t know you have a girl-friend).

Valuable experiences to avoid my friends.