I’m pretty happy with the hiring process at Treehouse. Over the course of my career, I’ve been through (and conducted) interviews that ranged from borderline inane (“Why are manhole covers round?”) to pretty intense (“Here are some coding problems. You have 10 hours. Begin.”). I’ve filtered through resumes and listened to coworkers explain why they thought this particular candidate would be a bad fit “because he doesn’t seem to understand enough about how diesel engines work.”
Hiring developers at Treehouse is pretty painless, though – in part because we we’ve been careful to build a solid team, but also because we take a lot of care to cut to the BS out of the interview process.
Step 1: The Questions
When someone is interested in applying to become a part of the Treehouse Dev Team, we ask them to answer four questions for us. These questions serve as our initial filter:
- Why do you want to work at Treehouse? The most important part of building a good team is understanding the motivations of your employees, so this is the first question we ask. Often we’ll choose not to pursue otherwise-talented applicants based on their answer to this question.
- Can you share with us a code sample that you’re proud of, or that you think represents an important part of your coding philosophy? Two questions for the price of one! We get our first look at the applicant’s code, and also get to hear what they think is important about how they program.
- Can you tell us about a hard problem you’ve had to solve, and how you went about solving it? This question is mostly for providing us with insight into the applicant’s thought process, and has probably given us the most interesting answers, historically – I’ve seen responses ranging from “here’s an interesting algorithmic issue I had to solve” to “well, my wife and I were trying to find an apartment…”
- Can you give us a brief description of your background (NOT a resume or CV)? Treehouse’s mission is to help people educate themselves into a better career, and so it would seem almost hypocritical for us to put any significant emphasis on formal education and experience, which is why we don’t ask for resumes. At the same time, though, it’s always helpful to know where an applicant is coming from.
I serve as the first pass filter on the answers to these questions from applicants. There are several circumstances where I’ll just turn down applicants on the spot – if they communicate poorly in their answers, misunderstand the questions (it’s surprising how many people forward me a resume anyway), or otherwise indicate that they would definitely not be a good fit for us as a team or as a company then the interview ends there. If not, then I pass their answers on to the rest of our team.
Step 2: The Interviews
If the rest of the team reviews the answers and are all happy with the applicant, I set up a call with them. This is boring and typical stuff: I explain the position, benefits, answer any questions they have about how we work. The goal here is to make sure that they understand what they’re applying for and how the rest of the interview process works, and that they’re interested in moving forward before we take up any more of their time.
If they’re still interested, we set up interviews with the rest of the team. These interviews are mostly oriented around gauging the applicant’s fit with our team. This is important, because fit is the one thing that’s hard to fix if it isn’t there – you can train people on technology and you can cultivate talent, but personality mismatches are practically impossible to eliminate.
If the applicant has talked with the other members of the team and everyone’s on-board with continuing the interview process, we move onto the next step: giving them a contract project.
Step 3: The Project
To me, this is the most interesting phase of our interview process. At this point we’ve determined that the candidate is likely a good fit for the team, and they’re interested in what we have to offer. The last step in the process is essentially a dry run to give everybody a preview of what it would be like if we hired this person.
We try to find a project that we can give to the applicant. In a best-case scenario, the project fits all of the following criteria:
- It’s a real project – that is, when the applicant completes their work on the project, we intend to deploy the code live on the Treehouse website.
- It’s big enough, but not too big – we typically aim for a project that we think will take 10-20 hours of effort, as that’s big enough to require some real thought but not so big that it adds weeks to the interview process.
- It’s not critical path for the company – since the applicant will be working on this project in their own spare time in most cases, they need to be able to execute on it at their own pace. In order to help preserve that we don’t give them a project that’s a high priority for the company right now, so that there won’t ever be any temptation to pressure them into finishing it sooner.
- It requires coordination – often we’ll go out of our way to find projects that deal with tricky parts of our code base or require interaction with our design team in order to get a feel for how everybody is going to work together.
We give the project to the applicant and agree to compensate them for whatever reasonable hourly rate they choose. Even if we ultimately elect not to hire them, they’re doing valuable work for us and we want to make sure they’re fairly compensated for that. The applicant does their work – preferably in a GitHub pull request, so that we can follow along.
The great thing about this is that it’s very much a double-edged interview technique: not only do we get to see how the applicant will interact with our code base and cooperate with our team on a real project, but the applicant gets a taste of the kind of work that they’ll be doing. They’ll also get an idea of the state of our code (nobody’s run away screaming yet ;)) and see how the team behaves outside of the sometimes-sterile interview environment. It’s a win-win, and if everybody comes out of the process happy then we know we’ve got a candidate we’d like to make an offer to.
So that’s our interview process. It’s a bit longer and more involved than others, but it’s served us well and I think does a good job of helping the candidate represent themselves to us, and helping us represent ourselves to the candidate at the same time. While I can’t take credit for building this process – that goes to Alan – I am rather fond of it and think it’s helped us to build a pretty strong team so far. But, I’m always open to suggestions :) Let me know if you think there are ways we could improve on the process.