Are you expected to write perfect code on your first attempt in tech interviews? by Istvan Jonyer
Answer by Istvan Jonyer:
As someone who interviewed many engineers at Google, I can tell you my approach. Others may do it differently, but Google trains everyone to interview properly.
When I ask you to write code on the whiteboard, what I am most curious about is your thought process. Therefore I vastly prefer people trying to 1) understand the problem well, and 2) develop an algorithm using drawings and examples, paying particular attention to edge cases. Only when we talked through all that, and both agree on the algorithm, should a candidate start to actually write code. At that point I always ask what their favorite language is, and ask them to use it. If they make a syntax error, I usually ask about it, but I don't really care about the error itself. What I care more about is how the candidate handles being corrected. Are they defensive? Insecure? Or confident and collaborative? The most important thing, of course, is whether the code reflects the algorithm they / we developed.
If you launch into writing your code, as opposed to developing the algorithm using examples, you are likely to make mistakes. You are skipping an important step — the algorithm development. Writing code while at the same time thinking through the algorithm in your head is unnecessarily difficult in a high-pressure interview process.
The worst is when a candidate, upon hearing the question, turns to the whiteboard and presents a flawless algorithm, writing it out sequentially. I know that the person had heard the question before, and I learned nothing about their abilities. My notes in that case are literally "Invalid question, knew the answer".
If I sense that the candidate is not confident in their answer, I may even throw in a "mistake" to see if they're confident enough to disagree with me. This could also happen by an honest mistake on the part of the interviewer, which should not throw you off track, and you should stand up to your answer if you know you're right (and prove it).
To answer your question more directly, yes missing edge cases is a biggie. It means your process was wrong, you probably didn't try to develop the algorithm using examples, and you didn't take special care to identify and handle edge cases. If you've been a software engineer for a while, you know how many bugs are the result of missed edge cases, and how important they are.
Bottom line, you need to impress me, not hope to get away with mistakes.
Are you expected to write perfect code on your first attempt in tech interviews?