Coding Interview Guide

Last Updated: Aug 29, 2021

Advanced degree in computer science? Check.
Good marks in school? Check.
Years of professional experience at prestigious tech companies? Check.
Okay, just solve this programming riddle while an interviewer looks over your shoulder. By the way, the interviewer just added “it’s an easy question” ie. if you don’t solve it in 10 nanoseconds you’re an idiot.

Coding interviews are pretty hated, but you shouldn’t let them stop you from getting your dream job. This post gives my advice for dealing with coding interviews. Here’s a quick summary:

• Investing in this skill will help your career and significantly reduce the barrier to getting your dream job. Unless you’re taking a job for life, you’ll always need these skills.
• Yes you need to study for this, it’s a different skill than day to day coding or you algorithms class in school.
• Study the right way: don’t try to hack through hundreds of questions hoping to memorize tricks. Instead, internalize how to solve problems with different data structures and algorithms.
• Coding Interviews measure 4 things, in order of importance: Basic coding skills, CS algo and data structure knowledge, Problem Solving smarts and software engineering.
• Go in with the right attitude: Don’t put a ton of pressure on yourself. This doesn’t represent your value as an engineer, and you don’t need to be perfect. These are riddles in an artificial test environment, it’s almost impossible to think creatively when you’re feeling pressure. So take the pressure off yourself and approach problems with a sense of gaming. You won’t win them all in your career but you’ll have plenty of chances to play again.

Do you need to do coding interviews?

A lot of people complain about coding interviews, but for better or worse they’re part of the game. I’ve seen people complain about it, fight it and even refuse to play. The quickest phone screen I ever conducted at Amazon was with a senior engineer. After the small chat, I switched tracks to start the coding portion of the interview. He got angry, said he had a lot of experience and refused to do any coding in the interview. Well, John Carmack is above coding interviews, but you’re not. There are a few companies out there that don’t do coding interviews, but you’d really be limiting your options. If you’re going to be a software engineer, you need to be judged like a software engineer.

But what about your algorithm class marks? Profession experience? Github repo and references? Unfortunately, I’ve never once, in any company I’ve worked at, heard a peep about a candidate’s marks in school or how clean their side project code was. That’s because we’ve all seen people that look amazing on paper but are incapable of demonstrating programming skills.

If you’re coming from an ML background, there’s been a push to separate ML Engineers from Analysts. The ML Eng role has become more prominent (and generally pays a lot better.) However, this has the added requirement of passing software engineeringing interviews. That means lot of people coming from an analytical background are approaching coding interviews for the first time.

How Important are Coding Interviews?

The good news is that coding interviews have become much easier over the years. Companies are absolutely lowering their bars, but they’re also easing up on unnecessary requirements. The fact is, coding interviews don’t really reflect what day to day life is like as a software engineer. I’d say they’ve essentially become binary, at some companies their outcome is explicitly binary: pass or fail. Either you do good enough (and not necessarily perfect) or you fail. This is especially true as you become more senior, and past experience, behavioural questions and systems design interviews become more important. Unless you’re joining as an entry level engineer, coding questions will basically only disqualify you, they won’t get you the job if you have other weaknesses. I think that with some studying and practice to calm the nerves, every decent candidate can essentially remove coding from the equation of whether they’ll get hired.

Under Pressure

To me, the most artificial aspect of a coding interview is the pressure and time limitations. These questions are riddles, and your brain typically needs to be in a relaxed state to think creatively and solve riddles. This is one of the things that have thrown me off. Here’s my advice:

• Study enough to gain confidence
• Go into interviews with the right mindset: this isn’t a test that determines your self-worth, this is a game. If you lose one round there’s as many more as you can handle You don’t need to be perfect. Like I said, outcomes are somewhat binary. To pass, you often just need to get a decent solution and demonstrate the ability to translate logic into code. You don’t want to trip yourself up trying to think of the O(1) solution when the good enough O(n) solution is right there.

Studying Approach

I’ve always been good at algorithms and data structures, it was one of my best marks in school and I’ve programmed/studied these concepts for a long time. I learned that you need to go beyond a passive knowledge of algorithms and data structures excel at interviews. A book that shaped my approach to interviews, which I highly recommend, is Elements of Programming Interviews. This went beyond random practice questions to a much more structured approach. Questions are organized by CS concept, which helps show you how to utilize and internalize concepts like binary search and heaps.

