In the IT industry, a Coding Interview is the ultimate test to prove that you are worthy of a position in the company you have applied for. Interviews aren't easy, as a lot of things are at stake when you sit with the recruiter for an hour trying to impress them. They require full attention and you should be at the peak of your coding abilities to solve whatever problems interviewers throw at you.
When I was in my final year of college, I had the chance to sit for tech interviews with several IT companies. Some interviews went very well and some horribly wrong. But what mattered the most? The lessons that I learned after each round of interviews. After every interview, I became more confident in my technical abilities and communication skills.
Interviews made me realize what worked and what did not. It was key for me to work on my negatives, rectify my mistakes and polish the positives in order to present a better version of myself the next time I share the table with an interviewer.
Everybody talks about what to do in a coding interview but seldom discusses what NOT to do and things to avoid. In today's article, I will highlight 5 common mistakes I made during a coding interview and how you can avoid them.
1. I Rarely Asked Any Questions to the Interviewer
A coding interview is not a one-way street. You need to be prepared to ask all sorts of questions! After all, a problem you don’t fully understand won’t be solved by racking your brain trying to come up with the best solution. And I am not talking about the "Do you have any questions for me?" part at the end of the interview.
When you sit for a technical interview, you will be asked to write code. And to find the solution, you need to comprehend the problem well. I have seen many people jumping right into the editor to type the solution and end up giving a non-optimized solution to the problem. I did the same too. In my early days as an interviewee, I always felt that time is short and the faster I write the solution, the more chances I will have of getting selected. This was where I lost the game. Me rushing to type the code made the other person feel I was over-confident.
The interviewer does not expect you to give prompt answers, especially if you are a fresher. Instead, they expect you to understand the problem well and come up with a quality snippet of code that is optimized for both time and space. For that, even if you feel the need of asking questions to the interviewer to get a better understanding of the problem statement, then please do it.
You may not understand the problem well at first, and it is normal. Normalize asking questions and seek clarity on what needs to be done. You might also end up getting a hint or two in the process!
2. I Was Shy About Communicating My Ideas
You’ve written the code. Great job. Now it’s time to explain the idea behind your code. Problem-solving abilities are tested in interviews and your thinking process should be conveyed loud and clear to the interviewer. In an interview, you don't sell a solution. If you are asked to invert a binary tree, do keep in mind that the interviewer already knows the different ways to solve it. So it is not the solution he is looking for, it is your thought process behind the solution that matters.
When I was asked to write programs, I used to write the code on a piece of paper, dry run it once and proceed to type it in the editor. What transpired in between, was a few minutes of silence which the interviewer did not like at all. The tempo of the interview might have started on a good note, but here it became boring and frustrating for all. Companies value your communication skills as much as they value your coding prowess. The key here is to be as lively as possible and for that, you need to communicate with the interviewer.
3. I Failed to Focus on the Time/Space Complexity of Code
This is what I learned during my failed interview at HashedIn. In the coding interview, the interviewer started off by asking me to sort an array of 0s, 1s and 2s. Now there is more than 1 way of doing this, but I knew only one approach. I straightaway typed the code and compiled it without errors. Where I bit the dust was when the guy on the other side of the camera told me to write an optimized code for the same problem. I was blank. Little did I know about DNF sort then!
Coming up with a solution is good. Improving the existing piece of code for space and time is better. When you are given a code to write, it is always preferable to start off with the brute-force approach. After writing the brute-force approach, you should communicate with the interviewer and let him know that you can take some time and think of ways to optimize the same code for enhanced performance. And if you are able to optimize it, then chances are that the interviewer is already impressed with you.
Can't I save time and jump directly to the optimized code?
You can, no one's stopping you. But writing a time and space-optimized code involves a complex use of Data Structures and Algorithms and you may end up making a mistake. So the safe bet is to start low and climb your way up the ladder.
4. Pretend to think when I Don't Know the Answer
It is perfectly alright if you don't know the answer to a problem, but only if I had realized this before...
We are humans and so are the people who take your interviews. We don't have the power to know everything in this world and the interviewers know this very well. When you are asked a question and you don't know the answer, simply say that you don't know. I might end up embarrassing myself in front of you, but 1-2 years back, I used to do these head-scratching, deep-thinking antics to make the interviewer feel that I forgot the answer momentarily.
Now here's the thing - you are not the first person to be interviewed by that particular interviewer in his career. He/she has the experience to understand the body language of candidates. And as a result, you will not be considered for further rounds if you mumble or pretend to think. This wastes the interviewer's time. Instead, be very straightforward with your actions.
5. Not Writing Readable Code
This is one mistake I kept on doing again and again in interviews till one of my seniors pointed it. During interviews, I used to write code which was not readable. No, I was not typing in Hebrew, but I never gave appropriate names to variables or wrote comments in my code.
It is important to understand that apart from correct answers, the presentation of code matters as well in coding interviews. In organizations, people work in teams and over there it is mandatory to write code that is easily readable by others.
The code you write while solving a problem is the result of your thought process. If you want the reader to understand what you did, you need to write code that is easy to read and understand. Software has become more complex over the years. This has led to an increase in the amount of complexity in code. This has also led to a decline in the readability of code. A readable code is one that has a well-defined structure with a clear separation of the different parts of the code. It also has good indentation and is free of code smells.
Here's an example of poorly written code...
And this is what readable code looks like...
Readability is achieved by following these rules of thumb.
- Code should be well-structured and visually appealing.
- Code should be free of syntax errors and have a minimal amount of whitespace.
- Code should be free of code smells.
Conclusion
A coding interview is a great opportunity for you to showcase your skills, confidence, and level of expertise you have when it comes to coding. It's also a chance for you to see if this company is a good fit for you and if you'd be a good fit for the company as well. Don't let the pressure and excitement of a coding interview intimidate you. Be confident in your skills, and you'll do just fine!
