Coding Interviews

Coding interviews are a ridiculous yet widespread practice used to vet candidates for software engineering positions. I, and many other skilled software engineers, believe that coding interviews should be abolished. Why coding interviews are bad:

• They select those good at coding interviews
  Coding interviews don't find those who are good at coding. They find those who are good at coding interviews. The typical coding interview assigns some random coding task. There are many websites, books, and github repos giving examples of these to select from. It is possible ( and often required to pass coding interviews ) to study such examples and refine your skill at doing small contrived coding tasks. This does NOT translate into being good at developing software. It translates to being good at doing small contrived tasks that have little to no business value.
• They are unfair to the shy and/or autistic
  Many different types of people do not do well at writing code while someone is watching them. It could be because they are shy. It could be because they are autistic and can't think clearly in such a condition. It could be for any number of various reasons, none of which pertain to how they will write code on the job.
• They are a form of random chance
  The chance that a skilled engineer can solve any particular random coding challenge quickly is random. Using speed of completion or how many different tiny challenges can be done in the time alloted as a determing factor in hiring is equivalent to rolling the dice on the engineer.
• They ignore past work history
  I've been writing software for over 20 years. I still get failed at coding interviews and told "you aren't good enough". I can write software fluently in 7 languages. I've written multiple enterprise level systems by myself. Ignoring this past and judging solely based on a coding interview is simply stupid.
• They encourage rote memorization
  Many common coding challenges exist. The solution to them is known. Many study to know these solutions. This is destructive to quality coding. Filling your mind with "the way things are done" will just result in more software getting created in the same way. We don't want more of the same. We want creative minds capable of coming up with unique methods. Those methods may fail at first and require a lot of iteration. Coding interviews discourage innovation and encourage simply doing things the way you are trained to do them in school ( which is a bad practice ).
• The environment is unrealistic
  They are typically given via a web based editor that is not setup to the way a skilled engineer is used to working. They don't have intellisense, or the users common macros, nor their favored live debugger. Not only this but use of a search engine is denied. All of these things are unrealistic and as such aren't a realistic test of an engineers ability to do their job well.
• They interfere with focus
  Many/most of those giving coding interviews say something like "please talk to me while you are coding so I can understand your mindset during the process". I understand why they want this, but it is not a realistic way to write code. It is possible it helps some people who think best out loud. For most engineers this is not helpful and will result in a sharp decrease in the quality of the created code written. If I take the time to explain why I am coding something a certain way, it destroys my ability to focus. The way my mind works is by thinking of many different approaches at once. Some of that is subconcious, meaning that I cannot communicate it even if I try. Trying to communicate such a thing just stops it from happening to begin with. Talking to an engineering while they are coding, or asking them to talk to you while they code, is a sure way to make them code worse.
• They rely on interviewer knowledge / perspective
  Unless the interviewer knows the language being written in well ( and better than the interviewee ), as well as the topic of the coding question itself well ( domain knowledge ), then the interview will be stilted based on the perspective and knowledge of the interviewer. I've been interviewed many times by engineers far junior to myself, and get judged negatively because the interviewers don't know the language I chose ( despite saying I can choose any language I want ), or because they aren't familar with the coding practices I am employing ( because it wasn't taught to them in school ). This is also a more general issue of having junior employees interview senior candidates. It is particularly bad in the case of the coding interview. A junior candidate will tend to hire other junior candidates because they like how those people "think like them".
• They favor verbal communication
  Coding is a written activity. Most technical tasks are written. Most work output is written. Yet the coding interview heavily favors verbal communication. Interviewers when confronted with this point will say "yes because we want to hire engineers with great communication skills". What they mean is "engineers with great verbal communication skills". See the problem here? The best engineers aren't great at verbal communication, nor do I particularly want them to be. I want them to be best at written communication. Why? Because written communication can be referenced easily later. Because documentation is important. Being able to give a speech about their code? That is not important. I've been told to STOP when I was writing information in text in the editor in a coding interview. I was told instead to tell them. That is a horrible and ridiculous practice which just ensures that what I was trying to communicate gets mangled by the interviewer's ability to comprehend what I was saying while I was saying it.
