Healthy Engineering Teams: Improving The Interview Process
This is Part 3 in a series on building a healthy engineering organization. We’re more than developers writing code, we’re humans solving problems together.
Part 1: Why is a Healthy Engineering Culture Important?
Part 2: Foundations Of A Healthy Engineering Team
Part 3: Improving The Interview Process
Part 4: Fostering and Maintaining Your Culture
Part 5: Diversity of Thought
Everything in your team culture starts with interviewing. Notice that I don’t say it starts with hiring. Hiring is the outcome of interviewing. It’s how and why you interview that will determine the culture you ultimately embrace. This process should set the tone for the candidate’s experience on your team. It should sell itself. Candidates should be walking away from the process saying to themselves “I’d love to work on that team”.
Optimizing your process to hire the whole person, as opposed to just their technical skills, is a better way to fill out a well-rounded team.
Here is the interview process that has worked very well for us at Home Chef and has been continually refined over the past few years. We focus first on the candidate as a person. Technical abilities are covered last. We’re looking at their experiences, our needs, and what they will contribute to our culture. Productive development teams have diversity of thought so optimizing your process to hire the whole person, instead of just their technical skills, is a better way to create a well-rounded team.
Before We Start: Know Who You Are
I covered some fundamental elements that you’d want in your engineering culture in Part 2. If you haven’t spent time to define your rubric of core values and behaviors, start there. Once you’ve determined these traits, make your process optimized towards those items.
The Process
Step 1: Introductory Phone Call (~30 mins)
Conversational in nature, the goal is to get a quick sense of who this person is, if they can speak well to their experience level, and general communication. I break this phone call into 3 parts: tell me about yourself/experiences, this is who we are at Home Chef, and questions for me. At the beginning of the conversation, I like to hear where they start telling their story and how they tell it. Through simply listening to this, I start to get a sense of personality, and where their interests lie. Of course, not everyone is super talkative, so some nudging with questions like “tell me about what you learned at your last job?” may be necessary.
The 2nd half of the conversation can be pretty telling. I believe we have a great team, so I excitedly talk about who we are and what we value. It’s my chance to sell the company and let our own team personality shine through. But what I’m really interested in here is what parts they pick up on. Did they key in on the part of the conversation where I talk about mentorship? Did they get excited about the product planning process they would be a part of? Once I’ve spent 5–10 minutes being excited about what we’re doing, I open it up for questions from them and take note about what they ask. Often this leads to great conversations and is another opportunity for me to sell the role to the candidate by answering their questions directly
…what I’m really interested in here is what parts they pick up on.
Step 2: In-Person Group Interview (~3 hours)
The second step in our process is the in-person interview. The goal here is to give their peers on the dev team a chance to understand the candidate’s experience and shallow dive into their technical experience. Through the informal conversation and asking specific questions that let the candidate to talk about their experiences, we’re better able to identify their problem solving skills, ability to communicate ideas, and how they think through problems collaboratively with a team. The ideal outcome of this would be to know enough to want to see their technical skills in action through a technical interview.
This is where we differ from many teams, but it’s the key differentiator to our success. By this point we’ve spent close to 4 hours with the candidate and have yet to see code.
This is where we differ from many teams, but it’s the key differentiator to our success. By this point we’ve spent close to 4 hours with the candidate and have yet to see code. Crazy right? Consider this: software development is much more than writing code. We’re developing web and mobile apps in a time where great frameworks exist to help us make many of the low-level decisions. These languages and frameworks are largely commoditized. Because of this, I believe that our team can teach anyone better syntax. What is much harder to teach are the catalytic skills that we’re looking for: conscientiousness, empathy, humility, self awareness, interpersonal awareness, etc. So we choose to spend our time optimizing for those skills first to make sure they’re going to contribute to our goal of building the strongest team possible.
Step 3: Technical Interview (~4 hours)
Finally, we’re at the technical interview. This is the subject of many debates. Our technical interview is the final part of our process. It is done in person and as a pairing session between the candidate and a current team member. The idea here is to have them actually work together on a problem like we really do together every day.
There’s one important aspect here: We pay our candidates a fair market rate as contractors for 4 hours of their interview time. We do this because we respect that everyone’s time is valuable, and not everyone has the luxury to take a half day off to work with us (including and especially those with non-traditional backgrounds).
We make sure that the team member in the pair has already met the candidate, has a sense of what they’re capable of, and is able to test for the specific areas of the candidates skills that we want to better understand. This can and usually does include interpersonal skills. How does the candidate take direction while pairing? How do they give it? This process is flexible and is less about the final product than it is about the experience of working together on a real project.
We conclude our pairing session with what we call the “teaching portion”. We spend the final 30–45 minutes and ask the candidate to teach us something outside of our stack that they are an expert on. The topics we get can be really fascinating and are even sometimes non-technical. This tells us a lot about how the candidate will perform when asked to describe a topic to fellow devs, something they will do weekly in some form or fashion on our team.
A final note on the technical interview at the end of the process versus the beginning. If you’re optimizing to hire the whole person, as I am suggesting here, starting with the technical code puzzle doesn’t match your priorities, nor does it tell you much. In particular with the up-front code screen you are likely removing candidates from your pipeline that could otherwise have a huge impact on your product and team. By seeking to understand the candidate, you can create a technical screen that actually gives you insight.
Final Thoughts
In my experience, software teams undervalue both the people and the catalytic skills needed to hire great software engineers and create high functioning teams.
A couple of final remarks on the whole process. We fully disclose each step of the interview process to the candidates ahead of time. There are no surprises so they have time to prepare. In addition to our transparency, paying candidates for the pairing sessions sends an immediate message that their time and energy will always be respected.
To be completely transparent, I’m not sure how or if this scales to larger teams, but it’s been effective on teams up to about 30. Just because your team grows in size it doesn’t mean you should put less emphasis on your interview process. Even if you have to hire quickly, the time you spend up front is completely worth it and can help you avoid a bad hire or toxic employee who can completely drain your entire team.
You may have noticed that this is a time intensive process,. You may even consider it cost prohibitive. In my experience, software teams undervalue both the people and the catalytic skills needed to hire great software engineers and create high functioning teams. Our process is setup to optimize for folks who will contribute at a high level to both building working software and to team health.
