Are Coding Interviews Fair?

My not-so-simple answer to a pretty common question

This gist is called “Intense 2Sum,” and would not be accepted by most companies https://gist.github.com/curtcorginia/90ac594c022d37e4d8e3d9ac1c5a8bd5. If you find that code snippet strange, here is the short story it is from https://medium.com/@kurt.shibainu/interviewer-you-have-been-working-for-two-years-and-you-cant-even-2sum-16c185bc98f1

I have one blog that focuses primarily on software engineer interviews, while this one focuses mostly on personal projects — I thought it might be fun, for a couple weeks, if I tried swapping the two.

Are coding interviews fair? My opinion overall is that coding interviews CAN BE fair, if they focus more on thought process and problem-solving ability than on memorization. It gets a bit complicated from there, though, and every time I see anyone write about coding interviews I see three types of comments:

• One person on Medium responds to pretty much EVERY popular article about coding interviews to say that coding interviews are easy for him. Barring him…
• One group of people will generally argue that coding interviews are necessary, and not broken. They provide a fair standard, there is no better alternative, and they are much better than old brain teaser style interviews
• One group of people will generally argue that coding interviews are unfair because they are nothing like real-life coding

Unpacking JomaTech

If you have no idea what coding interviews are like, either because you are not in the field, you are new to the field, or you got your job at some company or in a time when things were not done this way, then this JomaTech video above is pretty great.

It’s also only about a minute long.

• 0:04: Joma claims to have solved 1513 LeetCode questions. This part is probably just hyperbole/parody, but many people ask how many questions they need to do. This InterviewNoodle article recommends solving as many as it takes to feel confident…100, 300, or even 1000. Yangshun Tay (creator of Blind75) recommends 100–200. I think your average person will certainly agree that LeetCode medium questions can take a fair amount of time to first complete
• 0:05: “Memorize all the answers.” A common argument is that everyone is just grinding/memorizing everything now in a kind of race to the bottom, perpetuating an endless cycle that makes coding interviews more difficult
• 0:11: “Read CTCI five times and Elements of Programming Interviews in three languages.” These two books are commonly recommended resources
• 0:17: Grokking The Systems Design Interview is an Educative.io resource that is for…wait for it…systems design interviews. These things are common for software engineers who have a few years of experience under their belts
• 0:25: “Go on LinkedIn to stalk my interviewer.” Like in any job, it can certainly help to get a fix on what an interviewer has worked on and is interested in. Even in a standard one-hour coding interview, you might get 10–15 minutes to just talk through your respective careers
• 0:33: Go on GlassDoor to check the interview questions they ask. I consider this underhanded, but many people interviewing for companies simply find coding questions on GlassDoor and memorize the answers
• 0:40: “Sketchy Chinese website to get leaked interview questions.” I think JomaTech may be referring to a specific, real website, but I’d rather not speculate on this
• 0:43: No comment
• 0:54: Cheat sheets. JomaTech once again makes a joke about “screen cheating,” in which interview candidates simply have resources open on other devices

Pros Of Coding Interviews

Pragmatic Engineer, former software engineer manager at Uber with a pretty large YouTube following, argues that coding interviews have no better alternative. They are easy to make fun of and complain about, but without them we would be forced to rely on metrics that are less fair…like who has gone to a certain college.

Another argument is that they are much better than the “brain teaser” alternative. To drive this point home, I will share with you a couple of questions I have actually received in software engineer interviews:

• There are three boxes, one contains only apples, one contains only oranges, and one contains both apples and oranges. The boxes have been incorrectly labeled such that no label identifies the actual contents of the box it labels. Opening just one box, and without looking in the box, you take out one piece of fruit. By looking at the fruit, how can you immediately label all of the boxes correctly? (Source)
• You have 3, 1, 3, and 6. Add operators to them to get 8. For example, 3 + 1+ 3 + 6 (which is not the correct answer, of course). Source

One advantage of coding interviews that I have not seen anyone else point out, maybe because it is too obvious, is that it is much easier to set up an environment in something like CoderPad. If you ask someone to work on a typical web app, there are quite a few dependencies. Even in an interview I thought was very good, in which the interviewers gave me an HTML file, a CSS file, and a JavaScript file, we still dealt with some differences in the console between browsers.

Cons Of Coding Interviews

• They do not accurately reflect what coding in the actual field is like
• Opportunity cost. The time people spend preparing for them could be spent building projects with real-world uses
• As much as books like Cracking The Coding Interview argue that doing well on them correlates with being a good coder, this point continues to be debated

Alternatives To Coding Interviews

Yes, these are all interviews I have actually had:

• Trivia. If you are interviewing for a C++ position, maybe they ask you about dynamic_cast and reinterpret_cast.
• Take-home challenge. For a web development position, I was once asked to take a day and use SWAPI to make a frontend application
• Realistic assessment. In an online test, I was given a code base, permission to use Google, and told to formulate an email about what an error message might mean. I will not name the company that sponsored the test because I think it was a bad test (it had some obvious errors in it), but I think it is a step in the right direction
• Multiple choice assessments
• Case study. They give you a large codebase and ask you to talk them through it
• Simply ask them to talk about interesting projects, then drill down and ask for more technical details. The more common themes you find between what they have worked on and what you are looking for, the more relevant your questions can become. Suddenly you are asking them valid questions about things like gRPC, or Vue.js, or whatever it is they claim to be experts in

A Longer Discussion

I got a pretty interesting comment on my other blog that I wanted to respond to:

The blog post referred to two pretty popular tech articles by Atwood and Spolsky, both of whom co-founded StackOverflow and arguably had a major role in what coding interviews are today. MY article, in spite of only getting claps from 17 people, was still one of my more popular things I wrote, with about 900 views (yeah, most things I write don’t get very many views). The comments were split right down the middle: People who argued against coding interviews, and people like the above.

• It’s not that surprising that an article from 16 years ago is out of date, right? That’s the FizzBuzz article by Jeff Atwood, which I very openly dislike. No, it’s not surprising that an article from 16 years ago is out of date, but it IS surprising that it still shows up as a top Google result when you look for coding interview information. It asserts that anyone who can solve FizzBuzz is better than 95% of programmers. Extending the logic of this comment, this would also mean programmers in 2022 who can solve “valid parentheses” are better than 95% of programmers
• You can’t assert that anyone who clears that bar is a good developer, but I don’t think anyone ever claimed that. Well, what Atwood was arguing at the time was that the ability to solve FizzBuzz put you in the top 5 percent. If you don’t think the top 5% of programmers are good, then that’s a different argument
• If YOU were trying to hire a software developer/programmer and they couldn’t even BEGIN to solve FizzBuzz, would YOU want to hire them? Do they know what mod is? FizzBuzz is basically a test to determine whether or not someone knows mod. Would they be able to solve the problem after I explained it? If it’s really such a baseline test, then that would already break it and the person would fail. Had this not been such a famous problem, I might argue that not every programmer uses mod routinely

What he gets to next is his best point: A coding test can be a great way to assess problem-solving ability. It should be treated in this way, instead of just being treated as a binary of who can spit out the perfect solution and who can’t.

Those four claps are mine. I am the one who claps

Closing Thoughts

3 -1 is 2, 2 % 3 is 2, 2 + 6 is 8, so the answer to that interview question is

(3–1) % 3 + 6= 8.

Ugh.

If you ever see that question come up on a software engineer interview, you’re welcome.

(3 + 1) / ( 3/6 ) = 8 also works.