• They disfavor pattern recognition and application
  A huge part of software development is seeing how things are done, and then continuing the pattern. Another example is finding a good piece of code and then adapting it to do what you need. When you are assigned to work on an existing codebase, ability to understand what you see quickly and then add more similar code is important. The coding interview doesn't test any of these tasks, and actually actively disfavors those good at those things by focusing solely on scratch creation of new code from nothing. Very little software development is done in this way. Almost all software is created by adapting some existing thing, even if that existing thing is just an example code fragment for how to use a library function.
• Success criteria is hidden
  The specific "success criteria" for passing a coding interview varies from one interviewer to the next. There is no way to know what it will be. The criteria for passing one coding interview can be the criteria that fails another. An example of this: One interview may have the goal "the candidate needs to complete 3 mini coding challenges and get the correct output to pass". The next interview may have the goal "the candidate needs to focus on the coding challenge ( one ) and go into detail about how to refine and improve it, as well as create basic unit tests for it". Those two criteria are at odds. If you focus on either one you will fail the other. Because of this, passing a coding interview is a total crapshoot. You have to choose some perspective, and carefully watch the interviewer ( hopefully you can see them on video and hear them ), to determine if they seem to be happy with what you are doing. If not, you then need to shift gears fast to another method and hope you have enough time for it. Oh yeah, this also favors verbal communication and reading non-verbal cues from the interviewer. Guess who isn't good at this: Those who are autistic. Guess what, many engineers are autistic and coding interviews as a result are discriminatory against them.
• They lack a feedback loop
  This is also just a general problem with most interviews, but is particularly bad with coding interviews. Barely any interviewer/company will ever tell you exactly why you failed a coding interview if you fail. The reasoning if confronted about it is usually one of the following:
  • "If we told people they could sue us for our reason." A: Well, no. If you have a bad or illegal reason perhaps you should be sued. Sounds like you are just hiding the truth to keep getting away with bad practice.
  • "We have a standard process and if we share the details our process could leak and people could cheat the system" A: If your process fails to work if people know what the process is, then your process sucks.
  • "There is no direct answer. We have a holistic approach. We just get a yes or no from the interviewer." A: This is horrible. If your interviewers can't explain why they fail a candidate you should fire them and hire people who can interview candidates properly.
• They favor single language developers
  Suppose you have a developer who has written code in 7 different languages spread over 20 years. ( me ) Average length of time coding any specific language then is 3 years.

  Now suppose you have a developer who has written code in only one language for 5 years.

  Which developer do you think will impress more at a coding interview? See the problem?

  Diverse and flexible thinking is crucial for a software developer. Being able to code a solution to a contrived logical puzzle in 30 minutes really fast? Not so much. Coding interviews test for the wrong skills.

• They favor "yes heads"
  If you agree with the interviewer on all points, you are far more likely to pass a coding interview. If you disagree with the mentality or approach a coding interview interviewer wants or suggests, you are very unlikely to pass the interview. This is the opposite of what you want in a good software developer. You want to hire people who will defend their position and bring diversity to the way the software is being developed. Hiring a bunch of people who you agree with and do everything the same way you do will lead to terrible software.
• They favor junior developers
  A junior developer ( one just out of schooling or in first 2 years in the industry ) is heavily favored by the coding interview process. The reason is a mixture of above reasons. Senior engineers who have been writing code for 10+ years may either hate coding interviews or simply be terrible at them because they have focused on delivering business value through their code instead of fun puzzle solutions. Business software is incredibly dull and boring. The skills required to create effective software that makes the company money are very different from those skills that are used to pass a coding interview. There are jobs that use similar skills. They aren't typically senior roles. Requiring a coding interview for a senior role ( one requiring 5+ years of experience post education ) is nothing short of idiotic.