Why I Don’t Have Time For Your Coding Challenge

It tends to be standard recruitment practice in the tech industry to require candidates to complete some sort of coding test or challenge. Sometimes this takes the form of the much-feared whiteboard interview – where candidates are expected to work through a problem on the aforementioned whiteboard, in front of an interviewing panel. In other cases, it’s a take-home assignment, or coding challenge. Often following an initial interview (or sometimes two rounds of interviews), the candidate is given a task to complete in their own time, generally something typical of the job they are applying for, or that requires many of the same skills.

This article is not specifically about the whiteboard interview, which I have never been through myself, although many of my points are equally applicable (perhaps more so). Rather it is about the utter uselessness of the “coding challenge”, and why I would never advocate using this to assess prospective candidates for your job vacancy. Having been a candidate for front end developer positions on several occasions, I am 100% convinced that coding challenges are a waste of time and resources, and cause unnecessary stress for the prospective. I particularly enjoyed this Tweet from Laurie:

(If you don’t want to read this whole article, read her Twitter thread instead!)

Disclaimer: I’m writing this as an interviewee, having never been on the other side of the interview table (for a web development position, at any rate). Perhaps you’re an interviewer and feel that coding challenges are important and valuable. I would argue that even if that is the case (which is doubtful itself), they are not worth the burden you put upon the candidate.

Time-consuming

The number one reason I believe coding challenges shouldn’t be conducted is the amount of time they take to complete. Looking for a job is tiring and often demoralising. The chances are your candidates are already spending many, many hours writing out applications and tailoring their resumés. Many coding challenges come with caveats like “only spend six hours on this”, but in many cases candidates will spend much more time than stated. Why wouldn’t you, when you know there’s a chance that other applicants are spending more time, delivering a more polished result than you?

For this reason, coding challenges are anti-inclusive, only encouraging applications from people with unlimited free time. For candidates who are parents, have other caring responsibilities, work multiple jobs, have medical conditions, are studying in their spare time (the list goes on), six hours work for a job that they might not even get is time they simply don’t have.

Spec work: just don’t

A special mention here for “spec work”: It should go without saying, but requiring candidates to complete tasks that would otherwise be part of a paid job role is a complete no-no. I shouldn’t have to explain why this is bad, but it’s safe to say that if you’re expecting your candidates to do anything like the amount of work this challenge involves, you should be compensating them accordingly.

Counter-productive

People do not do their best work when put under pressure. The whiteboard interview is a classic example of how putting someone in an anxiety-inducing environment is unlikely to yield the best results, but the coding challenge is stressful in its own way too. To be writing code knowing that every line will be scrutinised and judged to determine your future, means that you’re unable to concentrate fully on just writing code that works. You’re second-guessing all the time – “Will they approve of the way I’ve constructed this function?”, etc – which will likely lead to overthinking, sucking up the time you have available, and therefore requiring more of your time.

On the other hand, perhaps the challenge is easy for the candidate, and they’ll simply sail through it. Take the “to do” list application – a fairly common coding challenge example. It’s quite possible they’ll have built something like for an interview before, and this “challenge” will be re-hashing the same. In this case, you’re not learning anything that couldn’t be gained from looking at their previous work, and it wastes everybody’s time.

Some candidates may stick to the safety of their comfort zones, and focus on delivering something technically polished but less advanced. Others may overstretch themselves, taking on something new, only to fall short (while stressing themselves out in the process). An example from my own experience: apply for a junior developer role, I was required to build a landing page from a design. Although I had barely any experience with Javascript, it was one of the “desirable” job requirements, so I spent a disproportionate amount of time trying to add some JS functionality, meaning I had less time to do the things I was confident in doing well. I went into the interview already feeling like a failure. Either way, a coding challenge is an artificial environment, that doesn’t reflect the real world where an employee will feel less pressure. I repeat: it’s in no way an indicator of how they will behave in a working environment.

For these reasons, a coding challenge is unlikely to demonstrate what a candidate is truly capable of.

Arbitrary

A disproportionate amount of time is often spent trying to deduce the requirements of the challenge. What is actually being judged? In the previous example, I didn’t know whether I would be judged poorly for my mediocre JS implementation, or looked upon favourably for having given it a go. Another case in point is this tweet from Carolyn Stransky:

Of course, you can ask your prospective employers if it’s not clear what criteria you’ll be judged against. But unclear requirements lead to more time wasted, and more unnecessary stress. In the worst-case scenarios, the person doing the recruitment doesn’t know the criteria themselves, beyond “I’ll know it when I see it”. (If that’s the case, then it’s a major red flag.)

