GIANT ROBOTS SMASHING INTO OTHER GIANT ROBOTS

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 who we 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.

The simple fact of the matter is that we care too much about the quality of what we do and the environment in which we do it in.  That’s why, for a few years now, we have not subcontracted for other people and we have not subcontracted out any of our work.

Subcontracting for other people

After a few failures working in a situation where we are subcontracting for somone else we realized that because we didn’t have a direct responsibility to the end customer, and very often no direct lines of communication, we were not able to properly introduce them to our way of working and to properly set expectations.  When we were left to communicate through someone else in order to ask questions, talk about deadlines, etc. there is the danger that it’s not being told like it needs to be told in order to properly set expectations.

In addition, in a subcontracting situation, you are often beholden to a third party for invoicing and collection.  We invoice our clients on a weekly basis, with Net 15 terms.  All too often, when we didn’t have direct access to the end customer we were left waiting for our invoices to be paid while the person we were subcontracting for waited for their client to pay them.

We are in the business of working on successful software projects. We are tenacious about identifying things that aren’t working for us and stopping doing them.  Every once in a while, we identify something like this that becomes a real core principle to the way we work.  These principles, or rules, stand as guidelines to remind us what we need to do in order to ensure success.

Subcontracting out work to others

We also had several instances where subcontracting out work to others didn’t quite work out, and so have stopped doing it.  Everyone who works for thoughtbot is an employee and we don’t subcontract any work out.

One of the main reasons why we don’t do this is that we found it difficult to maintain our high level of expertise and quality when we were subcontracting.  Additionally, we care very much about the environment and comraderie among the team.  In cases where the expertise may have been great, its still hard to integrate that person into the culture of the team, and the contractor is ultimately always an outsider.

I know many firms find themselves subcontracting work that is not their core area of expertise out to other firms so that they aren’t turning away work.  I’d rather turn away work than take projects which aren’t a good fit for us.  If there is a component which isn’t quite right for us, we assist the client in making a relationship directly with someone else to do the work above, for the same reason that we don’t subcontract for people.

Also, working within our core expertise has allowed us to become experts at what we do, which has so many more benefits than the extra revenue we may get by being able to take on and subcontract Flash work.

Breaking the Law

Because these rules are there to guide us, of course there may be situations where we might subcontract for someone or subcontract to someone (there hasn’t been in quite some time) if we try to make the relationship directly with the end customer and subcontracting is the only way we can work, but we think the project might be good anyway.  The rule causes us to remember why we created it in the first place: 1) lack of direct access to the client 2) dependency on a third party for invoicing and collection 3) inability to integrate subcontractor onto the team 4) problem maintaining high level of quality.  If we can subcontract and still work around those key sticking points, then so be it.  However, at least we are then making the active decision. We’ve thought it through and decided that the project can be successful in spite of it, rather than just blindly taking any and every project and praying for success.

Back in June, I mentioned that we were looking to hire both designers and developers.  Hiring is tough, but we take our time, and don’t compromise to find the right people.  And it pays off.

I’ll be speaking in detail about hiring Rails developers in my talk Succeeding at Rails at Lone Star Ruby Conference next week in Austin, TX.

I’m pleased to introduce you to the new members of thoughtbot:

Fred Yates

Fred joins Kevin as our second Graphical Designer.  He got right to work on some client work and has been rocking it like nobody’s business.  You may have noticed his first post here about the twitter redesign.

Tristan Dunn

Tristan is a well-rounded Rails developer who moved from Louisiana to Boston to join the team. He’s hit the ground running on several projects, and making a great impact already.  He is slowly adjusting to Boston and has excellent support from Jared.

Josh Clayton

Josh is currently in the process of relocating from Michigan to Boston to join the team, and we’re happy to have him.  Josh is one of the current maintainers of the Blueprint CSS framework, as well as a contributor to several other open source projects.

Welcome to the team, guys.

We’ve slowed down hiring somewhat now, as it takes a lot of attention to do well and with these people coming on board we’re doing all right.  However, we’re always interested in talking to qualified people, so check out our jobs page for more information on how to apply if you’re interested.

If you haven’t already heard, we’re going to be be both speaking and running a training session at the Lone Star Ruby Conference 2009, which runs from August 27-29 in Austin, TX.

Our training session is an enhanced version of our regular Ruby on Rails training session titled “Second Gear”, where we’ll be showing you how to increase the velocity of your Rails development through tools, process, testing, patterns, and refactoring.

My talk, “Succeeding with Rails” will be a little more business oriented. I’m going to step through the principals and strategies that have helped to make thoughtbot a successful Rails development firm, including Hiring, Client management, Design and Development practices, Consulting services, Marketing, Product development, and Open source development.

If you’re planning on going to LSRC, we’ll see you there. If you want to go, register.