Startups, your technical challenge is doing you harm. Stop it.

I find it odd that this is such a controversial opinion. I have asked a lot of managers over the years why they are implementing a technical challenge as part of their recruiting process, and the most common answer, by a huge margin, is “I don’t know” (more commonly manifested as “That is just how recruiting developers works, isn’t it?”).

If you don’t know why you’re doing something, stop doing it.

I’d love to end this post there. It should be that simple. But the response when I recommend dropping it is always the same: “So-and-so does it, do you know better than them?” So, before we get into why not, let’s take a moment and review why certain companies implement technical challenges.

Reasons for a technical challenge

You have too many applicants

If you have so many applicants that you don’t have time to talk to them all, or even read all their resumes, you need a way to weed some out. You can, and in this case probably do, use a resume scanning software to try to identify the best candidates, but a good way to whittle the list down further is to make your first step an automated coding challenge. If people are lined up around the block to get into your company, adding an extra hurdle to the application process is something you can get away with.

Of course, if your company is this hot, it’s probably time to stop calling yourself a “startup.” Still, some startups will claim too many applicants is a problem, even when their list of applicants is barely out of the single digits. Typically, this means you’re overdoing your interview process and what you actually need is to simply your process, not make it more complex. Less time spent with more people will give you a better view of your candidate pool than more time spent with candidates filtered by a technical challenge.

Firing people is hard

This often crops up at large companies with robust HR policies who are especially averse to the risk of labor lawsuits. HR policies protecting employees are a good thing, but a side effect is often that a mistake during your hiring process can be very hard to correct. Technical managers who have experienced an unqualified employee not just under-deliver but consume the manager’s time with formalized reviews and improvement plans will often justifiably compensate by enacting much more rigorous technical vetting processes up front, where they have the control.

As a startup, if you struggle to fire people, you’re dead. This shouldn’t apply to you. If it does, you have bigger problems than your technical challenge. Treat the first month of employment as the technical challenge. If an employee misrepresented their experience, cut them and move on.

You are a staffing agency

If you’re staffing for someone else, the first person who is going to know that you hired a dud is likely your client. When the developer is the product, bad developers hurt your brand, and excessive thoroughness in your interview process can be justified.

Obviously, this doesn’t apply to startups.

That’s it. Those are the only good reasons I have come across, and none of them apply to startups. If you’ve got another one, by all means share it below.

Before we get into the reasons not to have a technical challenge, let’s look at one really bad reason I’ve heard a lot.

Fake it till you make it?

Lots of startups will argue that they want to require a technical challenge because it is what the big kids do, and they want to project the impression of a more mature company. Again, ask yourself the important question: why do you want to look like a big company? Typically, you want to look like a big company to your investors because it portrays maturity and stability which make you seem lower risk.

On the other hand, to potential hires, looking like a big company is a negative. Most people applying to startups are doing so because they don’t want the overbearing and constraining processes that come with a big company. They want to feel their role has a noticeable impact. They want to feel they have agency and are trusted to make meaningful decisions. Nothing says “we have too many processes” and “we don’t trust you” like adding a technical challenge to your interview process.

It should be telling that big companies all posture during their interview process as having a “startup environment.” They’re trying to look like a startup because they understand the why: that’s what employees want. Yet real startups constantly self-sabotage this natural hiring advantage. Seeming like a big company is what investors want, not employees.

What’s the harm?

The fact that there are justifiable reasons for some companies to use a technical challenge implies that there is in fact some value there. At least a minimal level of information about technical skill must be discernible by using one. So why not?

Filtering out your best applicants

As already discussed, bigger companies use technical challenges to filter their application pool, but unless you are drowning under a mountain of qualified candidates, this is a negative. This is especially true when you consider exactly who is going to refuse a technical challenge.

Candidates who are confident in their ability to find a job, value their time, and are being courted by several other employers are the ones who you are filtering out. It’s the best of the best — exactly the people you should be looking for.

As much as you might dream to be one day, you’re not Google, your name has no intrinsic value on a resume, and you can’t pay like Google can. Accepting a job with you is a risk every candidate is weighing. Spending their personal time to do a take home challenge for a job they may not even get an offer from is another level of risk on top of that, and the cost-benefit analysis on that often won’t weight out in your favor for the best candidates.

Juniors perform better than seniors

It is a commonly noted phenomenon that recent graduates and junior developers often preform better at a technical challenge than more senior and experienced developers do. This is easy to understand: those fresh out of school are used to this kind of assessment, which is not truly representative of actual work, and they are also more recently versed in the academic “gotcha” problems that are often included in these interviews, even though they rarely come up in actual development.

It should be easy to see why this is problematic.

Sending the wrong message

Recruiting is a two-sided game. While you’re trying to decide if the candidate is a good fit, they are wondering the exact same thing about you. You should keep this in mind during every interaction you have with a candidate. How are you presenting your company?

