Technical Interviews: the 8 Most Common Mistakes Programmers Make

If you had the opportunity to analyze a large sample of coding interviews, and examine the relationship between subjects’ reported behaviors and the feedback they‘re given, would you dive in?

The reason anyone would do this is, if they could, which they can’t, would be because they could, which they can’t. (Pickle Rick)

We sure would, and we sure did.
We studied over 20,000 mock interviews that had taken place on our code interview practice platform, Pramp. We looked at peer feedbacks, the topics they’re clustered around, and the trends that were statistically significant.

The result: we unveiled the eight most common mistakes software engineers make in technical interviews on our site, and developed a set of rules to avoid them. Some good and easy interview prep advice!

You’ll find the experiment’s methodology at the bottom of this article.
Note that mistakes are listed by their prevalence, not severity. We’ll have a separate blog post about the latter.

Let’s begin with the bird’s eye view:

#1: Jumping To Code Before Sketching Out The Solution

Prevalence: 20.66% of all feedback given

Diving into writing code before fully thinking out the solution is a recipe for a failure. The problem with a half-assed, half-baked solution is that by the time you realize that what you’re trying to do is too complicated or doesn’t work, you run out of time.

Whether it’s the nerves or overconfidence that makes you rush into implementation, hold your horses. You’re likely to do more harm than good if you think you can figure out the solution as you code. This hardly ever ends well.

Advice: Start by explaining your thought process, and thinking out loud about how to break the problem down into simpler pieces. When you are ready to begin, write pseudocode to clarify your approach. Along the way use examples to spell out key steps in your algorithm.

Only after both you and your interviewer agree that you have a good solution, proceed to implementation.

You should also mention the brute force/naive solution early on before you’re writing anything. There are several reasons for this. First, it helps you avoid any awkward silence moments while you’re still trying to figure out the optimal solution. Second, a brute force solution can sometimes lead to an optimal one by optimizing parts of it. Lastly, as an engineer, your prime directive is to code a solution that works. Correctness takes precedence over efficiency.

If you find yourself lost and can’t seem to make any progress, here’s some great advice on how to get unstuck in technical interviews.

#2: Weak Computer Science Fundamentals

Prevalence: 20.05% of all feedback given

Like it or not, most coding interviews today still revolve around data structures & algorithms (DS&A) problems. This is true for startups and pre-IPO companies like Dropbox, Airbnb, Uber & Palantir, and certainly for giants like Google, Facebook, Amazon & Apple.

You may be an exceptional practical programmer, but if your command of core DS&A is lacking, you’re unlikely to get the job that you want. Yes, this sucks, but that’s reality.

Advice: Carve out some time and brush up on/learn data structures & algorithms. Not only will this help you ace your coding interviews, but it’ll also make you a better software engineer. Good grasp of basic DS&A should be part of any software engineer’s toolkit.

Apart from Pramp.com, here is the list of the resources we recommend:

1. A great Coursera course that covers the essential information that every serious programmer needs to know about algorithms and data structures: Algorithms part 1, Algorithms part 2
2. “Cracking Coding Interviews” by Gayle Laakmann McDowell is a good book, which has problem samples, solutions and explanations on how different companies approach hiring.
3. Two good free preparation courses dedicated to helping you succeed in coding interviews are:

• Technical Interview Prep Course by Udacity & Pramp
• Mastering the Software Engineering Interview by Coursera

#3: Being Quiet

Prevalence: 15.80% of all feedback given

Interviewers aren’t Jedi and can’t read your mind. Sure, you might be anxious and your thoughts aren’t particularly coherent, but if you can’t muster the courage to talk, forget about passing interviews. It’s not enough to explain your approach to solving a problem you’re given at the beginning of an interview. You’re expected to communicate at all stages, including during the implementation and testing of your algorithm.

Advice: It’s a common cognitive bias to exaggerate the extent to which our thoughts are apparent to others, so err on the side of over-communicating. While performing a task, walk your interviewer through your steps and reasoning. Talking and coding at the same time doesn’t come naturally to many of us. Fortunately, there’s a great platform that helps you practice exactly that :). If it’s anxiety that you feel prevents you from verbalizing your thoughts effectively, you may want to try out these techniques to calm yourself down.

#4: Poor Command Of Programming Language

