Can You Make Mistakes During Coding Interviews?
Preparing for the software engineer technical coding interview is a daunting and tedious task for everyone, myself included. It doesn’t matter if you’re interviewing for an intern position or a senior software engineering position. All software engineering candidates for tech roles, typically up to management roles, are expected to do coding interviews.
With coding interviews being a large weighted portion of the interview process for many junior and mid-level software engineers (less for the more senior position you’re going for), it’s understandable to start wondering about what mistakes are acceptable and unacceptable during a coding interview.
During a coding interview, you’re allowed to make mistakes like syntax issues and calling a wrong function by name, but it’s all context-dependent. Coding interviews aren’t strictly evaluated based on you having working code. Instead, you’re evaluated on positive vs. negative signals.
In this article, I will go over my experience as a software engineer with making mistakes during coding interviews. I’ve interviewed at companies with LeetCode-style interview questions various times in my career over the past 5 years. I’ve also been a technical interviewer for about a year, so I’ll discuss the signals that I typically look for and mistakes that I think are acceptable.
Do You Have To Be Perfect In A Coding Interview?
Nobody is perfect, and this applies to everyone’s performance evaluation during a technical coding interview.
During a coding interview, you do not need to have a perfect performance. Instead, you should focus on communicating to your interviewer verbally and through your code that you’re a competent programmer in a programming language that has a great general problem-solving ability.
That sentence summarizes what every coding interview rubric at every decent company encompasses.
To demonstrate that you have all the competencies your interviewer is looking for in an interview, you’ll want to make sure that you communicate to your interviewer that:
- You fully understand the given problem
- You understand the inputs, outputs, and constraints of the problem
- You understand edge-cases the problem can have
- You can brainstorm and understand the tradeoffs between a couple of possible solutions
- You can identify one or two optimal solutions that you can use within the interview
- You understand time and space complexity analysis, and maybe you can estimate the time and space complexity of a solution without implementing it fully (this is really good for bonus points / good signal)
- You have a strong understanding of your programming language to construct a solution from your communicated description to your actual working code
- You verify your solution through testing
What Mistakes Are Acceptable During A Coding Interview?
As I’ve said before, you just want to demonstrate that you have the potential to be a solid software engineer during a coding interview through the communication of your thought process and the composition of your coded solution.
So, what mistakes are acceptable?
The mistakes that are acceptable are the ones that don’t matter within the context of an interview. If you demonstrate significant strength in a particular area of programming and make a minor mistake that the interviewer can feel that you could detect and correct if you had more time, then that’s an acceptable mistake to make.
Do You Need to Complete a Coding Problem to Pass The Interview?
Technically, you do not need to complete a coding interview problem to pass the interview. The answer to this question is highly dependent on the context of your coding and problem-solving ability that your interviewer obtained during the interview.
An example of this would be if you were working on a coding problem where you created multiple helper functions, but you didn’t implement them yet because you ran out of time.
Let’s say that you were able to come up with an optimal solution to your programming problem and the solution would’ve been working if you fully implemented the helper functions (that are relatively easier to implement) were completed.
In this case, your interviewer might ask you to only verbally explain the logic of your helper function. Alternatively, they may ask you to not worry about coding the helper functions if they’re confident that they understand how well you can code and predict whether you would’ve been able to finish the problem with more time.
Do Syntax Mistakes Matter During a Coding Interview?
The extent that syntax mistakes matter during your coding interview will depend on your usage of syntax throughout your interview. If you’re always making syntax mistakes everywhere, then it’s bad. If your syntax is 95% perfect throughout your code, then the 5% of syntax mistakes probably don’t matter.
You want to show your interviewer how well you can code in a particular programming language. It’ll be very apparent if you have syntax mistakes everywhere that you’re likely not skilled in the programming language you chose for your interview.
A couple of syntax issues in otherwise syntactically-perfect code will likely be overlooked by your interview and not counted towards your overall coding interview performance.
What Mistakes Are Unacceptable In Coding Interviews?
While there’s a lot of nuance with what mistakes are acceptable during a coding interview because you’re not expected to be perfect, there are some clear mistakes that are unacceptable during a coding interview that will likely result in your receiving a low evaluation score and rejection.
Mistakes that are unacceptable during a coding interview include, rushing to code a problem, failing to test your code, not knowing how to use key data structures and algorithms, and not understanding time and space complexity.
Doing any of the unacceptable mistakes listed above will likely cause you to have a significantly low evaluation rating for your coding interview.
Rushing to code a problem implies that you didn’t clarify the problem with your interviewer at the beginning and might be coding a solution to the wrong problem. Additionally, you might be coding a bad approach that your interviewer could’ve helped you clear up earlier. Rushing to code a problem also implies that you don’t think before you code. This is especially an important skill during a real software engineering job.
Failing to test your code is also a huge negative signal for your interview performance evaluation. Testing your code also includes informally going through your code and identifying portions of your code that might need additional testing for off-by-one errors or certain edge cases. Failure to even do that doesn’t reflect well according to most interview evaluation rubrics that I’ve seen.
If you don’t know how to use common data structures and algorithms in the language that you chose, you’re probably guaranteed to fail the coding interview. Your coding interviews are predicated on your ability to use data structures and algorithms in your programming language of choice. If you demonstrate that you’re weak, then you’ll be giving a massive negative signal to your interviewer.
It’s likely that your code won’t be functional and won’t be near-optimal if you lack the ability to apply the relevant data structures and algorithms.
Lastly, not knowing how to evaluate time and space complexity will be a massive negative signal in your coding interview. Mastering time and space complexity analysis is how you’re able to determine how one solution is likely better than another.
I think that time and space complexity is probably one of the most overlooked study items when people are studying and practicing LeetCode problems, yet it’s so important. If an algorithm runs in O(N^2) time and you say it’s O(N), you’re orders of magnitude off and may receive horrible signals toward your interview evaluation.
During an interview setting, this might not count for much for the problem, but in the real world, this could be the difference between a company surviving or failing if the code doesn’t scale well. While this is a bit of an exaggeration because you would likely have a team checking over your code to optimize naive approaches that don’t scale, that’s essentially why time and space complexity is important, in the most primitive sense, for coding interviews.
