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 Grokking the Coding Interview: Patterns for Coding Questions 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:
- 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.
- 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):
- What project are you currently working on?
- What is the most challenging aspect of your current project?
- 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.
Here's another story. 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 whiteboard, 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 you 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 you did 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:
- Grokking the Coding Interview: Patterns for Coding Questions.
- Grokking the System Design Interview.
- 3 Month Coding Interview Bootcamp
If you liked this post, 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.
Top comments (10)
Please ignore this article, and this comment.
Not really. Some good points are made. But this kind of absolute articles don't do good to anyone.
Never assume what your interviewer wants. Please just stop assuming that interviewers want short or long answers. You will need to find your way to what the other person in front of you wants.
We all misunderstand things. Point number one shows that we don't know what the interviewer really wants.
Do whatever you want. It is a whiteboard, you can erase things, evolve, do pseudocode first. You have an editor in front of you? Much better. Just do something. Think loud, because again you don't know what the interviewer is looking for, so you better dump whatever you're thinking.
Sean said it better in another comment.
Test, check, run. If you're in a whiteboard test you cannot "run" your code, you're the cpu of your code, you better run it. Not only you will find bugs, but you will have some time again to explain your solution.
As an interviewer.
Tell the people what you want and stop them if they're talking to much. Direct them to the topics you're interested.
No, the candidate didn't misunderstand the problem. You didn't explain it correctly.
You've seen this problem 100 times in 100 candidates. Perhaps this candidate sees the problem for the first time. Understand that. I know you like the problem, but it is your... BIAS, do not force into the candidate.
Sean said it better.
Drive the candidates to speak loud about the solution they've implemented. If you arrive to the end of the interview and you haven't told them to speak or asked any question and expects them to say anything... you might have set the wrong expectations.
And for candidates.
If your interviewer is not clear about how much detail of things they want... they might not care at all about the interview, you, or whatever you end up doing in that place if you get hired.
If you make a wrong assumption and the interviewer is there to point at you at the end and say "HAHA", you might not want to work in this kind of environment where everybody is waiting you to FAIL to punish you.
If your interviewer is looking for their solution, you might want to run away from a place where there is no alternative ways. Sooner or later the "my way or the highway" will push you out.
You might not want to go to a place where they do not evolve software.
Back to point two, you will miss things, but if the interviewer is waiting for you to fail, it might not be a good sign of culture and environment.
Thank you for this! All of your points make sense. :)
Disagree with 4. As an interviewer (for Amazon), I will never accept a candidate without a working solution. But I will accept a candidate who writes down the brute force and then walks me through a better solution. I've failed many candidates who tried to come up with the perfect algorithm and ended up empty-handed.
Glad you revealed Amazon uses the similar idiot technique for an interview, this solidifies my opinion that I will NEVER want to work for Amazon if it cares so little about it's employees that their test is a fucking toy programming test.
If talking to me doesn't convince you I know my shit, you're doing a bad job at interviewing.
Totally agree with you, Sean. It was geared towards candidates who don't even try to find the solution and become content with the brute-force solution. Some candidates don't even try to come out of their comfort zone and that's a red flag.
IMHO both are red flags: candidate who writes only the perfect solution, candidate who writes only the worst solution.
The solution should be a way to discuss (and learn) as many things as you can.
4 is tricky. I am also an interviewer and agree with Sean. Some working code is more important to me than the optimal version. But I don't work at a tech company and my department is producing code that runs mostly in batch jobs. We do have an upper time limit, but as long as the job is nowhere near this limit, we don't waste time on optimizing code.
However when I applied recently for a job at a tech company I focused on delivering a working solution with a test case. It had O(n). My interviewer wanted me to optimize the code and I came up with an O(log n) solution. But it wasn't good enough. I got declined. Directly after the interview I found a clever solution with O(1) on SO.
But I would never decline a candidate in an interview who doesn't find the clever solution, as long as I can talk about optimizations with him and see that he knows this stuff.
agreed.
It's crazy to me when people seem to constantly give advice on how to do at shitty interviews, when really the answer is that if you are put in front of an interviewer who doesn't understand the "gibberish" you're talking of, you're talking to the wrong person and the company doesn't care about you -> apply for a job somewhere else.
"Your interviewer is calibrated on a certain question and expects you to come up with the optimized solution to get a Hire" and "If she’s asking for a solution with linear time complexity and O(1) memory complexity" are also great red flags on places that don't give a shit about how talented, or passionate you are, or how quickly you learn actually relevant things. You can do better, apply for a job somewhere else.
This is a very helpful article. Thank you!