Is writing a working algorithm enough to get selected? Does it matter if you are writing a clean code in an interview? From my experience of taking interviews for more than 8 years, clear communication and clean code also matter!!
Why put an extra effort apart from learning algorithms?
There may be hundreds of candidates prepared for the role for which you are giving interviews. Most of the candidates may have prepared through stressful competitive coding and in-depth system designs. Then what are the things which can differentiate you from other candidates? The answer is to show best coding practices in the interview rounds themselves.
How to have clear communication and clean code?
Clear communication and clean code come from regular practice. Thus, at the time of coding preparation, always practice code as if you are giving a solution to the real interviewer. This mocking of real interviews is really helpful in the long run.
Below are few best practices which I believe can give you extra points in each step;
- Thinking out Loud
- Ask all the doubts and communicate all assumptions
- Proper variable names
- Extracting out functions
- Avoiding multiple if-else
- Input variables validation check
- Code readability
- Code complexity
Thinking out Loud
While giving the interview score, most interviewers think about how they felt when candidates were solving the given problem. If the interviewer feels like left-out or like an outsider, it would be a red flag for the interviewer for selection. This feeling may be interpreted as if you (candidate) are a lone wolf and always like to work alone, instead of as a team.
The best way to solve problems in the technical coding interview is to consider the interviewer as your team-mate and start the discussion around the given question.
Communicate your thoughts clearly, each next step, assumptions, bottle-necks, and blockers. Having loud thinking in an interview will let your interviewer be part of your problem-solving journey and they will pitch in whenever you are going off-track or making any wrong assumptions.
Ask all the doubts and communicate all assumptions
Most interviewers believe in giving a one-liner problem statement. They want to see if you can check the lack of required information. The key to winning the interviewer here is to start the discussion on the problem itself. Start thinking about the details of the problem. For example, if the problem is related to the random number generator, then question if there is any input to this generator, or how frequently this generator is used.
Asking questions about the given problem statement will help you get a clearer picture of the problem. Also, if there are any assumptions then practice writing them before implementing the algorithm.
Proper variable names
Naming a variable is among the hardest task for a programmer. But this is also one of the most important tasks. A proper variable name not only increases the readability of the code but also avoids any confusion in the middle of the interview.
The best way to have proper variable names in an actual interview is to use proper variable names while practicing code for the technical interviews.
Extracting out functions
Even if you wrote a proper algorithm, the interviewer may find it confusing if it extends to more than 20 lines. Also, repeatable code in the solution signals the lack of an eye for detail.
You can think of your solution as a combination of multiple sub-solutions. Thus you can extract these sub-solutions and keep focusing on the implementation of one sub-solution at a time.
Avoiding multiple if-else
Multiple if-else is the enemy of a good code. It not only hampers the readability but also shows a lack of design patterns skill. Multiple if-else can be easily replaced with switch cases or with a suitable design pattern. For example, if we are creating objects of the same parent class in different if-conditions then we can use a factory design pattern.
Replacing multiple if-else with design patterns is not an easy task in an interview.
It is very important to point out the presence of multiple if-else and the scope of an improvement.
Input variables validation check
Always make a habit of validating the input variables of the function. Some of the well-known checks are;
- Null check.
- Is string not null, empty or spaces.
- Is number valid and in given range.
- Is object valid and has all required properties.
Writing a readable code is an art, especially in a coding interview. The main reason to have a readable code is to keep the code simple and not get confused with your own code.
One best way to maintain code readability is to start with comments which can act as a pseudo-code for you and the interviewer. Also, appropriately name each variable and function.
Code is not complete if its performance is poor. Thus always revaluate your code to check if there is a scope of improvement. One way to check the poor performance is by getting the time and space complexities of each step.
The best place to learn and practice complexities is chapter 6th of “Cracking the coding interview” book. It explains the complexities well and also has practice questions.
Lastly, I want to suggest to you that coding practice is possible from many platforms but also focus on writing clean and efficient code that can differentiate you from other coders. If you want to understand the Clean code deeply and implement it in your daily codes, then check the “Clean Code book by Robert C. Martin”. It will make you an extraordinary programmer.
You can also use platforms that can connect you to the existing FAANG employees.
You can find an article on How to crack Microsoft interview in just 2 months here
You can find an article on how to prepare and ace system design interviews here.