Do I need to write perfect code in a technical interview?
September 19, 2020It's a natural question to ask when you have a technical interview coming up - do I need to write perfect code in order to make it to the next round?
How many bugs are acceptable, if any? And how should this influence my strategy before and during the interview?
Mandatory caveat
I'll preface with the most-hated phrase heard by question-askers worldwide: "it depends."
It depends on several factors, but in the macro the thing to realize is that interviewers can be fickle.
You could be interviewing with two people from the same company, and one could expect flawless code while the other could take a more nuanced approach in evaluating the interview.
Some companies have higher standards than others and use different criteria.
In this essay, I'll focus on what's true in general when interviewing as a junior-level candidate at a big tech company.
These considerations are what you should base your actionable strategy and approach off of, not the outliers.
Interview mistakes I made
I have some N of 1 data from my own tech interview experiences that can hopefully shed some light on the answer to this question.
In both the phone screen and onsite interviews for Microsoft, I made mistakes in the technical interviews.
In the phone screen I missed an edge case that the interviewer pointed out explicitly.
In at least two of the four rounds of the final onsite interviews, I had a bug in my code that the interviewer had to tell me about.
Even worse, in my final onsite interview (when I was COMPLETELY brain dead from what turned out to be 5+ hours straight of technical interviews), the interviewer gave me a hint that basically told me exactly how to get unstuck on a specific part of the problem.
I still got the job.
In the system design round at Asana, I definitely did not do perfectly, yet moved on to the onsite.
At WePay, once again I felt like I did awful on the first technical screen, but moved on to the next round.
What matters more than perfection
Although I made mistakes in my interviews, I still moved forward in many of these rounds, including the one that got me a job at Microsoft.
I believe the reason for this is that I still demonstrated a fit for the core criteria that the interviewer was looking for in a candidate.
I wasn't perfect, but I was still strong in data structures and algorithms. I got 95% of the problem correct on my own and was able to explain the fundamental technical reasons for my decisions.
I could efficiently identify suitable data structures and an algorithmic approach when given a brief description of the question.
I clarified the boundary conditions of the problem beforehand and laid out a thoughtful strategy before just jumping into solving the problem.
I talked about the technical tradeoffs of alternative approaches and why I thought one approach was preferred over the other.
From the perspective of most interviewers, they are looking at your thought process, attention to detail and core technical understanding more than your ability to write perfect code in an interview on your first try.
It's much preferred that you demonstrated your ability to think like an engineer, could evaluate time and space complexity of the algorithm at scale and truly understood what you were doing, than if you got to a perfect solution in 5 minutes but showed no insight into your thought process.
Another thing that I believe helped me pass these technical interviews is the collaboration aspect of things.
I made sure to approach the problem at hand as if the interviewer and I were solving it side by side as part of the same team.
This made me way less nervous than if I thought I was being evaluated across the table, and also showed the interviewer what it would be like to work with me in real life.
This is a crucial point. If the interviewer wouldn't want to work with you, you probably won't pass the interview no matter how well you do on the technical round.
Who would you rather choose to hire - someone who has proven only that they can solve a DSA problem with no bugs in an interview, or someone who got 95% of the way there, was a pleasure to work with and was willing to listen, learn from and collaborate well with you to persevere and solve the problem?
Summary
You do not have to perform perfectly in an interview to move forward to the next round.
You should obviously prepare with the aim of writing perfect code, but once you're in the interview or have just finished it, don't let the anxiety of making a mistake detract you from what matters most in the interview.
Interviewers are looking first that you have strong, core technical skills as it relates to the role, not absolute perfection.
They also want to know that you can think like an engineer, evaluate tradeoffs in terms of time and space complexity, demonstrate the ability to problem solve in the midst of ambiguity and doubt and that you would be a good person to work with.
So basically, your performance during an interview is evaluated by more criteria than just writing bug-free code.
If you can keep a positive attitude, show off your strong technical chops and demonstrate the mindset of a competent engineer, you can still ace that interview and get a fantastic software engineer job.
Want to ask a question or get first access to future essays and announcements?