One of the best ways I’ve found to create high-functioning teams is to interview well. (The other is to create a company & culture that great people voraciously want to join, so that when you find someone terrific, they say “yes.”)
There are four things I want to know about a candidate before I make them an offer:
- Skills: do they have the skills, knowledge, and experience to do the work you need?
- Behavior: will they behave in a way that benefits the team and helps it grow?
- Culture: will they be a good fit for the company’s culture?
- Desire: do they want to be on this team at this company, doing this work?
Most teams develop a reliable way of judging an interviewee’s skills; they might be asked specific questions about tools and languages, and then sit down to solve a real-life problem with other team members. And it’s reasonably easy to gauge someone’s desire by asking straightforward questions. But once you establish that the person has the skills & desire to play the role that you need, how do you determine whether they will be a good fit for behavior & culture? I’m often surprised that people haven’t heard of Behavioral Interviewing, and are mostly interviewing for technical skills, and then just hanging out with the people to see if they’re “nice” or “cool.”
As the former VP of Engineering at Critical Path, I was personally responsible for hiring the first 50 technical people, which included developers, QA, designers, and technical managers. We ended up with a stellar team, and I think part of the credit goes to how we conducted interviews. For the last 5 years, I’ve worked as an executive coach for entrepreneurs, and I often end up helping clients refine their hiring practices. (BSP: You can learn more about my executive coaching practice, or check out my blog at StartupHappiness.com)
Why is it worth it to put this much effort into interviewing? First, firing someone who doesn’t work out is a huge hassle. Having someone who is the wrong fit, or not performing well, frustrates other team members, and takes up the team’s valuable time and emotional energy. Second, a company starts with the cultural DNA of the company founders, and every new hire that’s made can either amplify those values and beliefs, or not. Why not amplify the great parts of your culture with every new hire, if at all possible?
Basic Format of a Behavioral Interview Question
A Behavioral Interview question almost always starts with “Tell me about a time when you…” The goal is to have the interviewee describe a real-life experience that shows how they have behaved in a social situation, especially one where they were had to overcome some sort of difficulty that they might be likely to encounter in your organization.
One of my favorite behavioral interviewing questions is “Tell me about a time when you had an idea that you thought was really great, but other people on your team didn’t agree, and it didn’t end up being implemented.” What I want to learn from this question is how they handle a disagreement in the workplace, and how they roll with not getting their way.
Once I have a sense of the situation, I’ll ask them “Tell me about what you did, and what results you got.” I want to know if they strategized about who to talk to, what methods they used to influence others, if they gathered data first to support their position, and how things unfolded. I’m also listening for whether they talk about others as having valid points of view, or if they disdainfully talk about how stupid or inferior everyone else was. Did they go to anyone else for help, or fly solo? Do they still have respect for the manager in charge, even though things didn’t go their way? (Hint: this tells me if they will still respect ME if I choose to disagree with them someday.)
The second thing I’ll ask is “What did you learn from this, and is there anything you would do differently today in that situation?” Here I’m looking to see if they gained any insight after the fact, and some indication that they are growing and maturing as a team member. I can tell from their answer whether they’re likely to use social experiences at work as opportunities to learn.
How to Develop Behavioral Interview Questions
The best questions are taken from scenarios that actually occur within your organization. Think for a moment about what kinds of things might frustrate your current team (if you don’t know, I’m sure they will be happy to tell you). Those are the things you want to make sure a new hire can roll with. Don’t be afraid to get really specific.
When we were creating huge-scale telco-grade email infrastructure to host millions of email accounts at CPTH, one of my questions was “Tell me about a time when you got paged in the middle of the night to help a team fix an urgent problem on a production server.” By a candidate’s answer, I could tell (a) if they had any actual experience doing this, (b) how they performed when woken in the middle of the night, (c) how they communicated with other members of the team under pressure, (d) how they troubleshoot a problem, (e) what they learned about the system, themselves, and others, and (f) if they put any safeguards in place to prevent that particular thing from happening again. That is a lot of learning from one interview question!
It’s well worth creating some standard questions like this when interviewing for a position, so that you can compare different candidate’s answers. Ideally these questions would be drawn from the job description (ex: “resolve production problems as part of on-call rotation” leads to the question above), and from the team’s own experience. A few candidates reacted very negatively to this question, and at that point their interview was essentially over: I needed people who could survive this uncomfortable situation with flying colors, get the system back on its feet, and do it a relatively cheerful attitude.
This is where “Culture” comes in; we were developing cutting-edge systems at huge scale. Everything was new, and we were moving quickly enough that we could never do enough testing to insure that the system wouldn’t fail. We were just trying to prevent it from failing the same way twice (this sounds cavalier in retrospect, but it’s true; Web 1.0 was the wild west, and we were building the kind of infrastructure for the first time that became the basis of cloud computing today). So someone who was super-disdainful of the fact that the system wasn’t 100% tested wouldn’t survive in our culture, whereas they would probably be welcome at eTrade, who was developing high-volume stock-trading systems.
Behavioral Interviewing keeps out the Assholes
One of the things that behavioral interviewing can really help with is identifying assholes: people who are likely to appear friendly on the surface, but harbor nasty traits like arrogance, backstabbing, not sharing credit for success, always blaming others for failure, and so on. It’s often easy for those kind of people to act nice during an interview, but when you ask them to talk about multiple difficult situations in a row, it’s much harder for them to maintain the veneer of kindness, and some of their more difficult habits start showing through.
Generally no one answers behavioral questions “perfectly”. Work situations are fraught with difficulty and frustration, but what I was looking for is an orientation toward curiosity, problem-solving, kindness, teaching, and learning: those were all things that our culture valued, and that I felt made technical teams very strong. So it’s fine if someone did struggle with not getting their way, or said that they didn’t love waking up in the middle of the night, as long as in the end they were able to pitch in and make it work anyway, and extra points if they did some introspection and learned something about themselves from the experience.
One important thing that I’m guarding against is someone who is still very angry or sad about a difficult situation after the fact, or who can’t stop themselves from complaining about former colleagues during an interview. If they don’t have enough self-control to speak kindly about others during an interview, they certainly won’t speak kindly about their colleagues once you hire them. Engineering culture often has a certain amount of inherent snarkiness, but I developed the ability to tell the difference between funny-snarky and mean-snarky. Funny snarky pokes fun at a difficult situation; it diffuses tension through humor. Mean-snarky is often about a particular person, and is meant to undermine their authority or credibility.
Behavioral Reference Checks
I particularly like asking behavioral interview questions of an interviewee, and then asking the same question when I check references. Then I am more likely to have the corroboration of their boss or peers: “PersonX told me about the time when they had to fix such-and-such production problem in the middle of the night with your team. Tell me about that…” Because I have already talked about this with the candidate, the manager often feels more free to tell it like it really was.”
While I’m on the subject of reference checks, my all-time favorite reference check question of a manager is: “We’re really leaning toward hiring PersonX. As his/her new manager, I want to create the best possible working relationship. Everyone has things that they like, and things that they don’t… Can you tell me what might frustrate PersonX, so that I can avoid that?” By establishing that I am close to hiring, but looking for ways to work better with the person, I’m more likely to get an honest answer, and in fact, I can use that information to help get that relationship off to a good start. Occasionally I learn something here that is a showstopper, or at least that I want to check out with the candidate before I move forward with the hire. I ask candidates the same thing about themselves, earlier, so I can corroborate the two answers. I want a candidate with enough self-knowledge and honesty to tell me what will upset them; someone who has no real answer to this doesn’t know themselves very well.
Hope this helps in finding & keeping great team members! This post originally appeared on the BalancedTeam blog.