A straw poll in our studio showed that most developers thought coding challenges as part of the recruitment process were bad news.
Delving a little deeper, I was astonished at the negative experiences our developers were reporting. From pointless number crunching to coding in an irrelevant language, these tests seemed like an arbitrary pass or fail exercises that chewed up applicants’ time. They encouraged the reviewer to jump to a conclusion in seconds that didn’t give any meaningful insight into the person applying. An example given by one of our team was a challenge to programme an application to select words in an anagram. This could take 3 – 5 hours to build, but take a reviewer 10 seconds to dismiss.
“They are abhorrent, they don’t tell the company anything about the developer and are a waste of their time. If the applicant hasn’t made an obvious error, they are invited to interview and nothing more is said of the 5 hours of development time they’ve gifted the company.”
– Michael Rochester, a developer here at Angry Creative (Pragmatic)
Why does Angry Creative still run developer challenges in the face of such a hostile reaction from our current team? Well, our challenge is a little different.
Firstly we want to show that we value people right from the start. Our development challenge is paid and we encourage the applicants to write up a feature backlog if they run out of time, rather than spend hours perfecting their response.
Secondly, our challenge is designed to be ambiguous and can be interpreted in a myriad of ways. This shows us how applicants deal with a vague task and gives them an opportunity to let their creativity shine. If a developer is a front-end specialist, they may choose to tackle the challenge using a super smooth JavaScript heavy approach. If they want to flex their back-end muscle, they may use the WP API to manipulate data from a range of sources. There is no right way, we just want to be wowed.
Finally, the challenge is designed to form a framework for the next (and often final) interview. We spend a lot of time reviewing the code and the finished product (or wherever the applicant has got to) and the feature backlog. We then ask the hopeful applicant to talk us through their approach and the code. So the challenge is far more than a pass/fail. In fact, if the finished result is a little shaky, but the applicant can talk passionately about why they tried an ambitious method, that shines them in an extremely positive light.
If you fancy a challenge with a difference, check out our current opportunities.