I love to interview people. Honestly, I do. Some might say I enjoy giving interviews a little *too* much, but I can’t help it. There’s just something about trying to determine what a developer knows and doesn’t know that gives me satisfaction. Over the years I’ve interviewed (what seems like) countless developers and think I have a pretty good handle on the art of interviewing, so I thought I’d share my thoughts.

First and foremost, I’ve named this post the “art” of interviewing because there are no hard and fast rules about what makes a successful candidate. What I think is a good candidate for me might not be the right fit for you and your situation. Interviewing is not science and is not black-and-white. Many grey areas exist in the realm of interviews, so with that, here’s a few things I’ve learned over the years.

Hire People Smarter Than You

Yes, you read that correctly. If you want to take your team to the next level, hire people who are smarter than you. I understand this might seem counterintuitive, and a bit of an ego-buster, but I firmly believe it. I say this because one of the best ways of learning and improving is working with people who are smarter than you. It’s as simple as that. If you’re committed to constantly learning and improving (and you better be), then hiring developers who are smarter than you will keep you on that path. And nothing but good things can come from that.

Your Next Hire Should Raise the Bar

This goes hand-in-hand with hiring people who are smarter than you, and is something you have to be diligent about. As you’re interviewing someone, you must constantly ask yourself “What does this person bring to the table that we don’t already have?”. If the answer is “nothing” by the time the interview is over, you might want to pass on that person. The reason is that if the person doesn’t bring anything new to the table, then that person doesn’t standout in any way from anyone else.

I firmly believe that each developer on your team should bring something different to the table. It could be a skill specialization, such as someone who’s really good at ASP.NET or SQL. Or it could be someone with certain design skills, like maybe they have a knack for usability. Whatever it is doesn’t necessarily matter. What matters is that they contribute something from a different angle, and you must treat your interview candidates the same way.

I’ve said no to developers based on the simple fact that they didn’t bring anything to the table that we didn’t already have; in essence, they weren’t going to raise the bar, and for us, that’s not good enough.

Don’t Settle

This should be pretty obvious given what I just said about only taking people who raise the bar, but it’s unbelievable how many companies mess this up. It’s all too common for companies to hire developers simply because they need bodies. If you find yourself doing that, you’re doing it wrong. And not only are you doing it wrong, you probably *know* you’re doing it wrong. So stop it.

Do not settle for a developer just because you’re getting pressure from management to fill a position. Fight the urge, and fight it hard. There’s nothing more crippling to a team than hiring someone you settled for only to find out that person is a dud. Because now what do you do? Do you fire that person? Do you move them to another team? How do you get rid of them? All kinds of difficult questions come up in those situations, so save yourself and your company a lot of trouble and don’t settle. It might take you quite a while to find the person you’re looking for, but believe me, it’s worth it.

Do It Only When Needed

When interviewing someone, make sure you actually have a position to fill. That seems pretty straightforward, but I’ve been in situations where I’ve interviewed people only to find out the position was closed or was never open in the first place.

This is a complete time-waster not only for you, but for the candidate as well. Interviewing is a time-consuming process by nature, so don’t waste it by interviewing for phantom positions. Not only that, but having candidates find out they interviewed for something that might not be true makes you and your company look really bad, and they will think twice about talking to you the next time around.

Find the Breaking Point

During the course of an interview I try to find the person’s “breaking point”. By that I mean the point where they just can’t handle a certain line of questioning anymore. For example, I’ve been known to pepper developers with questions about garbage collection just to see how far they can carry on before saying “I don’t know”. I don’t do it in an attacking way or anything like that, but as they answer a question, I ask a follow up question based on their previous answer, and as they answer that question I ask another follow up question based on that answer, and so on and so on until we can’t go any further.

This is actually a tactic I use to see how well a candidate handles a little pressure. The thought is that if the developer struggles under pressure in an interview with questions they’re supposed to be able to answer, will they also struggle as a deadline nears and the team is under the gun to deliver? Of course the two situations don’t map 1-1, but it’s an interesting indicator to see where someone’s breaking point is.

And I can tell you this: the best developers I’ve interviewed remained cool under pressure, even when they didn’t know the answer to something. The candidates who I doubted were those that were easily flustered and "broke” quickly.

