Adventures in HttpContext All the stuff after 'Hello, World'

How to Hire a Software Developer: The In House Interview (Part Two)

_Note: This is part of a series on hiring software developers.  See articles tagged with interview for the series.  The in house interview post has two parts.  This part focuses on non-development questions._

Key Concepts

  1. Present yourself well- the candidate is checking you out too.
  2. Prefer a group style interview approach over one-on-ones.
  3. Ask specific non-development questions and evlove the follow ups.

They’re Interviewing You Too

It’s important to note that you- both as a company, a potential co-worker, or a future boss- are being interviewed too.  A smart candidate (read: one you want to hire) will be sizing up the situation and the interview process themselves.  What’s the office like?  Do people know what’s going on?  Where is the interview going to happen? Am I, the candidate, waiting around a lot for something to happen, or someone to do something? How fluid is the entire process?  Are people droning on at their desks or do they look happy?

What goes on during the interview will give the developer hints as to what to expect during the day to day of the job. If the office is awesome, the people are cool, and things are moving smoothly, a much better impression will be made on the candidate than a sloppy process where people are totally frazzled, have no interest in what’s going on, or are treated/act like sheep.

Bottom line: be respectful.  Present yourself- and your company- as the epitome of who you’re expecting to hire.  Joel Spolsky, of Joel on Software, puts great effort into making his office and company a kick-ass place.  Even his blog makes you sit at your desk wishing you worked at Fog Creek.  Hell, the New York Times even wrote an article on the office architecture!  Don’t be afraid to sell yourself.

The Interviewers

It’s important to have the candidate meet with a variety of team members.  This shouldn’t be considered a chore for people, but an honor.  It’s important when building a cohesive team to give current members a voice as to who’s joining the team.  Most people have no idea how to interview- so make sure to give current members specific questions, role playing scenarios or guidelines on how to conduct the interview.  Make sure meetings are timed box- to between 5 to 20 minutes- so the interviewer knows the correct pace.  There’s nothing worse than awkward silence.

The Interview Structure

There are essentially two ways to structure the interview: a series of one on one interviews where different developers ask a distinct set of questions, or a group style interview where a group of developers have a round table discussion with a candidate.  The way you decide to structure the interview says a lot about your company and how you conduct your development (that whole thing about presenting yourself).

Personally, I don’t like the one-on-one style.  It’s pretty exhaustive, both for you and the candidate.  The candidate is constantly bombarded with questions in an interrogation-like manner.  If the questions aren’t planned ahead of time people will also ask the same set of questions (Um,  so, why are you leaving your job? Why do you want to work here?).  More importantly, it’s hard for the candidate to get into a rhythm- the mandatory warm up time, body, and wrap up is just too cramped.  Finally, the one on one approach offers poor breadth of a candidate.  If each person is only focusing on a specific set of questions, no one person can see the big picture.

A roundtable discussion is a much better approach, even if there are only two interviewers.  This is much more representative of an agile development team- you want to see how the group dynamic plays with a new person.  It also gives every person an opportunity to determine breadth- you see the whole package, and not just individual parts.  The conversation has a much better chance to evolve in a solid discussion- the positive attributes of each interviewer can shine while the negative attributes are mitigated by the group.

The one advantage to the one-on-one style is you can interview more people easily.  It’s just math- let’s say you’re interviewing four candidates with four developers.  An interview should last about two hours.  That’s eight hours using all four developers!  On the other hand, if each developer spent 30 minutes with each candidate concurrently, that’s only four hours total- half the time!

Personal/Non-Technical Questions

It’s important to ask non-development questions.  You want to get a sense of how well rounded a candidate is and what their personality is like.  Here are some example questions:

How do you stay on top of technology?

I’m looking to know what their go-to resources are for learning and keeping up with stuff.  Google is not a good answer.  Do they read blogs? What are their favorite books? Have they been to any conferences?  Subscribe to any magazines?  What can they bring to the table?

What personal program projects have you worked on, if any?

I’m interested to know if they have any programming experience outside of work.  Not too bad if they don’t, but it shows how into programming they are.

What is the coolest thing you’ve done with technology? What are you proud of?

One of my favorites.  It’s important to hire people who are proud of what they do.  You can’t beat someone who’s about personal responsibility.

What are some websites you’ve used where you appreciate the design of the site? Why?

An analytical question.  Developers with design insight are rare.  A developer who shows appreciation for good design, or can “talk” design, is invaluable.

What do you want to be doing in a couple of years? What is one area where you want to be developing your skill set?

I used to hate asking this question because its so cookie cutter.  But it’s important to ask and to have the candidate elaborate on.  It does two things- let you know how driven the candidate is, and what they’re interested in doing and evolving.  Both important things to know.  A good follow up is “How are you going to do that?”

Describe how you would handle a situation if you were required to finish multiple tasks by the end of the day, and there was no conceivable way that you could finish them.

Answer: Prioritize.

If you could get rid of any one of the US states, which one would you get rid of, and why?

Answer: Canada.  Just kidding.  This one’s good to change pace of the conversation if needed.  Ask if the candidate completely failed another question or is feeling insecure.  It can help them get on track.  It’s one of those silly filler questions that’s good at wasting time if you need too or changing the mood.

With your eyes closed, tell me step-by-step how to tie my shoes.

If selected for this position, can you describe your strategy for the first 90 days?

You may not need this if you’re doing role-playing development questions, but it’s a good question to gauge how well a candidate can explain something.

Describe a criticism you were given at a job and how you worked to improve it.

This is another good question to ask.  Most people don’t respond well to criticism, or aren’t that self critical.  You don’t want someone to be cocky nor beat themselves up.  But there are times when people do things they shouldn’t or simply make mistakes.  Being self-aware and improving on weaknesses is one of the best qualities a person can have.