Software engineering interviews are certainly something, aren’t they? A potential employer reviews your accomplishment, sees the code that you have contributed to open source projects on GitHub, and things seem to be going great. Then, the technical interview appears. It’s all down hill from here.

Does this sound familiar? I’m sure it does to many of you, and you shouldn’t feel bad about it. The majority of technical interviews as they are given today are garbage. There are some companies that do them well, but most of them do them bad. For this entry, I will be focusing on the companies that do them poorly, and describing why they are so terrible.

The technical interview of today is often nothing more than a bastardized I.Q. test.

Have you ever noticed that coding interview questions are often needlessly complicated and do not reflect anything that you would ever do on the job? Me too. If you have noticed this, it means you have actually worked in the field. Many of the questions are based around syntax-correctness, memorization of random API method signatures, and very specific algorithm implementation details. This is cute for trivia night, but it means nothing in the context of the job.

A fun analogy: For my friends in the arts, let me give you an analogous example question that you might be asked if your technical interview were written by a hiring software engineer.

“You have a photoshop document with two layers. A base layer that is black, and a top layer that is white. A masking layer is added to the white layer and the white layer is set to 70% opacity. If you were to make a stroke with the brush tool on the masking layer with the color set to black at 50% opacity, what would the resulting color be in the hexadecimal format? It is OK if your answer is off by a few octets.”

If your first thought here was “who cares about this crap? I could figure it out in two seconds on the job with the color picker tool,” then your mind is in the right place. Indeed, who cares.

The majority of modern day technical interviews are nothing more than an I.Q. test for candidates under a different name. Which, by the way, was decided by the Supreme Court to be scumbag behavior. They tell you nothing about an individuals ability to do the job well, but they do give you potential hints as to how wealthy that person may have been during their upbringing.

Ever wonder why there are countless books on how to “crack the coding interview” and training businesses built around these draconian interviews? Now you know. It’s because they have nothing to do with the job. It is extracurricular work. It is an entirely different skillset.

I’ll leave this one with a hot take, some exceptions apply:

“The engineer that spends their all of their time engineering is not qualified to pass an interview.”

The technical interview does not pass empathy test, because it was not made for humans

There was an interesting study done by someone way smarter than me that I think applies here. It is called the “Illusion of Transparency” which describes how humans tend to over-estimate how much of their own mental state is known by others. This happens in interviews a lot as it is, and it is even worse during the technical portion for engineers.

This concept, sometimes referred to as the “curse of knowledge”, seeps deep into the minds of interviewers everywhere. The interviewer that walks into a technical interview with all of the answers cannot “un-know” what they are about to present to you as a test. Their frame of reference is warped, and more often than not, technical interviewers have no desire to be empathetic to those who they are interviewing. To the interviewer it is simple and easy, because they already know the answer going in. The interviewer has the curse of knowledge. This bias can lead an interviewer to see you as a poor candidate despite the test being inhospitable to how humans actually think.

So why design an interview like this if it sucks so bad? Why ignore all of these biases? Well, it comes down to good ol’ corporate number crunching. These questions are hospitable to corporate timetables, as the fruits of the test can easily be placed into black-and-white boxes for quick assessment. Frankly, in these situations, the individual giving the interview does not have to care. They know the hyper-specific answers. If you also know these answers, you’re in. If you don’t, you’re out. Indeed, interviews like these are designed to benefit corporate schedules at the expense of merit. Remember this at all times.

Keep in mind that if you were to put a technical interviewer through their own interview process with a different question set of a similar design, there is an exceedingly good chance that they would stumble just as quickly as anyone else. And yes, this would happen to senior engineers, and even high level architects. The best of minds cannot compensate for the worst of tests.

If during a technical interview you stumble when being asked to point out some simplistic syntax error, or you forget some random API signature, don’t beat yourself up about it. Do not define yourself by a bad test. Keep your head high and keep searching.