Posted by andy@assembla.com Sat, 27 Jan 2007 11:53:00 GMT

We use trial projects to help find the best developers to work with. We hire candidates to do paid trial tasks from our live projects. In working with the candidates, we understand how good they are and how well the they work in our process. We try to sign the good ones for longer term contracts. It’s a lot of work, but it is well worth the effort.

Sometimes, clients want to do this themselves. Or, they want us to perform in a trial, which is a hassle for us, but a good idea for them. That brings us to the subject of how to select trial tasks. To make the process work, we need good trial tasks.

I find that a manager’s first instinct is to create a “test� task. It’s a small task that can be assigned to lots of candidates. That way, they save time by doing one specification, and they get the advantage of being able to compare results from multiple candidates. Or, they select a task that they have already specified and completed. That way, they save even more time because they don’t have to do a new specification, and they can compare the candidate result with the previous result.

I don’t use either of these approaches (a test task, or an already completed task), because they make the task meaningless. This causes two problems.
  • Good developers (including us) are busy, and work very hard, and don’t have time to do meaningless work.
  • These trials fail. As a busy manager, you will never bring yourself to pay enough attention to a meaningless task to get a good result.

So, I only assign trial tasks and features that I intend to deploy, or that are R&D / prototyping for something that I intend to deploy. I only assign meaningful tasks. I think to do otherwise shows disrespect to the hard-working candidates I hope to work with.

For trials, I take a real system that I am working on, and ask for a meaningful improvement. Essentially, I assign tickets out of our live projects.

I hear three objections to this approach

  • “I need the deliverable. I can’t risk it with a new guy.â€? If that is true, then hire two guys to do it.
  • “It’s too much work to specifyâ€?. That’s true if you are working with mediocre developers. However, if you are working with people who require precise specifications, and they just do coding, they aren’t saving you much time. They would save you a LOT more time if they could take the general idea and a do something with it. So, it makes sense to test for that.
  • “My systems are too complex for a quick trial.â€? That’s true if you are working with mediocre developers. If you are working with good developers, you should be able to throw them into a complex system and get some forward motion pretty quickly. From a qualification point of view, complexity can help you. If the build process is such that you can’t get new people set up easily, then you will benefit from improving the build process. That in itself can be a trial task.