March 5, 2008

Are three-stage interviews possible?

Posted in Software tagged , , at 9:29 pm by mj

I’ve been thinking about interviews lately. At my new job, I hope to be able to build a team, and I’ve been asking myself how to improve on past experience.

I’ve always been a bit uneasy asking basic coding questions. A colleague of mine asks basic coding questions simply to weed out so-called “architects” and “team leads” who haven’t done any actual coding in a long time. In that respect, they’re fair questions. And, amazingly enough, they do weed out a number of so-called senior programmers. (How is that possible?)

But even perfectly reasonable answers can be held against the candidate, because then the interviewer (and his colleagues in the ensuing post-interview discussion) get to dissect every last bit.

“Well, that part there, it isn’t so well optimized…”

“He hesitated a bit too long, like he had to think about it, but it’s a basic part of the language…”


Pretty much the only way to knock the socks off an interviewer with a basic coding question is if you’ve heard and answered the question before. Which is cheating, isn’t it? (When I interview, if I’ve answered a question before, I feel inclined to say so.)

And as an interviewer, that makes me uncomfortable. I want to know what you’re capable of and imagine how you’ll fit into and enhance my team. So you might not have a lot of experience with language X. But do you know how to optimize SQL? Have you studied the great resources available on building large-scale web sites? Can you learn new material quickly and present it to your team in a way that everybody groks?

So, here’s what I’ve been contemplating. It’s a three-stage interview. Well, maybe four stages, depending how you look at it
Stage 0. At the end of the phone interview when the decision has been made to bring a candidate in, they’re asked to learn a new technology. I’m imagining giving the candidate a choice of two or three fairly complex things. For example, how does Java’s ConcurrentHashMap work? How does Lucene answer queries? Etc.

Stage 1. Day of interview. The first thirty minutes to an hour, the candidate presents this new technology to the whole team, and answers questions. This gives the candidate a chance to shine and build confidence before being grilled. It breaks the ice. (If the presentation doesn’t go so well, the interview is over.)

Stage 2. Day of interview. Normal interview rules apply.

Stage 3. After the interview, the candidate is asked to consider his answers during the interview, and given a couple of days to improve on a coding or design question by e-mailing the hiring manager with an improved, or even totally new, solution.

What I like about this:

  1. Learning new things is one of the most important parts of any gig, and yet it’s absent from 99.99% of interviews.
  2. Team members should give frequent presentations to each other. This gives the candidate a chance to be just another team member doing what team mates do.
  3. Rarely is a programmer satisfied with their first solution to a problem, particularly if they were rushed. Yet candidates almost never get a chance to show how they go about revising their solutions.
  4. The structure and pacing of the “real interview” part of the interview need not change. Nobody needs to rethink their standard questions.
  5. By giving the candidate more chances to shine, the whole team is more likely to give an enthusiastic up or down. Rarely will you still have a bunch of “maybe”s (which, by default, should be no–but who feels good about that?).
  6. Worst case, you waste forty-five minutes of everybody’s time in a useless presentation that imparted no knowledge. Like that never happens during the normal course of a week anyway.
  7. Once the ice is broken and the candidate has built some confidence, he’ll probably give better answers the rest of the interview. Which means: you’re free to scrutinize his answers more thoroughly.

What do you think?


1 Comment »

  1. Case Larsen said,

    Interesting idea. I wonder if the ‘learn a new technology and do a 45 minute presentation’ may be too big of a hurdle to ask the candidate to jump through?

    Maybe it would work for a Google where they have enough candidate flow to apply one more filter to weed out candidates. But what about a smaller company where you might be needing to sell them on the company as much as evaluating them technically. The worst case outcome is that the really good, busy candidate may postpone the interview towards the end of the other interviews they are doing (because it requires investment of their time) and take a job elsewhere before going through the longer process.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: