How Many People Should You Interview With?

When a software developer — or anyone, really — is looking for a new job, it's expected that you'll talk with the person to whom you report. Your new boss knows what she's looking for in the new hire (including technical skills and "team fit"), and since you're going to report to her she certainly will want to choose someone that'll make her happy. But how many other people should you expect to talk with?

From the job-hunter's viewpoint, this is simply a matter of avoiding exhaustion. Even the thought of talking to five people in a single day of interviews makes me shudder. Plus, it might seem as though your chances of getting the job decrease with every additional person with whom you interview, because everyone will have his own expectations. Who can possibly meet everyone's idea of "the person who'd be perfect for this job"?

I've seen and experienced just about every variation on this theme, from the Hire decision coming after a ten-minute phone interview with the manager to a grueling day in which everyone in the company had to ask a really tough question. Or, too often, a really stupid one.

Over the years, I've come to lean towards the "more interviews are better" side of the issue. From the job-hunter's point of view, every discussion you have with someone who works at the company gives you another opportunity to judge the corporate culture, particularly if you speak with folks at different levels. Your prospective boss might tell you how important it is for developers to grow their skills, for instance, but if you ask three people you'd be working with when they last got developer training you'll find out if the company puts its money where its mouth is. The more people you talk with, and the more questions you ask (rather than answer) the better you can triangulate on the department's goals; is everybody heading in the same direction or do departments have differing priorities?

But I'm a little more interested in the question from the company's point of view... or rather, the point of view of the team who's going to bring on the new developer. As I wrote about several months ago, in

Interviewing Your Next Boss: Putting the Programming Lead on the Hot Seat

, dire and terrible things can happen when the people above the manager have a different idea of what's needed than the people who will report to him. (Read the comments, if you don't believe me.)

But the same rule applies to the people you'll work with. I don't know why "team fit" is so often considered by Management and by HR departments (the same HR departments who dump your résumé because you lack a current tech buzzword or because they didn't accept your expertise gained in an open source project) but they think that team members don't recognize the need for "fit," too. Who do they think will be spending all the time with the new developer?!

A long time ago, I worked for a very small company — it employed 12 people — at which every new hire spoke with everyone on staff, from Carolyn the bookkeeper to the guy who owned the firm. (You didn't formally interview with Sam, the owner's dog, but I can't imagine that anyone who Sam objected to would be offered a position.) Anyone could veto a new hire. Anyone. An explanation wasn't required, though the company culture was such that it'd be expected. The result was that we had an incredibly strong, diverse team of people who truly loved one another, learned from each other, and were immensely productive. (I'm still in touch with half my coworkers, and I live on the other side of the country, now.)

However, one reason I'm even more in favor of "have more interviews, not fewer" is on Agile grounds. If the developer is going to work with people in other departments (whether IT or line-of-business), those users have to be comfortable with her, too. A candidate may be able to speak brilliantly to other programmers, but have terrible listening skills when it comes to learning what the users need. In the real-world scenario that inspired this blog post (a hiring anecdote imparted by a friend), the developer got along fine with the tech staff. But when he interviewed with the project manager, she gave him a thumbs-down; according to the non-technical project manager, the guy didn't understand the business processes required.

What's your experience been? I created a poll so we could judge what "normal" is (I'm sure you're as curious as I am). But I'm sure there's arguments for-and-against the "many interviews" options. Tell me what's worked for you.

You probably should follow me on Twitter. Because, y'know, you just should.

This story, "How Many People Should You Interview With?" was originally published by JavaWorld.


Copyright © 2009 IDG Communications, Inc.