Prevalence: 12.56% of all feedback given

You may have great problem solving skills and algorithmic thinking, but that won’t be enough if you don’t know the core constructs, functionality, and syntax of your programming language of choice. To clarify, nobody expects you to remember by heart the interface of some esoteric data structure that is used once in a blue moon. It’s perfectly fine to google the answer in this case. We all do that.

However, if you’re struggling with elementary things like, for example, memory management in C, inheritance in Java, list comprehensions in Python, or closures in JavaScript, then that’s a nonstarter. While this is a mistake that typically beginners do, it also exists among academics who have deep theoretical knowledge, but scant hands-on engineering experience.

Advice: If you have the option, always interview in your strongest programming language. Interviewers are often flexible and would allow you to choose the programming language you want to interview in.

If this isn’t the case — for instance, if you’re interviewing for a Frontend position where JavaScript is required — do yourself a favor and brush up on your programming language skills beforehand.

Learning from books won’t cut it and you need to get your hands dirty. Program a few projects, contribute to open source, or better yet, do both.

Learning by doing is really the only way to go about mastering a programming language. Need an idea for a project? This simple Google search query will provide plenty.

#5: Not Using Tests

Prevalence: 10.33% of all feedback given

Not running your code through test cases is missing out on crushing your interview. For one, it is very common for code to fail in some specific test cases. Dry-running your algorithm with few examples will allow you to spot bugs and address them early on.

Also, you may come up with an original solution that your interviewer hasn’t thought about. By showing, with examples, how each variable is changing at every line of code, you make it much easier for the interviewer to understand that your solution indeed works.

Hiring engineering managers love test cases. In fact, for some of them not using tests is an outright deal breaker even if you reached to the right solution.

