Technical interviews, as they stand, are at best a proxy for finding people exactly like the interviewer and at worst part of the systematic discrimination plaguing tech.

We have very little idea about what makes good code, so it should come as no surprise that we have little-to-no idea how to find people who are good at coding, along with the dozens of complementary skills. Tech interviews boil down to finding “people like us” and a quick glance amongst any startups team page should confirm this.

Along with finding “cultural fits”, there is nothing more terrifyingly common than an interviewer trying to trick you, in order to show how clever they are. Interviewers love algorithmic puzzles, even though they are not indicative of the work at hand.

Aside: The Wason selection task is one simple way to demonstrate that the framing of a problem determines the ability of people to solve it.

In one interview I had, the lazy interviewer forgot the problem he’d googled five minutes before the interview, stumbled through it, struggling to remember the tricky parts I was meant to guess.

Other asinine things I have been asked in interviews include guessing “how much teflon is there in the world” (and they didn’t like it very much when I challenged them on the relevance of the question). I’ve also been sent a dodgy, pirated, 300 page pdf of interview techniques to prepare for a Google interview.

Despite being asked to reverse a linked list in almost every interview i’ve had, I have only ever used linked lists for two things: a) computer science exams, and b) interviews by people who passed the former.

Sometimes algorithms are indicative of the work at hand — natural language parsing, numerical methods — and sometimes a simple algorithm is used as a filter to check you can actually implement a simple, specified problem.

However, asking questions which require a trick to solve correctly only serves to filter out candidates who have heard of the trick before.

Most developer jobs require applicants to come into an office conference room and answer puzzle-style programming questions on a whiteboard.

There are entire books full of strategies for whiteboard interviews. They list the types of questions you’ll get & give sample solutions.

These books are for developers, & they exist because whiteboarding is a skill completely separate from actual software development.

I mentor students at several coding boot camps. Every single school teaches “whiteboard skills” as a distinct unit.

They teach it separately because whiteboarding is a skill completely separate from actual software development

From @sarahmei’s excellent series of tweets

The amount of bullshit questions you are asked in the interview is directly proportionate to the bullshit in the job. Places with interesting puzzles to solve can and will rely on your intrinsic motivation to put up with their dysfunctional and toxic environments.

I really wish Liz Rush’s amazing “On Interviewing as a Junior Dev” was around when I was starting out—It took me forever to realise that interviews are as much about you judging the company, as they are about the company judging you.

I know being able to pick your job is a privilege few have, and I’ve fallen into a number of toxic jobs to keep a roof over my head and food on my plate, but maybe I wouldn’t have started a job with the naïve belief that the interesting work would save me from burning out.

In the end, you shouldn’t look for jobs where just the technical problems are interesting, but also for ones where the people are friendly—the work you do is more likely to change than the culture you work in.

Don’t forget: the correct answer to “How do you reverse a linked list” is “Thanks for your time but I’ll see myself out”.