Here’s the situation: you need to hire a new developer. You’ve put up a job posting, you’ve got ton of CVs, and even after you discard the ones obviously not suited to the job, you still have a lot more potential candidates than you’d like to interview in person.
One way to trim this even further is to give them a task and see how well they execute it. Unfortunately, this only tests the programming abilities of the candidate. While important, these are not the only skills they need to have. Also, the assignment can easily be gamed – the candidate can ask (or even pay) someone to solve it for them.
The “patches welcome” test
Open source contributors usually start by making a small tweak or fix in the existing project code, not by developing all new codebase. Similarly, new hires usually first work on the existing code, before being put in charge of a new component of the system.
Can we apply the same principle to candidate assignments? I think we can.
We can make up a standalone project that uses the same languages or framework that the new hire will use – something that can be done in a day. We actually implement it, but leave it full of errors (syntax, logic, or valid but obviously poorly performant code).
The setup
Instead of writing corret code and inventing errors, it’s better to just write the whole thing in one go, never bothering to check and fix any syntax or logic errors (in fact, it’s best if you disable syntax highlighting and other code validation checks that your editor might have).
We put the project on a code hosting site and give the candidates no further instructions than “this needs fixing, documenting and unit tests – patches welcome.” We leave the code wide open, so candidates don’t think we’re abusing the test to have the “real” work done.
Then, we wait, see what they come up with.
Benefits
This tests a lot:
- whether the candidate can use git (or hg or your preferred vcs) or, failing that, that they can (and do) learn the very basics
- whether they can read and understand others’ code and modify/refactor it without making it into a pasta
- that the candidate can actually program and fix the code in question
- that they know the frameworks or libraries you need them to know
- whether they can follow the code/style conventions
- that they write unit tests (if applicable to the assignment)
- whether they’ve identified valid but poorly performant parts of the code
- can they write documentation
- whether they split their work in smaller chunks (commits/patches) or give one big code dump at the end
Conveniently, it also serves as a quick intro for your coding practices for the candidate you do end up hiring.
While this does take a bit more involvement up front (lose a day to write the test), I believe this is far more accurate test across various skills needed for a good developer, than just a simple fizzbuzz.
