Creating a better developer test

Hate is a strong word. Its a word that should be used sparingly. A word only wheeled out in times of desperation. A word reserved for the things in life you would prefer never to see again.

I hate developer tests. Let me be unequivocal here for a moment. I really hate developer tests. As a developer of 13 or so years I have sat my fair share of these things, some better than others, but I doubt any of them were the deciding factor in me getting the job or not.

Haters gonna hate

One of my main gripes is that most developer tests prove nothing. 

"What is the name of the Nuget scaffolding package for Asp.Net MVC3?"
"List the events in page life cycle."
"List all templates of the Repeater control"

If you can answer the three questions above, congratulations, you can obviously Google with the best of them. Every developer test will have a few questions like those above. Questions like this prove nothing. So you can remember that there is a SeparatorTemplate in a repeater. What has this told your prospective employer? Precisely nothing. Having Google has abstracted away this requirement in a developer. When it took 30 mins to scour the weighty tomes on the office shelf for an answer to a technical question, the ability to recall obscure facts and figures was essential. As developers in 2013 we all have access to all the information, all the time. The need for us to remember dusty corners of our chosen frameworks has gone. Get over it.

More important than CODE?!

It a well known phenomenon that the bar for developer tests is low. But why is this the case? Is it perhaps because a developer's ability to write code is secondary? When hiring a developer, there are criteria that should be ranked higher than their ability to code. What could be more important than your code? Your ability to explain your code? Your ability to share your ideas with your colleagues? Are you excited by new developments in your chosen field? Your fit with the wider organisation culture? Your ability to plan your workload and prioritise? While a developers ability to write code is clearly a core skill, it is not the only one which should be considered when hiring. 

Take a sad song and make it better

I was recently asked to write a developer test as my organisation is looking to expand the current team and the existing test needed a little refresh. I wanted my developer test to not only test if the candidate could write code, but if the could read code and understand requirements. I also wanted my developer test to contain a variety of questions from simple programming ones - to make sure they understand general programming constructs like object-orientation - to tasks which our developers do everyday, like writing a LINQ query to filter a list of objects, or writing some JQuery to wire up click handlers. I included a few bug spotting questions to test candidates code reading abilities.

Finally, there was a section asking candidates to write a web page, showing a list of orders and the products contained within each order. A very low bar indeed, but this simple task tells me if the prospective candidate can structure their code, and write code which is reusable. Their ability to read and understand (albeit simple) instructions is also tested as well as their attention to detail.

Below are two sample questions to give a flavour of what I ended up with.

Define a Orange as a c# object. Include any object hierarchy and properties you see fit.

The following code contains some bugs. Please list below the code snippet any bugs you can see.

Hopefully my developer test will test more that just the candidates ability to retain information. Hopefully it will tell me more about the prospective candidates than other tests full of obscure framework related questions. Hopefully it will go some way to recruiting a better developer. Hopefully.