5 Most Common Technical Interview Mistakes
I’ve given 50+ phone screens in the past year and a half, and there are similar patterns in many of the interviews that fail. As someone who’s been nervous on the other side of the phone, I thought I would write up a few of the most frequent reasons people fail to get a question, and how to correct them.
(1) Assuming the question has a fancy silver bullet.
When you’re interviewing for a generalist position at a software company, it’s pretty unlikely that their phone screen is going to require you to know what a Bloom filter is (although they are quite cool) and how to use it. And yet candidates consistently scrap OK solutions that aren’t quite optimized and start diving into crazy tangents. Just like in an actual programming job, save the complex and specialized data structures for situations where their usage is clear. There’s a reason why we’re all still using arrays (and merge sort) 70+ years later.
How to fix: use standard algorithms and data structures as building blocks.
(2) Ignoring interviewer hints and suggestions.
This one can manifest itself in a couple ways. The most egregious is when the interviewer makes a fairly clear hint such as “what if we used a stack instead of a tree?”, and the suggestion is either ignored or dismissed out of hand. As an interviewer, I’m trying to help you! There is no situation in which people will intentionally mislead you. When the interviewer makes an explicit suggestion, they are either trying to guide you along the right path or trying to have you prove that your current solution is optimal (in which case you’ll probably already know that your current solution is a good one). Regardless of which they are doing, just ignoring the hint won’t do you any good.
Occasionally candidates will take the hint, spend a little bit of time trying to work it into their solution, and then cast it aside and return to whatever wasn’t working before (or onto a new thing). If someone gives you a suggestion and you don’t think it works that’s fine, but you should have a clear explanation for why an alternative solution is better than the one suggested to you. Remember, we’re trying to help you get the right solution and we have the answer key, so it’s likely that our suggestions are going to be helpful (not to say that people don’t occasionally come up with great solutions that aren’t in the answer key).
How to fix: give any input from your interviewer strong consideration.
(3) Forcing a square peg into a round hole.
This ties into the one above, but candidates will frequently pick a solution early on and tack on enhancements for every problem that it has. If your answer doesn’t feel like a clean fit for the problem, then there is most likely a flaw with the foundation of your solution, not the wallpaper. Don’t be afraid to scrap your current solution (especially if you can articulate why it’s bad) and pick a new one. The right answer is usually also a fast one, so don’t worry about time constraints on that front.
How to fix: don’t be afraid to scrap a solution and try out something new.
(4) Diving too far into details right away.
This one doesn’t sink candidates immediately, but it hurts them in two ways. First, once they’ve described a solution in great detail they get invested and don’t want to change it, leading to problem (3). The bigger issue, though, is that it takes more time for the interviewer to figure out that it is a wrong solution. Interviewers will typically direct you away from wrong solutions and towards correct ones, so the faster they understand your solution the faster they can put you on the right track. Since interviews are time limited, it’s better to give a wrong solution in 30 seconds than in 5 minutes. And if the solution you gave is correct, or close to it, the interviewer can always prompt you for more detail.
How to fix: get it wrong or right quickly, then iterate from there.
(5) Filling the silence at all times.
I blame bad advice from college “how to pass a technical interview” seminars and online advice columns for this one. It is important to let your interviewer know what you’re thinking, but just rambling is bad. The same way none of us sit down at a computer and start coding instantly when presented with a problem, it’s OK to not start talking right away when presented with an interview question. Just saying something like “just let me think for a second” is perfectly fine and can give you 30 seconds or a minute to concentrate. For the reasons discussed in (4), don’t take too long, but 1 minute of silence followed by a correct answer is a lot better than 2 minutes of talking but no good answer. A brief silence also allows candidates to gather their thoughts and then present a coherent answer, which is definitely preferable to a jumbled answer.
How to fix: still communicate your thoughts, but don’t be afraid to organize them first.
Most of the candidates I interview clearly have enough knowledge to get our questions right, but nervousness or an unfamiliarity with how to present their thinking during an interview cause them to perform poorly. I think that by combining the tips in this article with a strong knowledge of CS fundamentals, you can pass the vast majority of technical phone screens.
If you’re interested in working at a company that prioritizes practical skills and critical thinking over trivia, check out Everlaw’s job page and shoot me an email.