Matt Basta

My Blog

I don't care about your code challenge.

I've recently been doing some interviews for front-end and JavaScript-related positions at local tech companies here in the bay area. One thing I did not expect as part of this interview process (at a company which shall remain nameless) was to be presented with a "code challenge". I'm all for a challenge, but I immediately lost all enthusiasm after I read through the requirements. Essentially, the "challenge" amounts to:

Let me explain the reasons why this is bad and I'll never do this.

You don't learn anything about the candidate.

When you get a final product back from a candidate, what does it tell you? Probably not much. Here's why:

The only thing you learn about the candidate is what they're willing to put their name on.

Your time is more valuable than mine.

If you ask a candidate to take part in a "code challenge", you're telling them that they need to devote a day of their time to building something (without pay) so that you are able to better understand their ability.

This is a load of horse shit.

The fact that technical interviews exist and lead to--in many cases--strong hires disproves the notion that a "code challenge" is necessary. Perhaps you're doing it to be different, perhaps you're doing it to attract people that like "code challenges", perhaps you're doing it because a bunch of recruiters got together and said, "You know what would be a great idea?"...we may never know. Regardless, the message that you're putting out is that instead of proactively learning about the candidate, you'd rather sit back and grade papers.

For many candidates, this process is entirely redundant anyway. I have a Github with almost 100k lines of code that I've written that are live in production, complete with tests and documentation. If anything, the code on my profile is even more telling than the code that I'd otherwise write for your "challenge" because my code is actually being used for something. Granted, not everyone works for a company that open sources all of their code, but that shouldn't disqualify open source code from counting in the recruiting process.

I'm not equipped to do your challenge.

When I do work for work, I use my work computer. I don't do the same kind of tasks when I'm at home on my personal machine, mostly because I don't generally do the same kinds of things in my own time as I do every day at the office. At work, I write production-ready websites. At home, I make HTML5 games, work on CSS compilers, and make toy programming languages. I don't have an environment set up for building what you want me to build (in my free time).

I'd imagine many other folks that don't use their work computers at home are in the same situation. Work is separate from personal endeavors.

The process is candidate-unfriendly.

As a candidate, I'm blocked from asking your engineers and engineering managers about your company and culture. An interview process is not just so you can decide whether I'm a good fit for your company, it's also so I can decide whether your company is a good fit for me.

Engineers aren't different.

We engineers solve problems, that's our job. We do a lot of things on a day-to- day basis and oftentimes wear many hats. That doesn't, however, mean we should be required to allow recruiters to make us jump through flaming hoops.

In other words, when you hire accountants, do you hand them a stack of spreadsheets and tell them to put together a sample of W2s? When you hire someone to clean the office after hours, do you ask them to visit a sample office and demonstrate their ability to clean it up?

If Walmart asked potential employees to visit a store and stock an aisle worth of shelves (without pay) before they could proceed to an interview with a manager, how do you think the public would react?


If you're tasked with hiring and you think a "code challenge" is a good idea, take a moment to reconsider.