Why We Prioritize Culture Fit Over Technical Interviews In Hiring Developers

In the year and a half that I’ve focused on hiring at Buffer, I’ve received more than 2,000 applications for engineering roles. Of those applicants, 70 have gone on to interviews, and we’ve grown from a team of 2 to 10 engineers.

Learning how to hire great people is one of the toughest challenges I’ve ever faced. I’ve iterated on our process for hiring engineers and I’m glad to have the opportunity to share my lessons. Here’s my first post on our hiring process and why we no longer have the traditional technical interview for technical roles.

Where we started: A typical technical interview

When I first started hiring, my interviews were highly technical because every interview I had at other startups and large companies were centered around challenging coding questions or puzzles. Since these were all successful companies, I figured there must have been a reason for asking these questions. For 6 months or so, my interviews had two standard computer science questions, something like: implement binary search, or how would you know if a loop existed in a linked list?

I remember asking questions like these and slowly realizing they never really told me much about how good of a fit a candidate would be on our team. If anything, I’d weed out a candidate who hadn’t taken a computer science course (or paid attention in class), even though I knew they had the capability of learning those concepts after seeing what they’d accomplished in side projects.

These types of questions weren’t at all relevant to what it’s like working at Buffer. I’ve yet to come across having to tackle a problem without the resources of the internet, so technical questions without the tools that emulate a development environment weren’t an accurate indicator of how a candidate would fit in technically with the team.

If anything, people who only excelled at technical questions were less likely to be aligned with the team we are building. Moreover, asking technical questions didn’t allow me to determine their ability to solve problems in line with how we approach things. We’ve been trying to build a team that follows lean principles, that doesn’t try to re-invent the wheel or spend time optimizing for perfect code.

Getting rid of technical questions in interviews has been one of the best things I’ve done as it allowed me to focus on what really matters for us in an interview.

A focus on culture fit over technical fit

We’ve been very deliberate about the team we’re building with a sincere focus on culture fit. For us, culture fit encompasses these four components:

1. Has a personal alignment with our Buffer Values.
2. Is a Buffer user who is passionate about our market and our vision.
3. Has demonstrated a startup-y, fast-paced, entrepreneurial spirit—either through prior founder experience, goal of becoming a founder, and/or completed a bunch of personal/side projects.
4. Has skill and experience for the role that is in-line with the way our team approaches that role.

Our interview process for engineers has followed the format of one initial technical interview followed by three culture interviews. In realizing that technical questions in that first interview weren’t telling me much, I removed them entirely. In doing this, I optimized for determining culture fit and took a larger risk in technical fit—the inverse of what most companies do. It is much harder finding people who fit our culture than people who are technically skilled for the job.

Candidates who are good culture fits are likely also good technical fits, which is why I am willing to take that chance on someone who embodies our values and is passionate about the team, product, and vision that we’re building. Having that means they have the right motivation to learn and become a technical fit. I trust someone I believe is a culture fit to start building and deploying on day one.

How we determine technical fit

Since we don’t believe interviews are the best place to gauge technical fits, we’ve had to set up different ways to test for this. Github activity and the code-walkthrough have been the best preliminary ways for me to assess technical fit. Github activity gives me an idea of how active someone is with side projects or open-source. The code walkthrough gives me an idea of what type of code a candidate finds interesting and how well they communicate their work.

Here’s the general structure of our new ‘technical’ interview:

• Candidate describes their background, how they grew up, how they learned to code, and lessons they’ve learned along the way.
• A series of culture-focused questions based on how the Buffer values apply to their lives and personal development philosophy.
• A code walkthrough, in which candidates choose anything that they have written that they are proud of and discuss with me. I’ll usually ask simple questions, like why they decided to design it the way they did, and what other implications they had to think about while writing this snippet of code.
• Q/A for the candidate to ask me questions.

After interviews, the main arena we have to determine how skilled someone is technically is by working closely with them. So, we hire everyone who we believe is a fit after interviews for a 45-day full-time contract period we call the Buffer Bootcamp.

During this period, an engineer would be fully involved in our development process and be trusted to deploy new code on day 1. Working with them closely lets us assess accurately how quickly they can pick things up and contribute.

Feedback during “boot camp”

Like everything else in our hiring process, we’ve had to iterate on the trial period experience too. A core component of this is there is a two-way continuous feedback loop on what’s working well and what can be improved for each new hire. I chat with a new engineer every couple of days and we discuss how things are going.

In addition to understanding their technical skills, a clear sign of culture fit for us is how well someone responds to direct feedback. Are they defensive? Are they grateful for the feedback and able to take it to heart to genuinely improve? Are they transparent about that process? Seeing something like improving on feedback greatly helps in our decision-making process to hire them full-time. The contract period has been the only opportunity to gauge something like this—something an interview won’t be able to provide. About 1 out of 3 people don’t quite make it to full-time.

Since the Buffer bootcamp is formalized and includes consistent two-way feedback, it makes it much easier for us to make a call on a faltering partnership, and it’s much easier for the candidate to move forward and find a better fit for them.

Some critical pieces that make the process work

In talking with many friends who lead hiring at their organizations, I’ve realized that our situation at Buffer is somewhat unique. So I’d like to address the key pieces that we set up that makes this model work for us.

We hire and work remotely

I don’t think we would be effective in this process if we picked one geographic region to be centered in. We’re able to look for the best possible people we can find, regardless of where they’re located. The best people for a team are likely located all over the world, so removing a geographic restriction has allowed us to be much more selective over the people we hire. We’ve been distributed from the start, and have centered our work and hiring processes around being distributed.

Starting something like our Buffer bootcamp process might be challenging to establish if we were solely focused on hiring in a competitive job market like San Francisco or New York.

We have an established and transparent culture

“Every company has a culture. The only question is whether or not you decide what it is.” — Jason Cohen

The Buffer values are well defined and established. We reference our values every day when we chat with team members. Having it established and agreed upon with our team gives us a lot of context around what defines a good culture fit candidate. When we give feedback during the contract period, it always points to a specific Buffer value. Without this, it would be hard for us to get on the same page of what type of team we’re looking for. I wouldn’t be able to focus on culture fit in an interview if I didn’t know exactly what a good culture fit looks like.

We have a great customer base

We’re lucky enough to have amazing customers who are fans of our approach to building our product and company. It’s been an absolute joy to interact with everyone who is excited about our approach in the hiring process. It makes it tough for us to decide who to bring on, which is the hardest part of my job. Yet it allows us to hire the best people who are passionate about what we’re building and want to do whatever it takes to be a great contributor to the team.

We’re looking for developers who are excited about Buffer’s values and passionate about the company and product we’re building.