How NOT to succeed in your 45-minute coding interview

I recently published a post How NOT to design Netflix in your 45-minute System Design Interview?. First, surprisingly, it got pretty popular. Secondly, and even more surprisingly, several people reached out to me asking if there are any tips on what NOT to do during their coding interviews. Most of these people had the questions along the following lines:

I’m not succeeding in programming interviews EVEN with months of preparation.

Some of these candidates had solved 200–300 coding questions, so the typical “practice more” sort of feedback wasn’t going to work for them.

The following post is focused on what NOT to do during the interview. If you are looking for programming or design interview preparation resources, look at:

Coderust 3.0: Faster Coding Interview Preparation using Interactive Visualizations and Grokking the System Design Interview.

Both as an interviewee and as an interviewer, I’ve noticed that there are a few, mostly non-technical, practices that can increase your chances of succeeding in the interview. Many of the following suggestions are based on my experiences and mistakes that I’ve made (yes I’ve had my fair share of goof-ups and rejections).

Here are the top 5 mistakes that candidates usually make (in my experience).

1. You spend too much time talking about your current and past projects

Interviewer walks into the room and asks ‘What are you working on at your current company,’ and you spend the next 10 minutes describing your current project in excruciating detail.

From your perspective, this is your chance to tell about the outstanding work that you’ve been doing for the past two years. You start describing the nuances that no one can understand OR you fancy that you can spend a lot of time talking about your current projects and get an easier question (won’t happen).

Instead of impressing the interviewer, you just wasted 10 minutes of your 45-minute interview. Your interviewer is also your fellow engineer and it might be hard for her to cut you off in the middle of your speech.

She just asked about your current project as an ice-breaker and was hoping that would spend a couple of minutes describing your current projects and then she can ask the coding or design question.

Remember two things:

1. Even if you wasted time at the start, you are still going to get the same Dynamic Programming question that you wanted to avoid. You just now have ten minutes less to solve that problem.
2. She is not going to give you a HIRE because you almost solved the problem and ‘could have done better had there been more time.’ That never happens.

Following are 2 examples of what not to say while describing your current projects (warning: nonsensical descriptions below on purpose):

“In my final year (or capstone) project, I built a web app that used MongoDB to store travel data from the most famous tourist destinations in the world and can match you with the other travellers from Mars who are going to be on the same spaceship as you landing first in Greece and then in Australia all for the price of a Starbucks non-fat latte”

“I am working at Microsoft in Visual Studio Debuggers team where my team is responsible for the bootstrap instructions that are executed right before the debugger is attached to the process looking at the permissions that are set on the process by the administrator. There can be 3 set of permissions based on the SKU of Windows-10 and those permissions can be configured by an administrator or a parent, and administrator can also add custom ACLs on the process which are then applied when the process is run under the credentials of that user … iggily biggily woopie doo”.

The above answers seem gibberish (because they are). I deliberately wrote these incomprehensible descriptions just to make you realize that your interviewer did not understand a word of what you said.

You are trying to explain nuances of a product, in a few minutes, on which you have worked for months or years.

Instead, the answers could have been:

“I developed a travel app that connects like-minded tourists travelling to the same destination. OR

“I work on the debugger team in Visual Studio and have worked on the various aspects of attaching the debugger to an already running process.”

The above answers are short and straightforward. More importantly, it gives the control back to your interviewer, and she can continue with the dynamic programming question that you’ve been trying to avoid. Good news is that now you have ten more minutes to solve that problem.

Whenever you go for an interview, have 1–2 lines answers ready for the following questions (and the interviewer can ask for more details if she’s interested):

1. What project are you currently working on?
2. What is the most challenging aspect of your current project?
3. What was the most difficult bug that you fixed in the past 6 months?

In short, manage your time. You are a no-hire by default, and you’ve 45 minutes to prove otherwise. If coding on the whiteboard is the task that’s going to get you a Hire, you should be spending as much time on the whiteboard as possible.

2. You don’t fully understand the problem

