I have personally worked with CodersFirst to perfect their tech interview protocol, and I can tell you that every software engineer has bombed an interview at least once. Sometimes even very talented engineers make interview mistakes which, though apparently trivial, may very well cost them the coveted job they were applying for in the competitive world of tech.
The good news is that these slip-ups are relatively easy to rectify once you’ve learned to identify them. In this article, I will reveal to you the most classic rookie errors that are made in tech interviews, including live coding challenges, and what you can do to make sure you don’t commit them yourself.
Some of these you may know, others will be new to you, a few you may be making without even knowing. All can be resolved with a little bit of patience, effort, and willingness to change your ways.
So let’s get started!
#1 Neglecting your project(s)
Imagine inventing a car that can fly, and then trying to sell it without mentioning that it flies. If you worked on a really good coding project in the past, and then you fail to bring it up in your interview, that’s basically what you’re doing.
It is frankly astounding how many juniors will spend an interview boasting about their skills in the abstract, only to neglect properly illustrating their most recent/ambitious project. Yet that is exactly what should be at the heart of your presentation: explain what you created, which problems you faced, what solutions you came up with, how these solutions impacted the project, and what it is you would do differently in retrospect.
If you don’t have any project to talk about, then think of something you can develop and get to work. It’s the best thing you can do to prepare for an interview, and it is entirely possible to do that while simultaneously looking for jobs. I’d suggest joining an open-source project, for example.
#2 Overcomplicating your solution
I get it: you’re in the middle of a coding challenge, you want to stand out, so you’re going to try and wow the interviewer with the most sophisticated solution you can think of. This sounds good in theory, but the risk in practice is that you will get lost within your own intricacies. Even if you solve the problem, you might just confuse the person you were trying to impress.
A professional coding challenge is not the time to take that sort of risk. Unless you really know what you’re doing, stick to the requirements and look for a simple solution you can pull off elegantly.
A similar but separate problem is that of the coding language you choose to employ (assuming you’re given that choice). You may feel that coding in a trendy or hardcore language will make you look smart, and sure, maybe it can do that – but not if you have to Google basic syntax. Use the language that you’re most comfortable with; if you want to try something else, that’s fine, but make sure you’ve practiced beforehand – and practiced hard.
#3 Cutting too many corners
High productivity can be an extremely positive signal, but it’s much better to be slow and careful than to be both slow and sloppy. If you apply too many shortcuts, your solution can become a giant with clay feet.
Often I see programmers take one look at the problem before them, and then instantly start to code. That’s not a good idea. Writing code before giving a problem proper consideration is more likely to hinder than to help you find a solution.
Take the time to think about the question, consider the steps you need to take, draw out a plan. As you do this, make sure you explain what you’re doing to the interviewer – they’re there precisely to evaluate how you approach a problem, and you need to have them on the same page as you.
#4 Not following directives
Overlooking a stated requirement – or worse, deliberately ignoring it to come across as unique – is a double red flag. Not only will it make it harder for the interviewer to consistently score you against other candidates, it will give the impression that you’re someone who doesn’t work well with others. Employers want to know that they’re hiring someone who can deliver what the company needs, even if it’s not what they want to be working on at a particular moment.
If you want to stand out, do it at the end of the interview. You can bring up your favorite hobby, or a personal interest which makes you look smart or engaged. Even better, follow up after the interview with a thank you note. This small gesture can go a long way towards showing you’re personally and sincerely invested in the position.
#5 Not asking questions
I covered the importance of explaining yourself as you work. The reverse of this is equally important: asking questions. Some interviewers want to see how you’d code in a real project, paying lots of attention to design, others are just looking for speed and expect you to get to the end quickly. It is up to you to pull this and other relevant information from them, so don’t be shy.
#6 Thinking big, not small
Coding for a project is not the same as coding in an interview. The former involves working on a problem incrementally over weeks or months. In the latter case, most problems will be short and compact, designed to test a specific engineering skill.
You need to practice working on such small projects, even if their practical applications post-interview may seem limited. Also, you should be creating these small projects from scratch, as that’s what will probably be asked of you during the interview.
There are, thankfully, plenty of resources online that can help you get handy with the process. You can learn how to quickly solve unfamiliar problems on interviewcake.com and dailycodingproblem.com, while brilliant.org will teach you computer science fundamentals.
Remember that a developer who never stops learning is a developer who is never out of work. So keep on practicing, watch out for these common mistakes, and good luck now and always!
Alexandra Jozwik is Co-Founder and Diversity & Inclusion Advocate at Berlin-based hiring consultancy TALENTFIRST. She has worked with established tech firms like OLX and FRI:DAY as well as successful startups like Flowkey and LIV, and she co-developed the adaptive quiz and technical screening process for tech interviews at CodersFirst.