This is why I believe studying for programming interviews isn’t a waste of time to game the interview process. By internalizing how to use different algorithms and data structures to solve problems, you’ll become a better software engineer. Essentially, every few years when you look for a new job, you go through the process of studying and rebuild those muscles, even stronger. The concepts are all timeless and applicable, so it’s very useful. Learning the trick for how to find the best possible trade given a timeseries of stock prices isn’t timeless, studying and understanding how to apply data structures absolutely is.

Unfortunately, coding interviews lean on different skills than you typically use at work or exercised in school. So it’s important to study ahead of time to give yourself a leg up. Like I mentioned earlier, it’s a worthwhile investment in your skills. Here’s my recommendations:

• Start early, give yourself weeks or even months, depending on how long it’s been since you’ve interviewed. It’s better to tackle a few questions here or there at a leisurely pace than cram everything on a weekend. Your brain can only solve so many problems at a time.
• I highly recommend Elements of Programming Interviews. Many companies will ask easy questions, but expect some medium. It’s unlikely you’ll get hard questions. Work your way through the important concepts I highlighted. Note that with this book, it’s cheating a bit since you know what algorithm/data structure to use ahead of doing each question (since the book is organized by these concepts)
• Use Leetcode. I recommend paying for it while you’re interviewing, it’s well worth the investment. You should look at questions highlighted for the companies you’re interviewing at. You’ll get a sense of the difficulty you’re facing. I’d say that Leetcode medium questions are a good level to study for.
• Don’t worry about hard/obscure questions. Questions with really specific tricks or require extensive background knowledge are poor questions and good companies will avoid them. If someone asks you how implement a Red Black Tree or expects you to pull out Dijkstra’s algorithm, then you had some bad luck.

Interview Signals

Companies are looking for a few signals in a coding interview.

Coding

The most crucial skill to demonstrate in a coding interview is the ability to cleanly code a desired behaviour. It doesn’t matter if you did a phd on cuckoo hashing, if you’re struggling with list comprehensions then you’ll fail. If you don’t come from a programming background, this can be kind of hard. Some interviewers are checking for language mastery, while others are just looking for pseudo code. Make sure you’re clear on expectations ahead of time. If you’re coding in a real language, I’d recommend using Python. It gives you a speed advantage for coding and most engineers know it.

CS Concepts

These are the Computer Science concepts that you should focus on for coding interviews. Of course the field has a lot more to it, and they may even come up in interviews too.

Data Structures

Data Structures are more important than algorithms. For most coding questions, the main insight will come from figuring out what data structure can be used to represent your data. This requires knowing the data structures by heart so you can cycle through options in your mind. Think about how you need to access your data, do you need to insert items in random locations? Do you need to scan the data in sorted order?

• Linked lists
• stacks/queues
• Binary search trees
• Hash tables (Go beyond Python’s ‘dict’. Know how these are implemented. What happens two ‘keys’ map to the same space in the underlying array?)
• Heaps/Max priority queues

Algorithms

• Graph algorithms. It’s often a big insight to see how you can represent a problem as a graph. Once you have a graph, to solve a coding interview question you’ll probably need to do a BFS or DFS. You probably don’t need to know deeper algos like Prim’s algorithm for a coding interview. However, you should get some practice coding a graph solution. For some reason, graph questions are a favourite for interviews.
• Dynamic Programming
• Binary search
• Recursion (it’s often easiest to implement the behaviour you want with recursion, but there can be performance downsides to this and it’s good to have some experience re-implementing a solution non-recursively)
• Merge sort (especially distributed merge sort, which can be used to sort something where you can’t fit all data into memory)

Complexity

You will definitely need to know how to estimate the big-O complexity of your solution, both in terms of memory and run time. You might be dreading this, thinking back to proofs from your undergrad classes. It’s simpler than that, with practice, you see patterns that emerge, often based on the high level concepts of different data structures and algorithms.

