Question

Are you expected to write the perfect code on your first attempt in tech interviews?

Answer 1

Definitely not, though you will be asked about any syntax errors you make—interviewers don’t necessarily mind the errors themselves that much, but they do want to see how you correct them (and how you react when those errors are pointed out to you). Interviewers also care about whether or not you can develop and explain an algorithm on a whiteboard before actually writing any code. Only then, when you and the interviewer have talked through the logic of the algorithm, should you actually dive into coding.

This often surprises programmers about their interviews, not because they have to use a whiteboard before writing any code, but because communicating their thinking is harder than they expect. This normally happens because programmers ignore the non-technical skills when preparing for their coding interviews, an oversight that can cost them the job. It’s important that you prepare for every aspect of the interview, and make use of the resources that match the skills you need to work on most.

If you’re confident in your coding skills and would like to focus on the behavioral side of your interviews, Interviewing.io is a great place to look. You’ll get matched in technical mock interviews with other software engineers—some of whom have worked at companies like Google and Facebook—and receive immediate, unbiased feedback on your performance.

If you think you’d benefit more from a deeper knowledge of data structures, algorithms, and systems design, you may want to enroll in a course like Tech Interview Pro, which was designed by a former Google software engineer. TIP is laser-focused on helping you ace your big tech interviews, and includes 150+ in-depth video lessons on data structures & algorithms, systems design, and the interview process as a whole. Students get access to a private Facebook group of 1,500 former students, many of whom have applied what they learned in the course to land jobs at Facebook, Google, Amazon, and other big tech firms.

And while one or two errors won’t annihilate your chances of success (refer back to what I said at the beginning), your coding skills should still be as sharp as possible. To hone them, you can turn to sites like LeetCode, a very popular online judge with thousands of coding problems to solve, or CodeKata, another problem library focused on bridging the gap between algorithm theory and real-world application.

Good luck with the interview.

Answer 2

It’s hard to write correct, let alone perfect code on the first attempt.

Through thousands of technical interviews we’ve conducted at Refdash we’ve seen that even the best engineers constantly make small mistakes, typos, etc.

Still, keep in mind that there are different types of errors you can make — some acceptable, some, well, not so much.

There are three levels of errors:

1. Typos — you missed a semicolon and it didn’t compile. No big deal. If an interviewer gives you trouble for this type of mistake, think twice if you want to work for that company.
2. Missing edge cases — happens often during interviews. Some more strict interviewers may interpret this as your inattentiveness to detail. Usually, you’ll get a chance to fix this.
3. Missing parts of critical logic — This is an issue. In some cases, interviewer will bring this to your attention and give you a second chance. Sometimes, that’s it, better luck next time.

When it comes to typos, make sure to pay some attention during interviews. As I said, interviewers will usually have understanding for this, just don’t be too sloppy with your code.

For getting those edge cases, I suggest you participate in some online coding competitions on sites like codeforces.com. Those guys just love to give you unexpected and tricky edge cases that really force you to think about your solution.

If you often find yourself missing parts of critical logic in interview questions, make sure to brush up your knowledge of algorithms. Pick up a book like CLRS and make sure to learn all classic algorithms, their use cases and running times. Then do a lot of practice problems, focusing on your weak areas. Check out Refdash where you can do free practice interviews with engineers from top companies.

Finally, do a lot of testing. While you practice, testing will help you see if you made any of the aforementioned mistakes. And if you test your code in an interview, it will show that you are an engineer who cares about correctness of their code.

Answer 3

First, I don't know of any problems that can challenge and demonstrate an interviewee's thinking for 30-45 minutes while still being able to be written 'perfectly' in nearly the same amount of time. If you mentioned "expected to write perfect code on your first attempt" in my interview I'd have trouble believing that you spent any significant amount of time in industry, writing software, because a software engineer knows how many places even simple code can go wrong, especially if it is code that is meant to challenge your thinking.

Second, breathe, don't worry. This isn't about other companies or your skills there, this is about you and how you think other companies will perceive you based on aspects of an interview that are trivialities when taken by themselves.

Would you reject someone on an interview that you thought went well *just* because you saw them miss two edge cases or made a few syntax errors they fixed when pointed out? It ties into whether the interview, as a whole, went well but is not the interview itself.

Third, an important thing for tech interviews is to model the your interviewer as being much more rational, at least in the work domain, than the people you are used to seeing. The cool thing about modeling someone as rational when you feel that your behavior can be rational is that you are thinking along the same path and any divergences can be reasoned through because you both expect to be able to do so and are willing to put in the effort for it because it's an interview, and both parties want an engineer hired (that IS the case!). If you don't come into the conversation with that mentality, the interviewer will have trouble telling apart interview anxiety and lack of confidence in engineering.

That lack of confidence is by far worse (if I was interviewing) than missing two edge cases because uncertainty and challenge defines our everyday. If you can't find a way to kick back and just calmly have a rational conversation with someone about engineering than you don't want to be here anyways so I wouldn't go for hire. If you need to work on your edge cases but all else is well, you can work on your edge cases in a few months and you'll be fine. Emotional reactions on the other hand take a very long time to change in someone. In a work environment they need a special relationship with a coworker for mentorship to work. Or you just hope the person gets better on their own, which I wouldn't do.

TL;DR: Either you don't understand code well enough and that is why you asked about "perfect code" in 45 minutes and therefore you need to practice coding more to realize how naive that notion is for a person going into a tech interview. Or the real problem is your interview anxiety and self conscious. In which case, don't worry, model them as rational and every company pays for interviews because they WANT employees, remember that. =D Good luck!