I have a story to tell here. A few years ago, I was looking for a job and giving tech-screens. Somehow in every tech screen that I gave, I was asked to ‘reverse a linked list.’

Not sure why but somehow I give the vibe that I wouldn’t know how to reverse a linked list.

When the fourth hiring manager asked me about reversing the linked list, I didn’t even bother pretending that I hadn’t heard this question before. I went to the whiteboard and wrote the code (in probably a couple of minutes). When I finished, I looked at my interviewer. He was smiling (well, almost laughing). He said that he was going to ask me to ‘print a linked list in reverse order’ and not ‘reverse a linked list.’ Ouch.

I knew I had made a mistake. As a joke, I told him that I was going to print the linked list after reversing it and then reverse it back to restore the original list. I also told him about why I’m getting allergic to this question, and we both laughed. If I remember correctly, he still let me go to the next round.

For most of you, not understanding the question might not be that dramatic (because hopefully, you would be listening to the interviewer a tad bit more carefully than me). However, I still see candidates jumping to the solution when I know that they don’t have all the data. It is not a good idea. First, you are now going to waste 10–15 minutes before realizing the gaps in your understanding and then you would have to change your code drastically.

An example would help, you might say. A story I have. I was once trying to solve ‘Rotate a Linked List by the given rotation factor.’ As soon as I heard the question, I started solving it WITHOUT realizing that the rotation factor could be -ve as well to indicate a rotation in the opposite direction. Ouch again. Trying to rewrite the code from scratch after wasting 15 minutes wasn’t fun, to say the least.

3. You jump to coding hastily without fully solving the problem

Here’s a fun-fact about coding interview problems. These problems are known as ‘toy problems.’

Good thing about toy problems is that the solution is rarely more than 15–20 lines of code.

Now, if I ask you to write 20 lines of code on the whiteboard, it would take you 2–3 minutes. Hence, if you had spent 30 minutes figuring out the solution, you would still be able to write down the code within time.

However, you are nervous and apprehensive. Your mind is telling you to start coding ASAP. Instead, tell yourself that writing code for a toy problem is never an issue. It takes a few minutes. You should be spending as much time as you need to nail down the solution and then start coding. Dry-run your solution with an example before jumping to code. It will also allow your interviewer to nudge you in the right direction if you are off-track.

In short, understand the problem and then spend ample time figuring the solution without worrying about writing the code. Once you’ve thought out the solution, it shouldn’t take a lot of time.

4. You code the brute-force solution first and then attempt the optimized solution

Harsh truth. Your interviewer is calibrated on a certain question and expects you to come up with the optimized solution to get a Hire. If you’ve read the above points, you would know by now that wasting time in activities that won’t get you a hire are not in your favor. Instead of trying to _put some code on the whit_eboard, spend that time in figuring out the solution. If she’s asking for a solution with linear time complexity and O(1) memory complexity, anything less optimized won’t result in a hire.

5. You don’t test your solution

Once you’re done coding, test it with an example. It will allow to find bugs before the interviewer has to point them out. Every time, your interviewer has to give you a hint to find the bug, you lose some points. Often, you would realize the typos and missing edge cases as soon as you walk through your code with an example. Also, not testing your code sends a negative signal so test your code even if you are 100% sure about your code.

BONUS: Asking how did you do in the interview

It probably won’t have a negative impact on the hiring decision, but it does put your interviewer in an awkward position.

Good luck with your interviews.

Again, if you are looking for programming or design interview preparation resources, look at the following resources:

1. Coderust 3.0: Faster Coding Interview Preparation using Interactive Visualizations
2. Grokking the System Design Interview

If you liked this post, click the 💚 sign and follow me for more posts. If you have any feedback, reach out to me on Twitter.

Fahim is the co-founder of Educative. We are building the next generation learning platform for software engineers and instructors. Learners learn by going through interactive courses. Instructors can quickly create and publish interactive courses using our course builder. If you are interested in publishing courses or knowing more, feel free to reach out.