How do we know someone will have a positive impact after we hire them? We don’t, but we try hard to figure it out in advance.
A candidate can excel at every technical question we ask them but still not be the right person for our team (we went through our technical screening process in the first article in this series). They may be overly focused on a single technology and unable, or worse, unwilling to learn another technology better suited to the problem.
They may not take critical feedback. We believe everyone can always improve, a growth mindset is essential. We can’t hire someone who doesn’t learn from their mistakes and won’t consider discussing them.
“Culture Fit”
Many companies try to interview for “culture fit” and the term has earned a justifiably poor reputation. Without proper thought, training and careful execution it can easily become “How similar is this person to me?”
Only hiring people similar to your current team won’t improve how you work and will limit your company’s capability. You’ll have cultural blindspots nobody is aware of. You may find yourself biased in unexpected ways: “This candidate probably wouldn’t enjoy working with a younger team anyway”, “This job is too demanding for someone like this” or “We move too fast to sugarcoat feedback, I don’t think they’re emotionally strong enough to work with us.”
Hearing anything like these from your team is a clear, unambiguous sign your process is broken. Your culture may not be so healthy either. Facebook’s excellent Managing Unconscious Bias is required reading/watching, and not just for the people involved in hiring.
Culture Contribution
If we truly believe in a growth mindset then we expect there are always ways to improve how we work. Each week teams reflect on their own process, discuss what’s working well, what isn’t and what they’ll do to fix it. Something similar happens at every level of our company.
We want to hire people who can contribute to that discussion. Occasional frustration is a healthy part of any satisfying job. You’re moving fast in unexplored territory, there will be upsets, setbacks and mistakes. The right people will respond positively in these situations. Identifying the problem and correcting it, learning from the mistake and making sure nobody else has to learn it the hard way.
A diverse team with different ways of thinking and a wide range of experience to draw from gives us more options when we need a solution. Instead of limiting who we hire based on how close they fit what we already do, we try to hire people who will make positive changes to how we work.
How we interview
Effective technical screeners are designed to be binary in their outcome. Determining how a candidate will improve our culture — or identifying when they won’t — is incredibly difficult with results necessarily spread across a spectrum.
In all interviews you should tell candidates exactly what you’re looking for. This isn’t a quiz show. Candidates shouldn’t need to guess at what’s important. It’s a poor interview if you’re left wondering “did they understand my question or just not have a good answer?” Explaining your values gives a candidate more information about your culture too. It’s an acceptable outcome for them to say “You value that? I’m out of here!”
We work to minimise bias by very deliberately deciding what is important, being clear on what isn’t and investing time training our interviewers to conduct a good, fair interview. Our approach is to ask for precise examples from their experience to help us understand how they’ll behave if they join us. Getting to the real details is important.
At Intercom we’ve put a lot of thought into what’s important about our culture and what makes us different. It’s important that thinking is reflected in our hiring process.
One of our strongest values is every day counts. Our time on this earth is short. Our careers are even shorter. Our competitors are constantly improving. The market continues to expect more. We hire smart people and remove obstacles in their path, so we won’t hire people who introduce their own obstacles. “I knew the code was broken, but it wasn’t my job to fix it” (substitute design, process or any other aspect of your work for “code”). Sure, there are times when it’s a perfectly acceptable answer so that’s why details matter. If they didn’t jump in and fix it themselves did they tell someone it was broken? Did they suggest a way to fix it? What did they do to make sure it didn’t break again?
We explain a particular value, why we think it’s important, give an example of what we mean and then ask the candidate to talk about a similar situation from their own experience. We ask questions until we fully understand the detail of the situation, their behavior and the impact of their behavior (abbreviated to SBI – this is a common approach to giving constructive feedback).
Situation Why was this a problem? Who else was involved? How long from start to finish?
Behaviour What did the candidate do? What were the options available to them? Why did they choose a particular option?
Impact Did their approach work? Was it successful? Why was it successful? Was there a significant improvement or change? How did they measure it? What would they do differently?
An interviewer won’t ask all these questions directly, but should know enough detail to answer them. We might take 15 minutes to talk through a single example, covering about three values in total during this 45 minute interview.
How we evaluate
We evaluate a candidate’s answers by understanding the context of their role. What’s their job? What does going above and beyond mean for that role? What kind of environment do they work in?
For example, you see code committed without review. Escalating to your manager might be a good approach if you’re a junior engineer, particularly at a conservative or strictly hierarchical company like a bank. It’s not so good if you’re the CTO of a 15 person startup.
Poor candidates will assign blame, sometimes indirectly. Early on in my career I caused a bug, miscommunicated the fix to a QA department and caused an entire batch of CDs to be junked (back when software came on physical media). If you’d asked me what my biggest professional mistake was in the following three years I would have told you all about it. While I’d have said it was my bug, I’d probably have also said something weasel-like about how I should have made sure the QA team double-checked my work.
It’s a bad sign when someone doesn’t know the impact of their action. “I think we have less customer reported bugs since I changed how that component works” is a weak answer. The numbers should be there in your bug tracker. A slightly better version would be “Our customer support team told me it seems like we have less bugs reported”.
What we’re really hoping for is “There was a 43% drop in the number of reported bugs within a week, churn has reduced by 10% one month since we made the change though it’s hard to be sure of the exact causes. Though in our cancellation survey there’s been a significant drop in complaints about reliability.” This answer demonstrates a good grasp of the impact of the engineering time spent. It shows a wide product and problem understanding, not limited to the technical aspects.
Excellent candidates will have a comprehensive list when you ask them “What would you do differently?” They’ll have self-awareness and understand where the weaknesses are, what they’ve done to improve since. They may have implemented processes, written documentation or taken similar steps to make sure others don’t have to learn these lessons for themselves.
Where this doesn’t work
Less experienced candidates, like graduates or people held back by biases at former employers, will have fewer compelling examples to draw on. Sometimes we fall back to hypothetical situations, “What would you do if…?”
These can offer some helpful information but won’t give you the full picture. For example, a candidate described the importance of automated monitoring and alarming on services, then talked about a site they were responsible for. There was a significant outage and it was only discovered when customers began complaining. When I asked what monitoring and alarming was in place now, the candidate hadn’t taken a single action. Their answer was close to “customer support have my direct number if the site fails again.”
It’s worth having alternative paths when it’s too early in someone’s career to get a good picture of how they behave. Strong internship programmes, with development, coaching and honest feedback can be a good alternative.
Tips
As with all interviews it’s important to be clear with candidates, let them know what to expect and what type of answers you’re looking for.
Our culture contribution session will start with something like:
I’m not going to ask you any technical questions, what is important is figuring out what kind of contributions you’d make to how we work and how we make decisions. I’ll make sure to keep some time at the end for you to ask me any questions you have.
I’d like to talk to you about some of the projects you’ve worked on and some of the situations you’ve been in. Specific examples help me to better understand.
For example, we think it’s pretty important everyone contributes to the product, we wouldn’t like to work with someone who says “I won’t fix that, that’s not my job.”
It’s important you have the right mindset too. Over the last 6 years I’ve interviewed more than 400 people. My goal is always the same — I want to hire this person. I need to collect evidence to make my case, in a similar way I would make the case to my team to refactor a complicated component. If I can’t find the evidence then I can’t support hiring this person.
Start with broad, open questions. Don’t limit where a candidate can draw their experience from. “What’s your proudest professional achievement?” and the converse, “What’s your biggest professional mistake?” allow a wide range of answers. “Tell me what could have gone better with the scaling project you’ve listed on your resumé?”, is unnecessarily restrictive.
Always set the context for your question. “What’s your biggest mistake?” can be needlessly accusatory, it may leave a candidate feeling defensive and they may hold interesting answers back. I start by describing a recent mistake I’ve made (I never have to go back far) and what I’ve learned from it. I explain why we believe mistakes are inevitable but learning from them is valuable, then ask for their own example.
Clarify “we” statements. Sometimes people say “we” because they were part of a larger group and had limited involvement. Some people will say “we” even when they were the only person involved. Make sure you know who was relevant to a particular example.
Almost every interviewer we’ve trained will go through a phase of rapidly running through every entry in our question bank. Slow down, take your time, 10 to 15 minutes per example is average. It’s perfectly fine to say “I’m going to take a minute to figure out if there’re any other questions I’d like to ask you about this.” Your candidate will appreciate a moment’s break and it’s much better than thinking of the perfect follow-up question ten minutes after the interview.
Think you’d like to contribute to our culture? We’re hiring in Dublin and San Francisco.
댓글