Programming Interviews Are Toxic

Letting YouTube do it’s autoplay thing I ended up listening to Joshua Katz 2014 Tedx Talk on the “Toxic Culture of Education.”

Now, there is a certain conspiratorial tone to his lecture, and by all means, I’m guilty of the same thing, yet I’ve seen what he’s getting at as a product of the public school, community college, and university systems in the US. And now I’m going to extend to a profession that I know more about — programming.

Before I begin, let’s state two things.

First, I have totally embarrassingly bombed tech interviews. Interviews in general. I’ve bombed a dishwashing interview. A number of reasons: didn’t realize what I was applying for, overestimated how much I knew, and yes, got flustered (or got drunk the night before) and messed up on standard things. The jobs I didn’t get, it was probably for the best.

Second, I have been interviewing people for 17 years. I have done bad interviews because of my own failings, and as such, I am sure I did not get the best candidates because I screwed up as a manager.

In other words, I’m not stating what follows out of bitterness or out of ignorance. We need to discuss the toxic nature of tech interviews.

To prime this, let’s talk about some of the worst questions I’ve been asked:

• At an interview for CSS bug fixing, I was asked about how to filter for prime numbers. Now I know there are some simple responses to this, but when pressed on limited data space and huge number testing, you have to resort to more complicated methods. These methods are rare for most programmers to have to do unless it’s specific to the field. This was for CSS.
• At another interview for Ember work, I was asked about the Separating Axis Theorem. Was a coincidence because I had been working on a game engine at the time, so it was pretty easy to pull the answer out. But had nothing to do with the job.
• A common question has to do with testing if two strings are anagrams. The simplest response is count up each letter (“anna” == 2 a’s and 2 n’s, “nana” matches that). But the cool computer science trick is to assign each letter a prime number, go through each string adding up the numbers, and see if their totals match (this way you can reduce your memory consumption for even insanely long strings and ones that involve characters greater than the 26 letters of the English alphabet, such as the 2^32 in UTF-32). These are popular questions on sites like Interview Cake and are nearly 100% irrelevant to the work at hand.
• Recursive questions. Now, not to toot my own horn, but I’m actually pretty good at these. I highly recommend The Little Schemer to learn more about the rules of good recursive design. Yet, in the last ten years, I’ve never seen a single line of code at any company that used recursive programming. Sure, maybe I wasn’t at companies that used it, but I was still asked.

These are all questions that are supposed to be “rockstar programmer” knowledge, but ultimately the questions require programmers to teach themselves to a test. Interview questions should simultaneously communicate to the hiring team the level of the programmer’s knowledge and let the programmer know the expectations of the job. If you ask questions that do neither, both come out ignorant no matter how well the interview goes.

Bit Manipulation and JavaScript

Thomas Figg in his talk at SXSW five years ago answered a few audience questions after his lecture, and was asked, “What language should I learn?”

In summary, Figg says JavaScript, because it’s in demand and is simple, and especially don’t waste your time with C just because you think it’s a hard language.

Well, how many interview books and online question preps, have questions on bit manipulations (a specialty of languages like C, but not so much JavaScript)? Does that come up often for the majority of tech positions?

Sure, embedded systems people, high-performance systems folks, I don’t doubt it, but for the most part, it never will. It just sounds like a smart thing programmers do. I’ve read Hacker’s Delight, got certified by the UW in embedded systems, and I’ve had that held against me as that I was more of low-level systems guy for front-end dev jobs after ten years of doing exactly that. So I knew bit manipulation and the number tricks involved. Lot a good it did me.

Nonetheless, seemingly every interview book has a section on bit manipulation. Sure knowing if that least significant bit is one or zero is a quick way to check evenness of a number, but so is “num % 2 == 0”, which is what you’ll do at work. Bits don’t come up much.

Objections

Now, I can already hear a couple objections:

• Maybe you interviewed at bad companies (Very true in a lot of cases)
• Interview books are trying to reach the broadest audience (Fair enough. Why are mind puzzles in these books as well? Which audience is that for?)
• Don’t study the parts that won’t come up if you know you’re interviewing for a JavaScript job

And that last objection is the kicker, and what I’m arguing.

Despite these topics never coming up in actual work, they come up in interviews.

This is teaching to the test, not trying to improve / evaluate skillset for actual real work, and moreover, as Katz draws out with students, programmers also become discouraged because of failing to know things that they don’t need to study and will never need.

This is even more harmful because there are jobs out there that most likely match a programmers skillset regardless of level and are also probably great environments for them. So the programmer misses out on fulfillment, personally and financially, and the company misses out on a great team member. It’s lose lose.

Can’t take the heat, random internet whiner?

This is very possible.

Yet, to borrow from the analogy, what if you ran a French restaurant and you tested cooks in interviews by asking them to make sushi? Sure, sushi is food, it’s good, it takes skill to make, but it’s a specific skill that will never again come up in a French restaurant (unless you work at Au Pied de Cochon).

So then what?

What concerns me is that interviews often reveal more about the company than they do about the interviewee. If a company asks unspecific questions about software and computer science, it may mean they don’t really understand what they’re doing either.

Because so much of the onus on the interviewee to be the smart and all-knowing one, it distracts from this simple point. The company doesn’t really know what it’s doing, where it’s technology is centered, where it’s headed, and furthermore, don’t seem to care about the interview process so just googled some questions.

Candidates should think about this a lot. As Figg says in the above video, if a company gives you a “brain teaser” in an interview, you should walk out. And we need more interview books and sites that admit this idea: you can just walk out or ask a response question like “What does this have to do with the job?”

The alternative is what we’re existing in — candidates who are sweating bullets not just to get that six-figure income, but to also not look dumb, and hiring managers who are simply covering their bases because that’s what their superiors told them to do.

How many CTOs have my tech friends met who don’t know how to code and couldn’t tell you what basic software tools do? If you’re a development manager, how much easier is it to simply say “I asked the questions from the book and they answered them right, so if they don’t work out, I tried my best” to a CTO who doesn’t know better?

After all, software is often one of the few businesses that is human capital intensive. Meaning, companies need you personally and your knowledge more than the computer on your desk.

So my advice is simple:

Candidates be professional, work hard, study what you enjoy, and be willing to walk out the door if you sense your time is being wasted.

It might be the most rockstar move you can pull as a programmer.