Tips: There’s basically 3 options in a coding interview: O(1), O(log(n)) and O(n). Are you modifying a tree? Think O(log(n)). Are you looking at every item? It’s O(n) Make sure you know what N is for your question, since sometimes there’s more than one input Look out for hidden constant solutions. If you limit an algorithm to looking at a max of 10 items, that’s a constant run time (it doesn’t increase with the size of the input.) Don’t forget that complexity applies to memory too. There’s often a trade off between faster run times and memory storage. Make sure that you’re the one calling this out, not the interviewer.

Problem Solving

Interviewers are also getting a sense for how you solve problems and what it’s like to work with you. Do you take hints? Do you get defensive on hearing feedback? I can’t tell you how many times candidates have sunk their chances by reactiving poorly to feedback. The interviewer is trying to help you by focusing on a better solution, but many candidates will get defensive or stay stuck on their current track. It’s also important to vocalize your thought process so that the interviewer can get a sense for how you deal with problems.

Software Engineering

In the context of a programming interview, software engineering is evaluated pretty superficially: variable naming and classes/functions organization. It seems like this aspect of interviewing has really fallen in importance over the years. You don’t see many questions on OOP or Gang of Four patters. The nature of coding interviews usually yields some messy code and abstractions. Interviewers are pretty lenient to this I’d say, as long as the candidate can call out how they’d refactor the code to be cleaner. It’s also good to avoid red flags (eg. poorly named classes or exposing public variables unnecessarily.)

Approach

Okay, the interview’s started, you’re done talking about your last project and the weather, now it’s time to get to business. The interviewer describes a question to you and you’re staring at a blank screen on CoderPad. Unfortunately, this isn’t the question you studied last night, so you don’t have an instant answer. Now your nerves are kicking in. How do we deal with this?

1. Make sure that you understand the question. It might make sense to go through an example input and desired output if the question isn’t straightforward
2. Ask about corner cases and assumptions, how do we handle a negative price value? Can we assume this is single threaded?
3. Speak out loud about an approach, just to make some progress. The most straightforward thing to start thinking about is how you’ll represent the data as a data structure and what behaviour you’ll need to do
4. Once you solidify an approach describe it to the interviewer to get their buy in
5. Code the question, narrate this a bit if you can to describe your thought process or any coding choices you’re making. Definitely call out things that you’re doing for interview processes.
6. Before saying “I’m done!”, talk through the code a bit to catch obvious bugs. This is often something you’re evaluated on and shows maturity. Look for easy corner cases, what the input is an empty list.
7. Finally, talk your way through your solution, perhaps ask if any unit testing is expected. It doesn’t hurt to help, and often you’ll be asked to think of how to test the code you’ve written. If you’ve gotten this far, you probably passed the interview. However, the interviewer might add in an additional request or ask about a more optimal solution. Sometimes you’re expected to code this, sometimes you’ll just talk through it.

How to get unstuck:

The goal of any interview question is to make you go through a problem solving process. This means you’re supposed to get stuck and have an ah-ha moment. However, it’s an incredibly uncomfortable feeling trying to conjure up a eureka moment under pressure. There’s a few ways to get out of this.

• Describe the sub-optimal approach. This is a good way to get unstuck, make some progress and gain insight. Say it out loud, and call out that this is the sub-optimal approach so that you’re not penalized. Often there’s a brute force approach that isn’t the perfect answer.
• Think about different data structures you can use to represent the data, and how you need to access the data. Do you need to access random items? Do you need to modify the data once it’s stored? Consider adding an additional data structure, increasing the memory size by a constant may lead to a speed up. Often the data structure is the heart of the problem.
• Typically, problems involve looping over a dataset. Work through an example of one iteration of what you’re trying to achieve on paper. Focus on the behaviour you want, not how to implement the behaviour in code. Then you can think about how an iteration can be sped up (eg. maybe it would be helpful to grab an item instantly by its id instead of searching through the whole list.)

Conclusion

Thanks for reading to the end and I hope this guide helps you out. Take the marathon approach to prepping, you’ll learn useful knowledge and this is a skill you’ll revisit throughout your career. Coding questions can be very stressful, so don’t feel bad or fear failing. It’s better to fail, study and learn than let the fear of interviewing hold you back from the dream career you deserve.