Information during this process, on both sides, is limited. Just like you are over-analyzing every phrase and mannerism of the applicant, they are doing the same thing trying to figure out what it is like to work for you. So what does the act of requiring a technical challenge potentially say about you?

Maybe you are extremely risk averse and overly strict about your processes — not the kind of environment I’m looking for when I apply to a startup.

Maybe you struggle to fire people and I’ll be working with a lot of sub-par peers.

Maybe you struggle with trusting your employees. After all, I’ve got 15 years of experience and you asked me to do a simple logic exercise to prove it. I wonder if micromanagement is going to be an issue.

Maybe you’re overly focused on technical purity. The technical leadership might have hard-headed beliefs about patterns and syntax, making working here less collaborative and open to new ideas than I’m looking for. Worse, they might struggle to implement quickly if they refuse to bend on technical best practices when appropriate, which means this startup probably won’t last long.

Maybe you have no idea why you’re doing a technical interview at all, and leadership in general at the company is lacking, and working there with be a directionless mess.

For any applicants reading this, I always recommend the first response when asked to do a technical challenge is “why?” — the answer is always informative, and will tell you where to focus if you choose to do it. For employers, make sure you have a good answer ready. You’re on your own in terms of what that looks like — I haven’t encountered it yet.

Wasted time costs you candidates

Almost any candidate worth hiring has another employer trying to sign them instead. As a startup, you can move quicker than bigger companies, and you should use that to your advantage. Every step you add to the process gives your candidates time to secure other offers. Even if that doesn’t cost you the candidate, another offer drastically reduces your negotiating position, and often costs you more money.

Technical challenges are often the slowest part of any developer recruiting process. Both getting the candidate to complete the challenge and having your team review it each take more time than an interview would. Meanwhile, the value is generally the lowest of any part of your process — you are essentially verifying what you should have learned from the resume, references, and technical interview.

Dropping this step alone will put you in a noticeably more competitive position in the market thanks to the efficiency gains in your recruiting process. As a startup, you should be nimble. Three weeks is exceptionally fast for a big company to turn around an interview process and deliver an offer. If you can execute your process in two weeks, you can catch the candidate before they’re close enough to stall for the offer from a company who can likely pay more with better benefits than you can provide. Additionally, an easy, painless process will often be seen as indicating an easy and painless place to work.

Diversity and inclusion

This is sometimes still sited as a reason for a technical challenge, but that thinking has been largely discredited. It is undeniably true that an interview can be heavily weighted by the unconscious biases of the interviewer. Acknowledging this, many companies moved from technical interviews to technical challenges as a way to try to create a more objective assessment. Unfortunately, the reality is that this traded an unconscious bias for an inbuilt systemic bias. Commonly cited groups which these processes work against are parents, the employed (a terrible group to filter out!), and people with reading disabilities, who are specifically discussed in more detail below.

Dyslexics make good developers

Roughly 20% of the population has some form of reading disorder. This means that one fifth of your applicants, for whom a technical challenge may take longer to complete than average, are likely to weight the cost-benefit of completing the challenge even more harshly, further reducing your candidate pool.

As a hiring manager, it’s tempting to think that this exclusion is a good thing. After all, who wants slow developers? However, there is evidence that people who suffer from reading disorders develop stronger than average abstract thinking, problem solving, creativity, memory, and empathy in order to compensate for their condition (this is found in adults but not children, pointing to it as a developed coping mechanism as opposed to a related genetic trait). These are exactly the types of skills that you want in a developer, and a trade-off for speed that is often worth taking.

In our industry, we are used to dismissing a certain level of communication and social difficulty as signs of autism which might indicate a heightened attention to detail or mathematical aptitude. It is not unreasonable to consider reading disorders in a similar way. Instead, as an industry we are sadly designing a gate-keeping system which pushes these people with a potential aptitude away from the field.

An alternative, if you must…

If you’re still not convinced and you still feel that you have some reason why your startup is a special duckling and really does need an extra level of technical vetting that your ability to fire people cannot compensate for, I have encountered one middle ground — what I call “The Reverse Technical Challenge.”

This involves screen sharing your code and walking the candidate through it. Specifically, focus on the problem areas. You know exactly where they are — show them to the candidate. Don’t try to hide them or see if the candidate can spot them on their own, that isn’t fair to expect of someone during their first look at a code base. Additionally, if they do spot it, they’re likely to think you didn’t, and hold it against you when comparing offers. Instead, point out the issues and ask their thoughts. Ask how they might approach fixing them or how they might have alternatively approached the constraints you were facing at the time.

This approach dodges most of the negatives involved with a technical interview, while still testing a candidate’s ability to read and comprehend real code. It also communicates to the candidate that your company is open and is able to identify its shortcomings. In my opinion, a verbal technical interview is still considerably more effective, but if your team struggles with that, this can be a good stepping stone while you recruit more qualified engineering managers.