Why we don’t have technical interviews for technical roles at Buffer

In the year and a half that I’ve focused on hiring at Buffer, I’ve received over 2000 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.

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 there must have been a reason for asking these questions. For 6 months or so, my interviews had 2 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’ve 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 which 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 doesn’t allow me to determine their ability to solve problems inline 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 1 initial technical interview followed by 3 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 taking a larger risk in technical fit—which is the inverse of what most companies do in determining technical fit and risking culture fit. It is much harder finding people who are culture fits for our team, than it is finding people who are technically skilled for the job.

Essentially, we now have four culture interviews. Here’s the general structure of our new ‘technical’ interviews.

• 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 Buffer values apply to their lives and personal development philosophy.
• A code walkthrough, in which they choose anything that they’ve written that they are proud of and discuss with me. I’ll usually ask simple questions of why they’ve decided to design it this way, and what other implications they’ve had to think about while writing this snippet of code.
• Q/A for the candidate to ask me questions.

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, 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.

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.

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 of the feedback and take it to heart to genuinely improve and are 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 on a backup plan.

Some critical pieces that make this interview process work

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

We hire remotely, and work effectively 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 located all over the world and so removing this restriction allowed us to be much more selective over the people we hire. We’ve been distributed from the start, and have had to center 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 such a great customer base

We’re lucky enough to have such amazing customers who are fans of our approach to building our product and company. It’s been an absolute joy to interact with some of these people who are 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 we can find who are passionate about what we’re building and would 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. If that sounds like you, we’d love to hear from you!