Warning! Are You a Slow Programmer in Interviews

Warning! Are You a Slow Programmer in Interviews It starts with a simple question: does speed matter in coding interviews? The short answer is: yes, definitely. At Gainlo, weve 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, Im not saying someone is slow in typing. More generally, I mean people who are slow in coming up the perfect code. Ill explain this in detail soon. In this post, Ill 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. Its 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, dont forget to take the difficulty of questions into consideration. Also, remember that interviewers wont 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. Common mistakes If you have interviewed many candidates, youll notice that slow programmers share a lot in common. I wont 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 Ive seen. A lot of people like to start coding immediately after they have a vague idea, which is extremely terrible. I can easily predict whats 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 doesnt 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.. Im not saying that you shouldnt consider these issues. But its better to postpone this discussion after youve finished the simple solution. #3 Reinvent the wheel Sometimes you dont 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. Dont 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, its always better to figure out which is your bottleneck before the optimization. If you are slow to provide a solution, its very likely that you dont have enough practice. Once you have worked on tons of coding questions, youll come up with the right approach within minutes. In this case, I dont 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. Ive 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. Its totally different from “solving in your mind”. Practice with a timer if you are slow when practicing, theres no chance youll be faster in a real interview. Therefore, its highly recommended to put a timer aside when you practice with coding questions. Youll 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 Gainlos mock interview focuses on. Naive solution first Never hold back your solution when you think its too naive. What is highly recommended is to tell your solution even if its not concrete yet. For many interview questions, it wont be hard to come up with a basic solution like brute force. If you are concerned about whether its too naive, you can say something like “I know this is definitely not the optimal solution, but Id 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. Python 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 dont need to learn Python from beginning just for coding interviews. Using a language you are not familiar with does more harm than good. Summary Typing/writing fast wont save you much time. Whats 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”?