Technical interviews are insulting

Developers should say “no”

Recently, I’ve been coaching some mentees through the interview process for developers. What I’ve seen is insulting.

Companies are insulting developers one of two ways:

1. They ask for ridiculously time-intensive take home assignments
2. Whiteboard interviews that are useless for the candidate and interviewer

Let’s talk about the problems and why I recommend you turn down insulting opportunities.

Take home assignments

My rule of thumb: If a take-home assignment takes more than an hour (2 hours, max) and is unpaid, then you have better ways you could use your time.

Imagine an architect being asked to do a take-home building assignment. Or a surgeon being asked to do a take-home dissection. It’s ridiculous! These people are professionals.

As a professional developer, it’s insulting to be asked to do these silly assignments.

If every company asked for a detailed take home assignment, then your entire job search would be hours upon hours of free work.

Moreover, developers are in high demand! Companies need to learn that they are the ones recruiting highly-skilled professionals working in an in-demand field. The weight is on companies to prove why we should work for them, not the other way around.

It’s a red flag when companies don’t understand this reality and don’t respect developers’ time.

I know it feels like “losing” an opportunity when you say no, but I’ve found that being clear on your expectations and sticking to principle helps you avoid being taken advantage of and actually attracts the good types of opportunities who are looking for quality talent.

Whiteboard interviews

Interviews at a whiteboard are useless. They’re mostly “gotcha,” smarter-than-thou theater from the interviewer.

The whiteboard interview has no resemblance to the actual work of software engineering! Some examples:

• In simple cases where the solution is trivial, the interview is pointless. It wastes my time to answer fizzbuzz or some other small coding problem.
• In complex cases where the solution has to be uncovered, it’s a crap shoot whether I’m going to correctly solve the problem with the ideal algorithm under a time constraint.
• If you’re hiring me as a software engineer, it’s to make decisions about how to solve problems, tradeoffs in implementations, and deployment strategies. Solving some pointless algorithm on a whiteboard doesn’t show that.
• When I write code professionally, I use all kinds of tools to write clean, efficient code. Taking away my IDE, test runners, git commit hooks, etc only hampers my ability to solve the problem the way I would in real life.

Addressing the problem

So, what do we do?

The fact of the matter is that it can be much harder to walk out of an interview than to decline a take-home assignment. Each interview process becomes a question of where you draw the line.

In some cases, you might enjoy the conversation you’re having with the interviewer and find the problem interesting. Perhaps you wouldn’t mind solving it or at least attempting. Just be familiar with basic strategies, common solutions/structures, and practice talking while writing code out long-hand.

In other cases, when it’s clear that the interviewer has put little effort into the process, you might directly question the nature of the assignment. You might ask what relevance the whiteboard problem has to the work you’ll be doing at the company.

What can companies do?

There’s research to suggest that interviews in general are not helpful. Companies would be better served just picking names out of a hat.

The interview means you hire people who are good at interviewing, not necessarily people who are good at the job.

However, I don’t think companies will switch to resume lotteries any time soon. Most companies need some process for vetting candidates.

At my last company, I helped design our technical interview process. Here’s how it looked:

1. We took the time to build a sample application that showcased some of the data structures and problems we worked with at the company
2. The take-home assignment was to complete two functions within that larger sample application. We had already written tests for those functions, so you could do TDD and tell if your code passed.
3. When candidates arrived at the interview, we did a small code review of their functions (like you would review a pull request in real life)
4. Then, we asked them extending questions about their code: What if we wanted to make only one query to the database?, What structures and strategies might you use to cache this data?, What if the data set had millions of rows — would you need to refactor your solution?

We received positive feedback about this process because it directly engaged candidates with the problems we were solving at our company. When we hired someone, they started work on the first day with a (very basic) understanding of one of our core data structures.

The process also respected developers’ time while engaging in the higher level thinking about tradeoffs in code, refactoring, and approaches. We got a much better sense for what it would be like to work together.

More perspectives

It’s not just me complaining about coding interviews:

More resources

DeveloperPurpose.com — Building a software career with meaning & purpose

Working for FAANG is a terrible goal — Why you should avoid big tech

Join Medium & support my writing — Access to everything on Medium + support me and other writers you read