Our hiring process has been continually refined over the 7 years we’ve been in business to reflect the needs of our team, the lessons we learned along the way, and the changes in the candidates we see.
In this post I’ll go through our hiring process, note places where we’ve seen changes, and hopefully answer some common questions.
It’s worth noting that we’re currently actively searching for both a new Designer and Developer. If you’re interested, I hope you’ll get in touch.
The History
When we first started out, we were smaller and we didn’t focus exclusively on Ruby on Rails. So our decision-making process for hiring new people was necessarily different.
At first, I’d basically talk to people a few times, meet them in person, and make the decision about whether to hire or not largely on my own, with consultation from Jon when he was available or when I thought it was particularly necessary.
Now that we’re a bit larger and have a well qualified team we involve the rest of the team in the decision making process to ensure that the people we’re hiring have been agreed to by the team.
We do this because having a cohesive team is incredibly important to our overall culture and attitude. We want to make sure that everyone will work well together to uphold our high standards.
Also, because we used to use a variety of different technologies our requirements were in some ways more loose, and in some ways more strict. For example, we didn’t use Java on every project, but that meant that if you were being hired as a Java programmer you’d be working with particular clients on particular projects. You needed to be able to perform well on those specific projects as well as just demonstrate a technical aptitude.
Back then, we also didn’t have the standards and practices we do now. We didn’t write automated tests, we used many different frameworks, and we weren’t as particular about the projects we took or the kinds of people we hired.
When we switched to Rails, that was our chance to push the reset button on our standards, including our hiring process.
We established that we would do test driven development, run continuous integration, more strictly follow agile methodologies and hold ourselves to a higher standard. Necessarily, our hiring practices needed to change to match this.
The Current Process
We ask all development candidates to provide us with information about them and a code sample as part of the initial contact.
After reviewing the code sample and their resume and cover letter, we decide whether we’ll do an initial interview with them.
We used to only ask for a code sample after the initial interview and before the second, technical interview was already scheduled. However, after a few candidates who would have never gotten through to the technical interview had we seen their code first got through, we decided to ask for this and evaluate it up front.
The initial interview is either by phone, video chat, or in person based on their capability and location. This initial conversation isn’t technical at all. Its a chance for us to hear in their own words what their experience is and for us to give some insight into thoughtbot, how we operate and where we’re going as a company.
If this initial interview goes well, then we’ll ask the candidate to do a technical interview with other members of the team (same for design candidates).
The technical interview is usually with two people, we review the sample code (or designs) ask them questions on that, and also ask a series of more technical questions.
We have some technical questions that we’ve come up with and revised over time. With these questions we try to judge core technical competency rather than just being up to date on the latest plugin or buzz-word (though those are also things we consider).
For candidates whowe think might be a good fit after the technical interview, we then invite them to come and work in our office for a week, for which we pay them for their time.
This week-long trial, particularly for remote candidates, is as much for us as it is for them. We want to make sure that everyone involved is a good fit before the big decision.
During this week-long trial we try to get them interacting with each member of the team and try to give them as accurate a picture as possible of what its like to work at thoughtbot.
Things We Can Improve
As with any process, this one continues to evolve, and there are certainly areas that we can improve.
We used to do a really terrible job of keeping track of potential candidates throughout the process, particularly in notifying people of a no-hire decision. We now do a less terrible job by using Wufoo to take submissions in a standardized form and Highrise to keep track of people, but we could stand to do an even better job with this.
As I mentioned above, our technical interview questions try to strike a balance and identify strong core technical competency rather than just being able to spout of the latest buzzwords or familiarity with a specific plugin. However, our questions could probably try to work with more practical knowledge rather than computer science topics. We’ve recently made some changes here already, and focus more on the sample code they’ve submitted, but we continue to refine.
Like all things we do, we also don’t want our hiring process to be a burden. We are a small team with lots of responsibilities. If anything we do becomes a burden on anyone involved it’s not working.
One problem we were having was that the number of low quality candidates we were receiving took a lot of time to screen. To help with this problem, we’ve started to avoid posting to job boards right away. Instead, we’ve focused more on trying to find qualified candidates through networking and directed advertising to more focused groups. Then, if we haven’t found someone through those circles, doing a broader search.
Our goal for our hiring process is to find people that will be a good fit with the team and who will do a great job with the kind of work we do. Our process has been honed over time to hopefully become a useful tool in identifying the right kinds of people for us.
I’d love to hear what you’ve liked or disliked about either side of the hiring table you’ve been on.
