Coding Tests in Interviews

In my travels, I stumbled across a blog post from Brandon Savage titled, "Why Coding Tests Are A Bad Interview Technique".  While there are some points I think are fair enough, for the most part I disagree.  I'll break down the major points so it's easier to read.

Sending out Resumes to all available companies

Brandon mentions quite early on that his major gripe with these programming tests is that he doesn't have time to do one for every company out there.  Every company. He's applying everywhere.  A good developer shouldn't need to flood the market with resumes.  If you're any good, you should be able to be a bit more selective about where you apply.  Is the market really that bad that you need to go door-to-door begging for a job?

Writing a complete application as a coding test

In the comments, Brandon elaborates on this a bit further, saying that he's actually had a company ask him to develop a complete database-driven, input-validating, emailing application.  Yes, that's ridiculous and if it's occurring more than once in a blue moon, then there's a problem.  If a company is asking you to write an app like that just to get an interview, I view that as over the top and unrealistic.  Asking you to code up Fizzbuzz or a function to recursively search a directed graph? Not so much.

Look, as long as the code I'm writing doesn't take me more than a few hours, and I really want to work at the company, then I'm willing to put the effort in.  If I'm flooding the market with resumes hoping for any kind of bite, then I'm probably not going to want to spend much time demonstrating my abilities to... who was it...? One of those places...

Asking for a code test is disingeneous and disrespectful

You know what? I totally disagree.  Brandon suggests that a few phone calls might be enough to determine whether someone is qualified.  Qualified? Yes, probably.  Does that mean anything? Not necessarily.

Let me digress for a bit.  I'm not sure whether the same thing exists in the US, but in Australia, we have a small training organisation that advertises late at night and promise a career in IT within a few weeks of graduating their four month course.  Four months, and they're considered an IT professional.  These offers boil my blood - particularly because for many, many people, their qualification means the same thing as mine and my bachelor's degree is therefore diluted.  By the way, I'm not talking about IT recruiters here; one would presume they'd know the difference.  My point is that an IT qualification by itself means nothing, and I'm not just talking about a participation certificate from Bob's Discount IT Training.  I graduated from my degree with a scarily large number of budding programmers who couldn't write code to save their lives.

Even experience on paper means nothing.  I've worked with plenty of highly qualified and very experienced people whose code just makes you cringe.  Sure, they've been involved in several major projects and have been an integral part of so-and-so really-important-deployment, but when you get down to it, they wrote crap code and nobody really knew any better.  You can look great on paper and still not have a clue.  I'm sure we've all known people like that.

Brandon suggests that as an alternative, asking for an already-written sample of code would be acceptable.  If it's available, then sure, but I don't think requiring one is fair for two reasons:

Firstly, the code the person writes during the day at their current job is not likely to be public.  As an employer, how would you feel about an employee showing the inner workings of your proprietary software to a rival so they can up and leave?  There's almost certainly something in the developer's current contract that explicitly prevents them from doing that anyway.  So what about code they've written in their spare time I hear you ask?  Unfortunately, not everyone writes code in their spare time and I think it's rude to assume they do.  I do, and I'm sure a lot of developers do, but they might not for whatever reason.  You shouldn't hold this against them.  Even if the person does write code on their own time, why should it be any more public than their company's code?

Secondly, I'm not sure I'd be happy showing much of my own (old) code.  I look at stuff I wrote a year ago and wonder what I was thinking.  Does this mean I'm a crap developer?  No, I think it's healthy to be able to appreciate that you're continuing to learn.  If you can't compare your current work to your previous work and see some improvement, then are you still learning?  I'm not alone on this line of thought either.  From a hiring point of view, I want to know how good the person is now, not how good they were the last time they wrote code that they're allowed to show you.

It's not all bad - what I agree with

I agree that it is very important to be able to see whether a developer is capable of learning. However, I'm not looking for the coding test to evaluate someone's learning ability. A piece of code is a snapshot, and you're not going to get any idea of learning and adaptability from a test like that unless you ask them to do it every six months for several years. You can evaluate whether someone learns well by asking them questions in the interview, and looking at how they keep up to date in the industry. You could even ask the default predictable question about a particular challenge they faced and how they overcame it. But nobody's going to look at a slab of code and marvel at how well this person adapts to change. That said, if someone proudly hands you a bit of code written in VB.Net for version 1.1 of the framework using untyped DataSets, it's probably safe to assume they're not the learning-and-adapting type.

Brandon also suggests that if someone has a body of code samples ready to give out, then they shouldn't have to do the test.  If those samples are appropriate and relevant, then I agree to an extent.  Why ask someone to redo something they've already done?  Really, though, if you want to see how well someone can think through a problem and turn it into code, then the best way to test that is to actually ask them to do it.

Summary (and tl;dr version)

If someone is applying for a job as a developer, I don't think it's unreasonable to ask them to write some code.  If it's a fully-fledged application, or something that takes more than a few hours, then we're not talking about a code test, we're talking about free software.  Sadly, qualifications and experience don't necessarily equal capability so you can't just rely on that.  It's entirely possible to have an awesome resume and loads of experience, and just be crap at writing decent code.  Being asked to show off your skills shouldn't be taken as an insult, but an opportunity.

Damian Brady

I'm an Australian developer, speaker, and author specialising in DevOps, MLOps, developer process, and software architecture. I love Azure DevOps, GitHub Actions, and reducing process waste.