A Nightmare on Bug Street
How to deal with bugs during a coding interview - or better - how to not get them at all.
Imagine being on a coding interview. You hear the interviewer explaining the rules and then you read the problem. You feel that you understood it well and come up with, what you believe is a pretty good solution. Then, when you finally get to the part when you press RUNyour world collapses as one by one, each test case returns red, fatfalse. The time is ticking and you standing there, devastated and all alone with a bug that you have no idea how to find, not to mention how to fix.
Getting a bug is probably one of the most terrifying experiences you might get during a coding interview. Maybe except for having no idea what the problem is even about, especially when you are very stressed and anxious already. Will you be able to find the bug? What if your algorithm is all wrong? What if you misunderstood the problem and have to do it all over again and you run out of time? The problem usually doesn’t lie in your capability to find a bug as you wouldn’t probably have any problems with finding it in the comfort of your own home but to do it under pressure, within the given time restraint, and often in front of a total stranger. This obviously comes with a certain level of stress that for many may be particularly challenging to handle.
Needless to say, there are countless techniques you may find handy to help you to be less anxious such as breathing or meditating. I, however, would like to focus on approaching this problem from a different angle, namely how to find the bug, how to fix it, and how to do whatever one can to avoid getting bugs in the first place. Equipped with this set of techniques, I believe you can approach any interview with confidence that you can recover from a challenging situation.
How to avoid getting bugs?
Understand and solve the problem before coding
The first and the most important rule to avoid getting bugs is to understand the problem correctly. You want to have some kind of method such as PEDAC (or any other problem-solving approach) that provides you with steps that you can follow. In the nutshell it may include: understanding the problem, writing down the requirements, writing down the algorithm, and finally coding the solution. Without a structured approach that will allow you to dissect the problem and plan before going to the coding phase, you may miss some important requirements and rush to solve the problem you don’t understand fully. The crucial part here is to solve the problem before writing the single line of code. We don’t solve problems with code. We solve problems using logical thinking and the code is just a syntax that helps us to explain to the computer how to implement our solution.
Write an algorithm and test your code
Writing a good algorithm is crucial. It’s a step-by-step plan on how do you intend to solve the problem, what data structures you are planning to use at each stage along the way, and how to translate your solution to computational language. Once you are ready with your algorithm you can test it with some test cases by checking if you are able to predict what each line of your algorithm will return. If you are dealing with some nested data structures you can even write down what data structure you’re expecting to get. Particularly nested structures may be confusing and it’s helpful to have a visual representation of how the structure will evolve as the code progress. You can test how your code will behave with several test cases to make sure you didn’t miss any important edge cases in your algorithm. Knowing how your code will behave will allow you to feel that you are in control and that your solution work as expected even before you write any code.
For example:
[[1,2], [3, 4], [5, 6]] => {1:2, 3:4, 5:6}// iterate through nested array [[1,2], [3, 4], [5, 6]]
// - on each iteration: [1,2] .. [3, 4] .. [5, 6]
// - take first element (1) of inner array and assign it as a // key of an object, assign second element (2) as a value
// {1:2, 3:4, 5:6}
Write code and test it all the time
Once you are done and feel comfortable with your algorithm it’s time to move on to writing the code. You can then take advantage ofconsole.log in order to frequently test if the output values are the same as the expected ones. Testing the code as often as possible will help you to see exactly where the bug is hiding and fix it before you move to the next line. After completing the code (or bigger part of the code) it may be helpful to run through it once again explaining out loud what you intended each line to do, which can benefit spotting small syntax mistakes.
While coding, we tend to establish certain patterns that we then unconsciously repeat without realizing that they may be the source of potential issues. For example, some of us may forget the parenthesis or the return statement, while others may misspell variable names. A good piece of advice is to create a small checklist with the most common mistakes and run through it quickly before running your code.
What if we get a bug anyway?
You have done all of that but there it is, the red strings of characters appearing in the console lightening up. An error message! Your blood pressure raises, your palms start to sweat, you start seeing in front of your eyes the whole miserable life you are going to have… Stop for a moment and take a few deep breaths. The last thing you want to do here is to jump back in the code immediately searching for the bug, refactoring, rewriting, and testing different options without understanding what caused it. It may seem that you are getting closer, and just want to do a ‘quick fix’ but in reality, you’re ‘hacking and slashing’ and for the interviewer, it looks purposeless and chaotic. Let’s be honest, we all have been there! Before you waste your once-in-a-lifetime opportunity to impress the Google interviewer or score A+ on the assessment, start with asking yourself a simple question: what type of a bug is it?
Identify the type of a bug
According to my own, non-official bug classification which was invented purely for this purpose, I distinguish two types of bugs that may be encountered. It’s very difficult to recognize them when you are under pressure but identifying the type is the key to fixing it.
The first type is what I call ‘Nice Bugs’. It may be a simple syntax problem, misspelled variable, missing semicolon. Those types of bugs would usually (but not always) be indicated by an error message. Most of the time those types of flaws can be handled easily and gracefully. The error message would most likely give specific enough information to fix the bug effectively such as what type of the error it is or where exactly in the code it appears.
The second type of bug is what I call ‘Nasty Bugs’. Those are the ones that although seem innocent at first, can foretell your great defeat. You approach them with confidence to shortly feel getting partially blinded and deprived of 3/4 of your mental capability. Usually, you would not get an error message. You would just get an unexpected output or return value. Maybe the returned data structure is not what you expected. Maybe you get many more elements of an array than you counted for.
The reason why this is so crucial to be able to recognize between those two types of bugs is that you want to handle them in a different way. A ‘Nice Bug’ is usually an easy fix. Missing parentheses? No problem, just write them down. Coma instead of a point? No biggy! You can calm down! You will be fine!
Nevertheless, the Nasty Bugs are the ones you want to watch out for. They will take you by surprise, and if you just let them, chew you up, and drag you with them to the darkest abyss of confusion. They appear usually undercover so they may easily be mistaken for Nice Bugs, so watch out for them!
How do you figure out the type of bug?
First of all, try to understand where the bug comes from. If you’ve got an error message, that’s great! This will give you some extra information that may be handy, such as the number of the code line that caused the error, as well as the type of error.
The three error types that you will get most of the time are ReferenceError, SyntaxError, and TypeError.
- The ReferenceError means that the variable that you are trying to reference doesn’t exist. Either you haven’t declared it yet or you’ve misspelled the name.
- The SyntaxError is the one that is caused by syntax mistakes like lacking parentheses or missing semicolons.
- The TypeError appears most likely when the data type you are using is something else than you expect. You can easily check that with the
typeofoperator or just console logging the value.
Make sure you are familiar with all the different error types, the error messages they produce and what do they mean. If you can understand what caused the error and you can quickly fix it (within 1 min) without making big changes to the code then that’s fine! Go ahead!
However, if you still don’t understand what is the problem after doing all of that or there was no error thrown, you will need a different approach.
Check what each line returns
Try to test your code and go through each line one by one explaining out loud what this line of code is doing and what it returns. Then use console.log in order to test if you get an expected result. Do that until you find the problematic line of code.
Analyze the code and understand why is the expected value different from the returned value. Once you understand the cause of the bug you need to ask yourself a question: “Did I follow my algorithm or did I make mistake in the algorithm?”. You can compare your code with the algorithm to make sure that it reflects it precisely. If the bug is small such as returning the whole array instead of just the last element it should be an easy fix. However, if you clearly see that the issue lies in the algorithm itself it means you got a ‘Nasty Bug’! There is only one way to recover from it, and no matter how painful and uncomfortable it may be at that time, you need to GO BACK TO YOUR ALGORITHM. If you get a nested array, expecting a string and you have no idea where it comes from it’s probably because you have a mistake in your algorithm or maybe you didn’t understand the problem correctly.
Fix the algorithm
In order to fix the problem with your algorithm, you most likely need to go back to the beginning, and ask yourself the following questions:
- Are you sure that you got all the requirements correctly?
- Did you understand the problem?
- Does your solution solve the problem?
- Which part of the algorithm doesn’t produce the expected result?
Depending on the answer to those questions you might need to redo part or the whole algorithm and again test it very well before moving on to code again. Even though this may seem like a time-consuming process, it gives an impression that your approach is structured and your code is well thought out.
Being stressed during an interview is a very natural feeling especially when we care a lot. We need to accept that we will not do our best in a situation like this but at the same time, there are certain measures we can take to prepare ourselves as best we can. Having a structured ‘contingency plan’ in case of unexpected bug attacks will help us to stay calm and overcome even the most blood-curdling nightmare.