Advice: There are three times during the interview where I’d recommend to use tests. The first time is right after your interviewer finished asking you the coding question. Use an example or two to verify you understood the question (see #6 below for more details). The second time is after you sketched out your solution. Use a non-trivial test case to walk your interviewer through your pseudocode and to validate its correctness. Finally, once you’re done implementing your code, dry-test your code again to make sure you don’t have any bugs.

#6: Misunderstanding The Question

Prevalence: 9.11% of all feedback given

Of all the mistakes here, this one is the easiest to avoid. It’s therefore quite surprising that in ~9% of all interviews, candidates still make it. There isn’t much really to elaborate here.

If you misunderstood the interview question or made assumptions about the problem statement or input that you shouldn’t have, it’s likely that you’ll fail your interview.

Advice: The first thing you must do after your interviewer finished explaining the question is to repeat it back to them in your own words to validate that you understood it correctly. If you got it wrong, they’ll tell you. Doing this simple thing will spare you from the costly error of answering a completely different question. An error that we sometimes realize we’ve made only midstream when there’s no time left to change course.

While repeating the question, bring up few simple examples of input, and make sure you are correct about the expected output. It’ll make it easier for your interviewer to know whether you understood the question. The other thing you want to do is ask whether you can make certain assumptions. For instance, you can ask whether you can assume the input is valid or within a specific range. Or, depending on the question, ask whether the input is sorted. Lastly, it’s also a good practice to clarify with your interviewer whether they want you to optimize for time or space.

#7: Ignoring Edge Cases

Prevalence: 8.31% of all feedback given

Overlooking edge cases may be an indication for inadequate problem solving skills. First off, if your algorithm doesn’t handle all valid inputs, your solution is incomplete. Secondly, by not considering edge cases, you miss out an opportunity to come up with a better algorithm that eliminates the edge cases. For instance, in the Find the Missing Number problem, one straightforward solution is to subtract the sum of the input array from the total sum of (1,…, n). However, for a large enough ’n’, the solution will fail due to Integer Overflow. Being aware of this edge case forces you to think of a better solution. And indeed, by using the bitwise operator XOR, we can devise a solution that is no longer susceptible to overflowing (refer to the second solution in the link above for more details).

Advice: Use tests around the boundaries of your algorithm’s input. If your algorithm fails on some of these edge cases, check first if you can fix your algorithm by introducing some quick incremental changes to it. If you can’t, ask your interviewer whether you should handle these edge cases. If the answer is yes and you can’t seem to think of anything, engage your interviewer and try to solicit their help to guide you in the right direction. For further advice on eliminating edge cases, refer to this nice blog post.

#8: Sloppy Code

Prevalence: 7.69% of all feedback given

Technical interviews aren’t just about correctness and efficiency. It’s also about your coding style. Your code may be fast and bullet proof, but if it’s only you (and perhaps God) who can understand it, good luck getting an offer.

Hiring managers look for engineers whose code is legible, maintainable and idiomatic. Code that other team members can pick up from where you left off easily.

This issue is prevalent among beginners, language switchers, and competitive programming participants. Here are some styling mistakes you should avoid:

• Giving random/non-descriptive names to variables, functions, etc. Some cringeworthy examples: using single character names for non-index variables. Or calling your function ‘func’. Competitive programing developers especially need to be careful here since they’re used to using super short names in their programs in order to code faster. This won’t work in tech interviews.
• Inconsistent coding style. While everyone has their own style of programming and we should accept it for what it is, mixing randomly coding standards is never a good idea. It signals sloppiness. For instance, employing different naming conventions. Or using tabs in some parts of your code and then in others spaces. You could be either on camp Richard or camp Winnie, but not on both. Similarly, if you put braces on the same line, don’t later put them in a new line. Other examples abound, but I think you get the point.
• Using defensive coding, such as NULL checks and lots of special cases, without really stopping to think about whether they were necessary. This leads to more complicated code that is hard to understand and debug.

Advice: I’ll keep it short. Use your common sense to give descriptive names where applicable and choose one coding standard and stick to it during the interview. Also, you want your code to be idiomatic. Otherwise, it may raise red flags and your interviewer could start doubting your proficiency in the coding language you chose for the interview.

Conclusion

If you made it thus far in this article, you may have noticed that a large percentage of all mistakes candidates make in technical interviews has little to do with technical skills. In fact, the non-technical mistakes (#1, #3, #6) comprise 44% of all mistakes.

This is yet another evidence showing that interviewing is a fundamentally different skill from programming. And it matters, since many experienced software engineers feel they don’t need to prepare for interviews. This is a big mistake, which explains why fresh out-of-college candidates often do better on technical interviews than experienced ones.

Moreover, don’t expect to do well in interviews if you only practice by solving coding challenges by yourself. To succeed, you’ll need to practice the whole gamut of a technical interview.

This is what we do at Pramp. We provide a comprehensive mock interviewing platform, free of charge. It has helped thousands of programmers ace their coding interviews. Are you ready for the whole interview experience?

Methodology

To identify the mistakes and calculate their frequency, we looked into users' performance data from the last 20,000 programming interviews conducted on Pramp.

Some background first. Pramp is a free peer-to-peer mock interviewing platform for programmers. In simple terms, we match software engineers over a video chat and collaborative code environment to practice programming interviews together.

Every such interview session is b-directional. That means that both peers interview each other in the same session. One of them gets selected randomly to go first as an interviewer and then after 30–45 min they swap roles — the interviewer becomes an interviewee and the interviewee becomes an interviewer.

At the end of the interviews, peers give structured feedback on each other’s performance on multiple of dimensions, such as problem solving, code quality, communication and more. The feedback form also includes two text boxes where participants describe what their peers did well and what they should improve. In our analysis, we looked at the latter.

The first step in our analysis was to find out recurring “mistake categories” in users responses for the “What wasn’t as good?” question in the feedback form. For that purpose, we selected randomly 1,068 interviews out of the 20K interview dataset. At that sample size, the results are statistically significant (95% confidence level and less than 3% margin of error). We then proceeded to categorizing manually these 1,068 responses.

We identified nine categories. Eight of them are the ones mentioned in the article. The 9th category was “Other”. This category included feedbacks that either didn’t say anything meaningful (e.g. “You did an excellent job. I have nothing to add”, “N/A”, “Nada”, “Nothing I can think of”, etc.), or that indicated an issue whose frequency wasn’t statistically significant (for instance, ~1% of all feedbacks were about peers’ coding speed). In the calculation of the mistakes prevalence we excluded all feedbacks that fell under the “Other” category.

Assuming that Pramp interviews are a good proxy for real technical interviews (no reason to believe otherwise), the 1,068 sample size is also representative of the overall “population” of technical interviews in the real world.