The Best Interviews Are Conversations

When you interview someone, do you simply go down a list of prepared questions and fire away? Does that feel robotic to you? It does to me, so I don’t take that approach. Sure I have a list of questions, but I only keep them around as a reminder, and as it turns out, I don’t actually refer to them too often over the course of an interview.

What I do is ask the first question and then every question after that is based on the answer to the previous question. I’ve gotten very good at picking out the key points for a given answer, and then asking other questions based on that. This allows me to deliver the interview as more of a conversation instead of a standard Q&A session.

This has a couple benefits. For one, the candidate tends to be more at ease, and when a candidate is at ease, I get more out of them. Another benefit is that a conversation can lead anywhere whereas a “question script” only leads you to the next question on the list. Part of interviewing is to really get a feel for if you could work with the candidate, and for me, a technical conversation between two technical people is a great indicator. This is important because that’s how problems get solved and designs get created. You don’t go through a canned list of questions. You get people on your team together and you talk it out.

In my experience, the best interviews were also the best conversations. Keep that in mind.

Avoid Trivia Questions

This is a big pet peeve of mine, but unfortunately, many people still do it. By trivia questions I mean things like “Is sorting turned on by default in the GridView control?” or “What’s the maximum number of AppDomains that can be loaded into a single .NET process?”. Try to stay away from these types of questions. They only support the fact that you’re probably trying to prove how smart you are, and besides, these are things easily found with some quick Google searches.

You need to find out how a person thinks and solves problems, and these types of questions don’t do that. The only thing these types of questions do is show that the candidate has a good memory of inane facts.

Your Gut Is Almost Always Right

This is something that took me a long time to learn. In my early interviewing days, I would base my decision on whether or not the person correctly answered my questions and never gave it much more thought. But as time went on I realized it’s not just about getting the questions answered correctly. There were little things I would pick up on, such as tone of voice, hesitancy, really short answers, or always asking me to repeat the question. Luckily for me, most of those early interviews worked out, so I didn’t get burned too bad, but it might have been more luck than anything else. I never really paid much attention to my gut, but now is different.

Let me give you an example. In my consulting days I lead a project where I had final say on who joined the team and who didn’t. Needless to say, I did most of the interviewing and at one point interviewed a very senior technical architect for another lead position on our team. I threw every .NET interview question I had at him (and then some) and this guy answered every single one of them without pause. I couldn’t find his breaking point on anything.

Somewhere in the interview I asked him about garbage collection and he went into the bowels of it really well. At one point he was talking and said “blah blah blah freachable queue blah blah blah”. As he was explaining this it was very apparent he was pretty cocky. There’s a fine line between confidence and cockiness and he was clearly way past the line. So I let him finish and I could tell he was sitting there thinking, “I just blew this guy’s mind”. Well, being the person I am, I said “You mentioned the freachable queue, let’s talk about that a bit more”.

And there was stunned silence. You see, he threw out the term “freachable queue” thinking there was no way that I would 1) know what he was talking about and 2) call him out on it. To his credit, he recovered well and we had a lovely chat about freachable queues, but by that time I had mostly made up my mind that I couldn’t hire this guy. Every technical bone in my body said it was a grand slam, but my gut told me otherwise. I just couldn’t risk bringing a guy like that onboard and wrecking the great chemistry we had as as team. It would have been catastrophic, so much to his dismay, I said no.

And I have more stories like that. The point is to pay close attention to what you’re gut is telling you because it’s almost always right.

Wrapping Up

I know this post was a bit lengthy, but it’s critically important to get right. Recovering from a bad hire can be hard, time-consuming, and expensive. As the saying goes “one bad apple spoils the whole bunch”, and that’s ever so true on software development teams. So to recap, here’s the key points:

• Hire people smarter than you
• Your next hire should raise the bar
• Don’t settle
• Do it only when needed
• Find the breaking point
• The best interviews are conversations
• Avoid trivia questions
• Your gut is almost always right

Similar Posts

1. TechEd 2005 Recap
2. Decreasing Developer Ramp Up Time
3. Clarity