How can I help a "meet the team" interview to succeed?

Question

We are looking for a third developer. I have reviewed the applications, conducted initial on-site interviews with the most interesting applicants (classic interview questions, FizzBuzz etc.) and, thus, finally reduced the number of potential candidates to two.

Now I want to reduce the risk of the new developer not getting along with the team (i.e. the two existing developers). To do that, I'd like to invite the remaining candidates (separately) to meet with the team, have a chat, and find out if there are any problems on a personal level.

As soon as I propose that to the team, the question "What are we supposed to talk about with him/her?" will come up, and I need a good answer. I don't want the interview to become awkward to either the candidate or the team.

My initial ideas were:

• "Ask technical interview questions." Not applicable, since this is a junior position, both candidates would need to learn the technologies we are using, and (I think) I already verified in the first interview that they are smart and able to think logically (as far as this is possible in a single interview).

• "Ask personality interview question." They are developers, not psychologists or trained HR people.

• "Just do some small talk." They are developers. I cannot expect them to just improvise some small talk with an unknown person for an hour without feeling bored or thinking about the work they'd much rather get done in that time.

• "Work on some real problem together." Introduction to our development tools or a specific problem domain would probably take a lot of time.

Any other ideas? Any experience with what works/what doesn't? As stated above, the primary goal is to make sure that they will be able to work together on a personal level.

(In case it's relevant: The duties will be classic "coding" (new features as well as maintenance of legacy code), customer support, and, after some experience has been gained, customer requirement analysis and software design.)

Answer 1

Invite them out to lunch. Do this as part of your interview process.

It's an easy, "how well will we get along" setting and this sort of thing is really important for teambuilding/socializing anyways. Also breaks the awkward "wall of interview" problem which can cause people to burn out. And everyone needs to eat, right?

Just make sure you don't make your team (or the interviewee) pay.

Answer 2

We do that with every engineering hire at our company. Letting them spend a day at the office is more of a cultural and team fit gauge.

So, this is what we do with a new engineering hire:

Give them a sample problem, one of a similar type which we work on every day; and ask him to solve it along with the team.

The problem should be such that it should be completed in a day and for doing the same, the person needs to interact with their team members (or the existing employees in the team).

So, in this way, the would know both the engineering culture and also have a nice interaction with their prospective team members; and help them in knowing each other.

For example: This is one problem which I give someone who is interviewing to join the data science team:

Can you design a model where you can identify and predict the most buggy repos of our codebase?

Bonus for someone who can identify and also give a nice solution for how to understand and maximize the quality of the model

Answer 3

As enderland said, take them out to lunch. And what should you talk about while out to lunch? One approach we use with junior candidates is to get them talking about an interesting internship or class. This isn't a technical screen; we don't really care about those details at this stage of the process. What we want is a topic of conversation that everybody can relate to somehow. Talking about past projects or internships lets you bypass the "feels like an interview" phase to get to what it's like to work (intern) at Google or what the candidate learned on the team project for compiler design or...whatever you end up talking about. Your team members should share their experiences too; it's not an interview and shouldn't be a one-way conversation.

Talking about past projects/internships/classes usually works better than talking about hobbies; in my experience it's a little harder to sustain a conversation about knitting or football or the like. But if somebody brings up something that catches the group's interest -- if the candidate goes skydiving every weekend and people are curious about that, or the people at the table happen to all like talking about Doctor Who -- that's fine too. The point is to have something that people can talk about for long enough to get past the awkward "new people" jitters.

For senior candidates I've sometimes seen companies pull the person into an actual design discussion -- a problem we're trying to solve now for real, not a simplified test question. Design works better than code from what I've seen because (a) you already had the candidate write code earlier in the interview anyway and (b) design on a whiteboard bypasses the logistics of tools and environment. In my experience it's also more interactive. Pick something that you can explain well enough to somebody just coming in and that doesn't have a lot of hidden interactions that are specific to your product, and then work on it together. (Members of your team should come with some starting ideas; jump into a design problem, but don't start with an empty whiteboard.)