What are the alternatives to a coding challenge?

So, what do I advocate instead? How is a manager to know which candidates have the most potential to shine at a job?

Ask pertinent questions (and trust in the answers)

Well, naturally you can ask them. A good interviewer should be able to encourage prospective employees to talk about their past experience with different technologies in a way that gives them an insight into how they would fare in the job role. What have they built? Were they part of a team? What were the constraints they needed to consider? How did they come to certain technological decisions? What do they like or dislike about a given technology? Which areas do they feel comfortable in, and where do they feel their knowledge or experience is lacking? What are they curious about? What would they like to learn or improve upon?

People don’t generally lie about their experience (they would soon get found out), although sometimes they might exaggerate for their resumé. An example is an interviewer looking for a React developer. Someone listing “React” as a skill on their resumé could be an accomplished React developer, or they could have only surface-level knowledge gleaned from attending a bootcamp or walking through an online tutorial. It should only take a few minutes of talking to them to understand the depth of their knowledge in this area, and whether or not they might be a good candidate for the role.

Have a probationary period

Most jobs have this already – a fixed trial period (usually 6–12 weeks), where the employer and prospective employee can determine if they are a good fit for the role. If not, they are free to part ways. Coupled with a good interview process, this should be sufficient. Plenty of people don’t pass their probationary period despite completing a coding test or challenge. There are many factors other than technical proficiency that determine whether someone is a good fit for your team, but coding challenges often focus on technical proficiency above all else.

Walk through their existing projects

Most candidates will have side-projects or work they’ve done for previous employers. Ask them to show you the code and describe the process, asking questions along the way (see above).

Even candidates for a junior role, perhaps who are fresh from a bootcamp, will likely have projects they can show. If they’re experimental or not public, that’s ok. It’s not the point of the exercise.

There might be some cases where candidates are unable to show work for specific reasons (such as NDAs). In those cases it might still be possible to talk about the work and challenges faced, without viewing the source code or going into specifics. But if none of these things are practical, there are still a few more options...

Ask them to build something – anything!

Instead of a coding challenge, ask them to spend a short time building something they enjoy, and talk about what they did and why. Perhaps they want to take the time to learn about a specific technology, so they put together a simple demo that helps them understand it better. Maybe they’re already a wiz with CSS animation, so they make a fun demo that really shows off their skills. Or another option, experienced by Jordan:

The difference here is that candidates are likely to be more comfortable talking about something they understand. The point isn’t how polished the result is, it’s how they talk about it afterwards.

I would still exercise a note of caution with this, as you are still asking people to complete an assignment in their spare time, which is not an option for everyone. I don’t advocate it as standard, but could be something to consider in exceptional cases.

You could argue the point of a coding challenge is to test a candidate’s limitations, which you might not glean from allowing them to choose what to build. Testing a candidate’s limitations is a terrible idea, which can only enhance the stress of the situation. And, as previously stated, stressed people don’t give an accurate impression of how they would behave in a “real” work situation. (Unless your work environment is super stressful, which is a whole other problem...)

Pair program

Again, I’m on the fence about this one, because pair-programming is not necessarily the less-stressful option. Personally, I don’t feel like I do my best work when someone is watching my every move – I would probably do a lot less Googling, and write far worse code! But if this is done well and with empathy, it could be used as a last-resort.

Focus on their ability to learn

Arguably, a candidate’s ability to learn is more valuable than how much knowledge they possess on a given subject right now. Coding challenges can only really demonstrate a current skillset. A better strategy might be to walk through an example of your company or product’s code and encourage the candidate to ask questions, as well as talk about what aspects they are familiar with.

A “good” coding challenge

If I haven’t convinced you to dispense with coding challenges altogether, let me give you one final piece of advice: Don’t try to catch people out. Make your challenge something straightforward that people can complete without hidden “gotchas”.

Here’s an example: For one position, I was given the challenge to build a simple app using API calls to get and post data to a server. I was given access to a starter repository, only when I tried to run the project locally I kept getting an error. I spent hours trying to debug it, thinking I was doing something wrong, berating myself for falling at the first hurdle (before eventually figuring it out!). At the subsequent interview I learnt that this error had been put in deliberately, to test whether I would reach out and ask for help. This immediately put on the back foot for the rest of the interview, despite not remotely reflecting how I would act in a work environment.

So. Don’t do that. And, if you can help it, don’t set a coding challenge at all. There are better ways to spend your (and your candidates’) time.

Webmentions for this page

About webmentions

Likes: 0

Reposts: 0

Mentions: 2