For interviews, how do you gauge whether the candidate would be a good coworker?

Question

As has been often stressed, people skills count for a lot in software development. While it's great to have smart and skilled coworkers, someone who communicates well and has the technical chops to contribute is invaluable to a project.

How do you gauge whether a candidate would be great to work with?

For me:

1) I look at how they explain their answers. Do they identify hidden assumptions as they answer their questions? Do they explain step-by-step how they get from their premises to the conclusions they want to draw? Are they humble enough to admit when there's more than one way to do it?

2) Direct questions that may be revealing about people skills. What was the most serious non-technical challenge have you addressed and how? Describe your dream job. If you had to pick a team for a feature set, how would you pick your team?

Answer 1

I try to gauge their passion. I ask questions that see if they read technical blogs ask the questions that see if they are willing to work late and are deadline driven. It's easier to work with someone that has passion and might be lacking it the exact technical skills then someone with no passion and who doesn't want to work.

Answer 2

For me, most important always were two things:

1) How they explain things? If I could, I tried to ask them about something they did in the past and I had little idea about. If they can make me know more in a few minutes, they can probably contribute a lot to the team with their unique skills. I know it's more like a teaching then programming, but even a smartest coworker who can't really explain what he's doing, and why it's better his way, is much less worth.

2) Can they argue? If I (or anyone else) tell something wrong, will they catch it and tell me, hey, you're wrong here and here, or just skip it, smile, and think deep inside that I'm an idiot...

I also like to ask how would they organize their desks. Don't know why I ask this...

Edit: Sometimes I'd just ask a candidate to sit be me and take a short look at my code (if it's allowed, not top-secret, etc). Just looking how one operates, what he finds important, tells a lot. But, I'm quite used to working in pairs.

Answer 3

While I don't have a hard set of rules that someone must match, here's a general list:

• Do they communicate well?
• Are they enthusiastic?
• Are they positive, or do the trash their former managers and co-workers?
• Do they seem honest about their abilities, or do they pretend to know everything?
• Can they clearly explain something technical that they've worked on before and give me a good idea about the project?
• Does it seem like they prepared for the interview by learning about my company?

I also think it's important to have as many people that are available meet the candidate and make sure everyone gets along, not just the group lead.

Answer 4

"I also like to ask how would they organize their desks. Don't know why I ask this..."

Wow, I thought I was the only one.

I think a lot of what I do is managing complexity. Part of that includes keeping my workspace clutter free and well organized.

I honestly believe that building effective solutions and management of technical tasks requires at least basic organization.

I also believe those who sleep normal hours to accommodate a normal business schedule (8AM - 5PM) are more likely to be reliable and organized. I've met people who roll in very late in the morning (10:30ish to 11AM) whom have always been characterized by everyone else as "lacking" or below some satisfactorily measure.

Answer 5

1. I ask questions that try to show me their prejudices and superstitions.

   • I know a guy that won't use "&>" in bash scripts.
   • I also know a guy that bases his language opinions(python, pascal, so on) primarily based on what other people told him, or who he knows that uses that language.

The first guy admits he doesn't use it because he doesn't understand it. I would hire him.

The second guy, I would not. From that statement I can be pretty sure he's not a good hire.

1. I also ask questions where they can say I don't know. If they fail to admit they don't know something I don't want them.

This is easy to do since they give you a resume first.

Answer 6

A lot of what makes a good co-worker is not about their technical skills and the technical will be covered by other answers, so here is my human angle...

Get them talking about their family and home and interests and general life a bit, in a non-intrusive way. Relate to them as a person and use your instincts about them from that standpoint. If you met them at a party, or through a friend instead of in an interview what would you talk about, what would you find interesting in them, how would you feel about them? Spend a few minutes at one or other end of the interview doing the human bit.

I think that the inter-personal stuff is the hardest and at the end of the day you won't really know what they are like until you actually work alongsde them. One thing's for sure though, if you like them as a person you are more likely to embed them in your working world successfully.

Answer 7

I was the "fit" interviewer at several companies and my primary goal was to assess how well the candidate would "fit" in the organization. I firmly believe that this is the most important thing to get right. I might be able to teach you, say, c++ but I probably can't teach you not to be a horse's backside or a know-it-all or a person who doesn't take criticism well.

I'm not sure there are 'magic' questions you can ask to get the answer. I could ask "tell me about a time you had to deal with a difficult problem" or "if you had to deal with a difficult co-worker, how would you do id?" but I'd likely get monkey-business, canned responses from the candidate much of the time.

