It starts with a simple question: does speed matter in coding interviews?
The short answer is: yes, definitely.
At Gainlo, we’ve helped many people analyze why they failed interviews based on their performances. One thing surprised me a lot is the huge percentage of slow programmers in these people.
When I say slow programmer, I’m not saying someone is slow in typing. More generally, I mean people who are slow in coming up the perfect code. I’ll explain this in detail soon.
In this post, I’ll tell you how to check if you are too slow in coding interviews and provide advice to help you speed up. Remember that you only have 45min in an interview, every minute counts!
Am I too slow?
In a 45min interview session, you will have few minutes for introduction in the beginning and few minutes for questions at the end. As a result, you only get ~35min for coding questions!
Generally, interviewers will expect you to solve 2 questions per interview. Depending on the difficulty, you may need to write solid code for at least one questions.
Therefore, honestly ask yourself whether you can complete 2 coding questions within 35min. If the answer is no, you should definitely need to speed up.
It’s worth to note that some interviewer will only ask one coding question but with a bunch of follow-ups. If you are trying to evaluate whether you are too slow in an interview, don’t forget to take the difficulty of questions into consideration.
Also, remember that interviewers won’t let you know if you are slow. If you used up all the time for his first question, usually he would just say he finished all his questions although the second one never got a chance to ask.
If you have interviewed many candidates, you’ll notice that slow programmers share a lot in common. I won’t talk about people who get stuck in interviews as the best solution is to practice more and be better prepared.
#1 Write code before having a clear mind
This is the most common mistakes I’ve seen. A lot of people like to start coding immediately after they have a vague idea, which is extremely terrible.
I can easily predict what’s gonna happen next. The candidate will start coding and get stuck very soon as he needs to figure out a bunch of details. He may keep fixing his code for a while. At one point, he notices that the whole approach doesn’t work and he has to erase everything from the whiteboard.
This wastes tons of time although it looks like he moves fast! Spending few minutes to discuss your solution with interviewers is definitely worth the time.
#2 Over optimization
In other words, some people tend to complicate the problem. They will consider a bunch of production issues that is not necessary for simplified coding questions. For example, they may consider things like security issue, dead lock, integer overflow etc..
I’m not saying that you shouldn’t consider these issues. But it’s better to postpone this discussion after you’ve finished the simple solution.
#3 Reinvent the wheel
Sometimes you don’t actually need to implement everything. For instance, some common sorting algorithms or binary search are not required to code from scratch.
Do ask interviewers whether you really need to implement them. If the question is not focused on these algorithms, most likely you can just use them for granted.
Don’t worry if you find yourself a slow programmer. Here are some advice that will help you speed up.
Identify your bottleneck
Usually there are two parts of a coding interview – coming up with the right approach and writing solid code, it’s always better to figure out which is your bottleneck before the optimization.
If you are slow to provide a solution, it’s very likely that you don’t have enough practice. Once you have worked on tons of coding questions, you’ll come up with the right approach within minutes. In this case, I don’t have any better suggestion than practicing as much as you can.
If you find yourself slow to finish coding, you should really write solid code for every question you practice with. I’ve seen so many candidates who came up with an approach quickly but failed to finish the code within the whole session. Do write solid code (NO PSUEDO CODE!) while practicing. It’s totally different from “solving in your mind”.
Practice with a timer
if you are slow when practicing, there’s no chance you’ll be faster in a real interview.
Therefore, it’s highly recommended to put a timer aside when you practice with coding questions. You’ll realize how different it is for sure.
You may feel nervous or maybe excited. Either case is likely to slow you down. The point is that if you can mimic the same environment as a real interview when practicing, you should get a better chance. This is exactly what Gainlo‘s mock interview focuses on.
Naive solution first
Never hold back your solution when you think it’s too naive.
What is highly recommended is to tell your solution even if it’s not concrete yet. For many interview questions, it won’t be hard to come up with a basic solution like brute force. If you are concerned about whether it’s too naive, you can say something like “I know this is definitely not the optimal solution, but I’d like to mention that…”.
The biggest advantage is that you successfully proved that you can solve the problem at least with some approached. Also, the naive solution acts as a starting point, which helps you to keep optimizing it.
In addition, communication plays an important role in coding interviews. Even if the idea is vague, thinking loudly can be helpful to form more concrete ideas and interviewers are also likely to discuss more about it.
This tip is absolutely optional but I still want to mention here. If you are familiar with Python, do consider use it in coding interviews.
The simple syntax sometimes can save you a lot of time, especially compared to Java.
Again, this is optional so that you definitely don’t need to learn Python from beginning just for coding interviews. Using a language you are not familiar with does more harm than good.
Typing/writing fast won’t save you much time. What’s more, bad handwriting may confuse both interviewers and yourself.
Also. never sacrifice your time of thinking and discussion as we said before. Moving slowly but steady is the best way to speed up.
Any other ways to be a “fast programmer”?