How (not to) fail a coding interview
Common mistakes developers makes during coding interviews and how to avoid them.
Hi Friends,
Welcome to the 110th issue of the Polymathic Engineer newsletter.
This week, we talk about coding interviews. Every software developer knows that such interviews are hard, regardless of their level of experience.
Most people don’t get that these interviews are a different game with respect to their daily work and require specific preparation. As a result they keep repeating over and over the same mistakes.
Below, we will discuss the most common blunders peoples do during interviews and see how to avoid them.
Project-based learning is the best way to develop technical skills. CodeCrafters is an excellent platform for practicing exciting projects, such as building your version of Redis, Kafka, DNS server, SQLLite, or Git from scratch.
Sign up, and become a better software engineer.
Not understanding the problem
The most common error candidates make is rushing to solve the problem before fully understanding it. But in a coding interview, clarity is your best friend. Don't be afraid to take your time with the problem statement because it will save precious time later.
A trick to be sure you are on the right track is to rephrase the problem in your own words. This is helpful for two reasons: it clarifies your understanding and shows your communication skills. If there is any misalignment, your interviewer will correct you right away.
Not asking questions
Once you've rephrased the problem, don't stop there. A lot of candidates wrongly assume they have all the information they need. But coding interviews as real-world problems are often fuzzy around the edges. Don't hesitate to clarify any part of the problem that seems unclear.
Some good questions that can can significantly impact your choice of algorithm and data structure are: "What's the expected range of input values?" or "How large can the input be?"
Another crucial question that is often missed is whether to optimize for time or space. There is a trade-off between the two, and knowing which is more important can guide your entire approach.
Not planning before coding
It's tempting to start typing away, trying to impress the interviewer with your speed. But coding interviews aren't just about reaching the solution, they're about showing your problem-solving process.
Before you write a single line of code, take a moment to figure out where you want to go and where you are starting. This might seem clear, but it's easy to lose sight of the big picture during an interview.
Sketch out a high-level algorithm first, and then start working on the details. This approach not only helps you solve the problem more efficiently but also gives the interviewer insight into your thought process.
Breaking down complex problems into manageable steps is a crucial skill in software development.
Not thinking out loud
One of the biggest mistakes a candidate can make is staying silent all the time. Even if it is natural to want to concentrate quietly, your interviewer can't read your mind, and they want to understand how you think.
Thinking out loud might feel unnatural initially, but is a crucial skill in an interview. Start by talking to the interviewer about the solution you're proposing. Explain your reasoning, discuss potential approaches, and share any concerns you have.
As you start coding, keep the narrative going. Explain what you're doing as you write each line or block of code. This doesn't mean you need to describe every semicolon, but give a running commentary on your thought process.
When you've finished writing a piece of code, take a moment to walk through it and explain why you made certain decisions. Maybe you chose a particular data structure for its efficiency, or you did something to handle an edge case.
These explanations show your depth of understanding and ability to make reasoned technical choices. It's not just about showing off your skills but also showing that you can clearly explain technical ideas.
Not using hints
Thinking out loud is important also because it allows the interviewer to provide hints or steer you in the right direction if you're going off track.
However, some candidates are so focused on their own train of thought that they miss these cues. Others think that using hints somehow diminishes their performance. The truth is that interviewers don't give hints to trick you or to make the problem easier.
They are trying to see how well you can incorporate new information and adjust your approach. When interviewers give a hint, take a moment to pause and really consider what they are saying.
Maybe it allows you to optimize your code using a different data structure or more efficient algorithm. Or maybe it helps you find an edge case you hadn't considered.
In any case, make sure you communicate how you're using the tip. This shows the interviewer that you're not just doing what they say without question and are actively using new information to solve the problem.
Not testing the solution
In real development, writing code is only part of the job. Being able to test, debug, and iterate on your solutions is equally important. After you have written your code, don't wait for the interviewer to ask you to test your code – take the initiative.
A good way of doing it is by running through your code with both normal inputs and edge cases. For instance, if you're working with an array, test it with an empty array, an array with one element, and a larger array.
As you're testing, tell what you're doing, why you chose each test case and what you expect the output. This shows that you're thinking critically about potential scenarios and not randomly trying inputs. Edge cases are particularly important. By proactively testing them, you show foresight and attention to detail, which are valuable software development skills.
If your code doesn't work as expected, don't panic. This is actually an opportunity to showcase your debugging skills. Try to understand why it's not working as expected. Are you off by one in a loop? Did you forget to handle a specific case?
Even if you can't immediately fix the issue, showing that you understand why it's happening and thinking carefully about your code is valuable.
Not knowing Big O notation
Big O notation is an important concept that describes how well an algorithm works based on the size of the input. Interviewers use it to evaluate if you understand the efficiency of your code and if you can analyze and improve it.
Learning about how common algorithms and data structures use time and space is a good starting point. For example, you should know the Big O notation for operations like searching and inserting in arrays, linked lists, hash tables, and binary search trees.
But it's not enough to know the theory; you need to be able to use it in your code. As you prepare for the interview, practice figuring out the complexity of your solutions in terms of time and space, and get ready to explain your choices.
During the interview, if you're asked to optimize your code, consider how to improve its Big O complexity. Can you reduce a nested loop to a single loop? Can you use a more efficient data structure? Identifying and eliminating inefficiencies in your code is a valuable skill.
In real-world scenarios, the difference between an O(n) and an O(n^2) algorithm can be the difference between a system that scales and one that crashes under load.
Interesting Reading
Some interesting articles I read the past week:
Premature jumping to the problem phase can lead to a mediocre solution or, even worse - not fixing the root cause of a problem.
Great tips Fernando!