Instead, I'd get them to talk. The goal is, I think, to shut up and let the candidate talk. My boss would often sit in the interview and blabber on about this and that - a big mistake in my book - and the candidate could just be polite and they'd like them. I tend to get them to talk about things on the resume, things they mentioned in response to questions, and perhaps talk about the work environment they have been in.

Example - if I wanted to see how they interacted with others, I'd ask them to describe the team environment (working conditions, desk space, were you in cubes or separate offices or just desks in a room. What did they like/dislike about those arrangements. I don't really care about the specifics of where they worked - I'm not going to be interviewing at their place - I'm really wanting them to get out of the 'interview mode' they are surely in where everything is formal and the shirt is pressed and the candidate is wearing a mask. If I can get them to forget that they are trying to get a job at my place and just be open, by getting them to chit-chat with me rather than tell me the answer to "where do you see yourself in X years", I think I can figure them out pretty well.

I think it takes certain type of person to be the 'fit' interviewer - I'm a reasonably good one because I'll let them talk but I don't come across as the stiff, formal company guy. At the end of the interview, if I haven't been able to get them to 'be real' for me, then I have to think long and hard about the candidate. I might even call them back for a second interview to ask some more questions, but I'm really looking to see how their personality is. Sure, I'm interested in if they have a background in some technology, but the goal of the 'fit' interviewer is to assess, in my opinion, whether the candidate is the kind of person I can trust and work with 40+ hours a week.

I'll also ask lots of questions of his references to get them to open up about him. This is hit-or-miss, but at least I'll try.

Just my two cents.

Answer 8

In todays world the programmers are so closely connected, And most programming task are already solved or tons of best practices out there to get inspirations. Nobody needs to re-invent the wheels from scratch again in most of the cases.

So I really would check if the candidate is closely connected to his peer programmers community and

• Willing to learn new tricks and tips and updating himself**
• Willing to share or contributing to the community **

Answer 9

I try to describe a piece of the thing we'll actually be working on -- to the extent that it's relevant in an interview -- and let them run with it.

[As a consultant, I've been on hundreds of job interviews over 30 years. Many of my clients are perfectly rotten interviewers. We spend an hour where they talk for 50 minutes and ask me if I can help. Duh. Of course I can help. But can I help in ways they'll appreciate? They'll never know until they shut up and listen more.]

I like to treat interviews as "free consulting" or a "peer review" kind of meeting. Since we'll be working together, then... well... let's actually work together for a few minutes on some specific task.

That work-together moment is it. If it clicks, they're going to work out. If they prevaricate or backtrack or waffle or otherwise behave badly, then it may not work out.

Answer 10

You have to use heuristics. Basically the two sides of the interviewer/interviewee encounter both suffer from asymmetrical information. Candidate could be a dud, job/company could be a dud.

"Do you have a sense of humor?" Mention something a little racy (like politics) and see how they react. I think it's easier to work with someone possessing a sense of humor.

Find some way to assess their general level of "geekiness." Could be through car talk, latest Apple device, Chrome browser, etc., whatever opportunity presents in the conversation.

Answer 11

I have been doing a lot of interviews and hired several of my co-workers. The things I am looking for are: Basic technical knowledge, humor and communication skills.

We never expect to find someone who are experts, and always plans with a long period of both internal and external training. But the basic knowledge has to be there. Since knowledge of network protocols are important to us, we almost always as the candidate to explain a three way handshake, the difference between TCP and UDP and what protocols are involved in a HTTP GET request (all the layers). They don't have to give a 100% correct answer, but they have to show us that they know the basics.

Humor is important. The work environment can be both stressful and frustrating at times, so being able to relax and have fun is important. Nothing is gained by running around waving their hands in the air while screaming. :) One question we used to use a while back was: "Unfortunately there are not many girls working for us... are you willing to change sex?". The reaction reveal if their sense of humor is compatible with ours. :)

We also pay close attention to how they communicate with us (in our native language) and we always do a part of the interview in english.

From time to time we also do a "stress test". That is, we give them a scenario and ask what they would do in that situation. Depending on the answer(s) we add information that indirectly indicate that their response was wrong. Their answers here are less important than their reaction: Do they stick to their original answer even when it seems to be wrong, do they try to get more information about the scenario or the worst kind: Do they start arguing?

We try to avoid question that could be easily googled, like details about parameters to programming functions or command line commands. If they need it, they can google it. Or ask a co-worker. :)

So far, we have a great working environment with enthusiastic and self-going people... and we have a lot of fun.