I've hired a bunch of developers, both permanent and temporary, for projects large and small. As a developer myself I feel I'm pretty good at identifying at interview if someone is going to work out or not.
But! The time and effort we have to spend on interviews and coding tests I feel is not optimal, especially for part-time or temporary hires. That's why we now use the 'disposable project' technique when bringing contractors on board.
First we whittle down potential hires to less than ten. Of these ten we ask brief clarifying questions over messaging, weeding out one or two of them as unsuitable. Then we jump on a standard skype video interview with the three strongest, repeating until we have three we could see ourselves working with.
Pretty standard up until now. Traditionally we'd deliberate over the shortlist some more and have another interview with each of them to arrive at our decision. That's when it can go pear-shaped. Until we have them working with us for real, solving real problems and communicating, there's no way to know for sure how this (most crucial!) piece will go.
So we now run as fast as we can to a trial project. We give this same trial project to our final three. The surprising thing we've found is that it's always obvious which of the three we want to work with after the trial. There's something that makes one stand out from the rest, and usually it's that one asks the right questions and is far clearer in communication than the others.
When picking a trial project we've found:
- it should be a piece of real development we already had planned
- estimated to take a day or less
- something that doesn't require learning how our system works- not in a complex part of our code
- some requirements written down but with gaps where we expect them to ask questions, not to make assumptions
- they'll be paid their usual rate, not a fixed price
- using the same tools as we do as much as possible
- don't indicate how much time we feel it should take
- give a standalone package of access/code and instructions to each candidate to work on at once
You'll find it surprising how many ways there are to handle the same task and conditions! We've been blown away candidates at both ends of amazing and terrible even after taking them through interview.
We look primarily at the disposable project when deciding which of the three to hire. Specifically:
- did they ask questions where they were unsure of important requirements or did they guess
- did they manage to deliver it right first time or was it back-and-forth a few times
- did they look at everything we gave to them or were there questions about things they already had answers to
- when they had a question was it a case of constantly and repeatedly interrupting us or did they package up a few questions after getting as far as they could themselves
- do they prioritize speed over quality
- can we work with them professionally
- does the final solution show that they've thought about the problem, perhaps even offering something better than we proposed
- did we have to chase them for updates and got the feeling things only moved when we checked in
- would we put their solution live without any modifications
- was their pricing clear and transparent, and fees likewise
- how do all the candidates compare on time to deliver, hourly rate, total cost
If you're anything like us, you'll find that there is one clear winner and you've saved a lot of heartache by not hiring based on an interview/code test alone. When you make the offer you know what to expect from them.
It's a disposable project because you should end up with three of the same thing, leaving you to throw away two. However that extra cost and time in my experience is a worthwhile investment, leaving you with one very solid developer before going weeks down the road with the wrong developer.