Understanding the Coding Interview
Having recently quit my job at Amazon and joined Microsoft, I thought it would be helpful to share my interview experiences so that those in the same shoes can be better prepared and avoid common pitfalls.
First and foremost, the golden rule you need to know about the coding interview:
The coding interview does NOT measure a candidate’s ability to do the job.”
In other words, the skills you need to do well on the coding interview is entirely different from the skills you need to do well on the job. And when I say “entirely”, I really mean it – the intersection of the two sets of skills is almost non-existent. It’s the equivalent of asking a firefighter to fix a gas stove because both of them happen to involve fire (or in our case, “code”). In order to fix the gas stove properly, you need training and practice for fixing gas stoves, which you’ll never get on the job as a firefighter. Similarly, in order to pass the coding interview, you need training and practice for solving tricky coding questions, which you’ll never get building apps, frameworks, and backend services as a software engineer. This point should be intuitive, but often times it is overlooked by candidates who believe they can ace coding interviews simply because they are superb coders on the job. Chances are, you’ll never need to balance a BST on the job in your entire career, and as much as I have tried, I’ve only managed to put “recursion” into production code twice.
A couple of myths to dispel right off the bat:
1. “The interviewers are interested in knowing your thought process.” Complete bullshit. For phone screens, the interviewers are most likely not even paying attention to you – they are overwhelmed with work, emails, and meetings and would much rather get the interview over with as quickly as possible. The interviewer already have the solution (or multiple solutions) to the question in mind and is just hoping you would give one of the correct solutions. If your solution deviates from what the interviewer had in mind, he will subconsciously think your solution is wrong or buggy, even if it is correct! And even if you manage to convince the interviewer your solution is correct, you can bet you’ll get a comment in the feedback saying your solution is “suboptimal”. This can be as trivial as applying De Morgan’s law to covert “(not A) and (not B)” to the logically-equivalent “not (A or B)” in an if-statement clause. What is important is not whether your solution is correct, but whether your solution is perceived as correct by the interviewer, who is a biased human, not a machine. Make the job easy for the interviewer and give them the solution they expect – this comes with practice.
2. “We don’t care about syntax and api, just get the logic right.” This is another shameless lie. Don’t let your guard down. I’ve seen lots of candidates get a “not inclined to hire” vote in interview feedbacks simply because they used the incorrect syntax or an api that didn’t exist in the language. For example, the syntax to insert an element into a Queue in Java is “add”, not “push”, not “enqueue”. If you use the wrong api, you are giving the interviewer the impression that you’ve nevered used a Queue before in Java. Don’t rely on the interviewer giving you the benefit of the doubt. You should know the APIs of the common data structures by heart, so you’ll seem sharp to the interviewer when it comes time to code. There is no auto-complete on the white-board!
3. “It’s okay to take hints.” This statement is used to comfort and console candidates. Rather than watching the candidate struggle with the problem, the interviewers are instructed to toss a bone to the interviewee to move them along and put them out of their misery. If you have to take a hint, you’ve already failed the interview. At the end of the day, the company have plenty of candidates to choose from, and they would almost certainly take the candidate who solved the problem without any hints over the candidate who needed hints, regardless of who is a stronger coder in reality. Resist the urge to throw in the towel – you need to figure things out on your own. The trick is to remain calm when you are stuck and think about the problem from different angles.
4. “Ask a lot of clarifying questions.” A lot of people give this advice, which is meant to demonstrate that you are a thoughtful coder, but I think it does more harm than good in reality. If you ask too many clarifying questions, it shows that you are not good at dealing with ambiguity. I once followed this advice on a phone screen and asked a lot of questions as I was coding. I thought I did extremely well and finally figured out the interview system. I solved the algorithm question with multiple solutions as well as provided a complete solution to the design question to implement a timer system that can be used in a multi-threaded environment. I received a phone call 20 minutes later from my recruiter saying that they will not proceed with the on-site interview, the reason being the interviewer had to give me too much “hand-holding”. I was extremely disappointed by the outcome – what I perceived as being thoughtful and collaborative is perceived by the interviewer as “hand-holding” – what a joke! My advice here is to make reasonable assumptions (provided the interviewer does not object to the assumptions) and start coding as soon as possible – ask clarification questions only when absolutely necessary, not for the sake of asking.
So what is the coding interview really about? It is about nailing down the coding questions, period. Why? Because at the end of the day, the interviewers need to present legal evidence to the hiring manager on making a hiring decision, and the candidates’ solutions to the coding questions are the most authoritative evidence – if the solutions are not the most efficient and bug free, it’s almost guaranteed to be “not inclined to hire”. There is very little room for subjectivity here – it doesn’t matter how much work experience you have or how many accomplishments you have – if you can’t give them the evidence that you are a good coder, they cannot hire you, legally.
The only way to beat this flawed system is to study extensively on coding problems and hope you get lucky during the interview. It’s an unfortunate reality, but I’ve seen a lot of poorly qualified candidates get through just by memorizing questions while other perfectly qualified candidates get turned down for messing up the coding problem. As a rule of thumb, I recommend spending at least 2 weeks studying coding problems every night in order to prepare for the interview. When you do a coding interview, it is important to remember that you are not competing against other software engineers, but rather against college candidates and unemployed candidates who are able to dedicate all their time to studying and memorizing coding questions. If you are a full-time software engineer, the playing field is rigged against you to begin with, so you must put in a lot of effort to make it even!