On Hiring and Test Projects

Hiring is a risk. Just about any company out there is going to put new employees under the microscope, at least for a short time. Everyone wants to know they made the right decision -- that this new employee can actually do the job they interviewed for and is a good fit for the company culture.

There are also several steps a company will take to mitigate this risk during the hiring process. This is what phone screens, call-back interviews and coding tests are all about. Hiring seems to be an ever-evolving process in the development world, and the goal is make sure that all parties involved are making the best choices possible.

Of course, nothing is perfect and everyone is always looking for ways to improve this process. Over the past week, I've seen several mentions of requiring potential hires to work on a 'test' project before getting the final thumbs up.

The first example of this comes from 37signals talking about their new hire. In their book Getting Real, they go into more detail about their 'test' project':

Before we hire anyone we give them a small project to chew on first. We see how they handle the project, how they communicate, how they work, etc. … Scheduling can be tough for this sort of thing but even if it's for just 20 or 40 hours, it's better than nothing.

A second example comes from a post about Heroku's hiring process

Several of our managers prefer to lay out several potential interesting projects, talk through them with the candidate, and then let the candidate decide what they’d like to work on. Sometimes there’s a pressing need that the candidate can jump right in and add some value. It’s always important that the starter project is achievable, if it’s too broad of difficult for a 1-2 day period then the manager has failed in the hiring process.

Let me state that I am not lodging a complaint against 37signals or Heroku over their hiring practices. Auditioning employees is a good idea. And both of these companies offer to pay their prospectives as a contractor. This is the correct model.

But for as many good examples that exist, there are bound to be those who abuse the practice. So let's set a few ground rules.

To see one of the most fascinating and bizarre hiring experiences ever, I highly recommend this two-part episode of Penny Arcade TV.
Pay their hourly rate

If the prospective employee has done contract work in the past, they likely have a rate. Companies should pay exactly that. If they don't have a rate, offer something competitive to what you would expect to pay any contractor. By asking the prospective to do this test project, you are shifting the risk almost entirely to them. It's their time spent on something that may result in nothing. They need to be compensated.

No 'real' work

The US Department of Labor has guidelines that define exactly what type of work an intern or volunteer may perform. If you are not hiring your prospective employee as a contractor, you are required to follow these same rules.

Do not hand a prospective employee work that a regular employee would handle. Do not have them perform any work that is important to the business. If you do give them this type of work, you are legally required to treat them as an employee. It worries me a little that Heroku describes some work being done by candidates where "there’s a pressing need that the candidate can jump right in and add some value." If that is the case, they absolutely need to be paid for their time.

A candidate's time is more important than the business's

As a business, you are the one soliciting candidates to come work for you. It is your responsibility to be flexible in how you schedule these things. It is likely your candidate is already working a full time job, has limited vacation days and is probably trying real hard not to let his colleagues know he's looking for new work. Please be sensitive to this.

It honestly seems to be asking a lot of a prospective employee to dump 40 hours on an employer who hasn't yet committed to hiring them. If you're going to insist on a test project, you need to make sure you bend over backwards to accommodate the candidate's schedule.

The test project must be the last step

I've heard of companies who insist applicants take a 6 to 10 hour programming test before even starting interviews. This starts the entire process off on the wrong foot. Again, this is a two-way street. As nervous as you are about hiring someone that's qualified, the candidate is just as curious about whether or not you're the right fit for them. Don't ask them to take a technical test before having a conversation with them.

Developer's aren't just fuses looking to get plugged into a socket somewhere. Short programming problems are fine, but I would flat out turn down any company that comes to me with a long technical test before sitting down for an interview, or even a phone screen.

Only when you've gone through all the traditional interviews stages, and are on the verge of making a decision should be you begin the 'trial' phase for a prospective employee.

This is not a perfect process

There's always a lot of discussion going on about hiring in the tech community. Everyone know it's a dicey process which can result in disaster for both the employer and the employee if things don't work out. However, it is an art rather than a science. It is unlikely the employer will ever ben able to eliminate enough rogue variables to perfect the process.

All I ask is that employers don't add undue stress to the process or keep their candidate is perpetual uncertainly while they try to divine who the 'perfect' employee is through drawn out exercises and interview. A truly perfect employee doesn't exist.