A Defense for the Coding Challenge

Let’s talk about code challenges. It’s a topic with many opinions, and for a long time, I was unsure whether I liked or hated them. However, I’d like to make a case for why I think there are situations where this practice is beneficial, not only for the interviewer but for the candidate as well.

But before getting that far, I would like to point out some of the downsides to code challenges because it isn’t a one-size-fits-all solution. You may want to steer completely clear of them or only use them in specific circumstances.

Downside 1

The primary issue with coding challenges is that they may be built in a way that prevents the candidate from showing their strengths. For instance, I have often seen logic-style code challenges applied to all development positions. A front-end developer, whose job would be to align things correctly with CSS, would be quizzed on their ability to solve sorting algorithms. This skill test, which ultimately assesses an entirely different set of skills than what is needed, will alienate the candidate. It allows a candidate with skills in the quizzed topic to outshine one with the basic skills required.

Later, I will talk a bit about some requirements that I think need to be considered in a good code test. If used, it should at least give a better indication of a candidate’s skill concerning the specific role, not just as a “guy who does computer stuff.”

Downside 2

The second downside is one I have mentioned before. In a competitive hiring market, being the company with the most prolonged hiring process means you might very well miss out on some of the best candidates because they don’t have the available time to complete these tasks in their spare time, or because another company was able to close the hire quicker.

Why You May Want to Use Code Challenges

Unfortunately, many people don’t perform well in interviews. Without a technical assessment, the only place for a candidate to showcase their skills is in the interview itself.

The IT space has historically been associated with an introverted stereotype. While not always the case, they are definitely out there, and there is nothing wrong with that. However, they are usually not the strongest at selling themselves, which is basically what most job interviews are. So if we give a candidate only the ability to showcase their skills through an interview, it stands to reason that the person we end up hiring isn’t necessarily the strongest candidate for the job but the best at showcasing their skills.

Using a code challenge alongside the interview allows you to use the interview to assess the person. You can get an idea of how they would interact on the team and have time to explain what the job would be like without having the “hidden” agenda of trying to trip them up with random technical questions to see if they can answer correctly on the spot.

So instead of the on-the-spot question style, the candidate gets the time to seek information and solve the tasks, which is more reminiscent of how they would work in the real world.

Additionally, if done right, the code challenge can also help the company or team prepare for the new candidate after the hire. For example, your code challenge can indicate the candidate’s strengths, weaknesses, and knowledge level with various technologies. This can help put a “training” program together to support the new hire to be up and running and comfortable in the position as quickly as possible.

What Makes a Good Code Challenge

This isn’t easy to answer, as it would vary from position to position, team to team, and company to company. Some jobs may require a specific knowledge set, where the “implement a sorting algorithm” may be the proper test and be something you would expect any candidate to be able to do.

But here are a few questions I would use to evaluate the value of a code challenge:

1. Does it cover all the areas you are interested in for a candidate? This is not to evaluate if the candidate has ALL skills but rather to see if they have skills that would add value to a team. For instance, if the role is for a front-end team that does both the front-end development, back-end for front-end, QA, DevOps, etc., the test should allow a candidate to showcase those skills. If, for instance, your test is too heavily focused on one aspect, let’s say front-end development, you may miss a candidate who could have elevated the entire team’s ability at QA.
2. Does it allow for flexible timeframes? Some candidates may not have time to spend 20 hours completing your code challenge, and the test should respect that. So if you have a lot of different tasks, as in the example above, you shouldn’t expect the candidate to complete all, even if they have the time. Instead, make a suggested time frame and give the candidate the possibility of picking particular focus areas to complete. That way, you respect their time, and you also allow them to showcase the skills they feel they are strongest at.

Another bonus to add is to give the candidate the ability to submit additional considerations and caveats to their solution. For example, a candidate may have chosen a particular path because the “right” approach wasn’t clear from the context, made suboptimal solutions to keep within the timeframe, or even skipped parts because of scope but still wants to elaborate. This way, you get closer to the complete picture, not just the code-to-repo.