In the previous post, we saw a general outline of the interview process and a few pointers on how to polish your resume to help you stand out. In this post, we’ll cover a little about the coding interview.
The kind of interview you need to prepare for largely depends on the level and the type of position you apply for. Thus, it’s important that you clarify the kind of interview you can expect with your recruiter ahead of time.
For example, if you’re applying for the position of Senior Backend Engineer, you’re more likely to have a design-focused interview. However, if you’re relatively new to the industry, your interviews will tend to be based on your understanding of Data Structures and Algorithms.
The Coding Interview
If I’m being honest, I have no love for the coding interview. However, I do understand (kinda?) why these interviews have become the de facto process for hiring in tech. Ideally, firms would love to hire everybody as an intern and use performance during the internship as the sole basis for hiring. This system works a lot better for everyone involved and is definitely a more accurate measure of a candidate’s skill.
However, this process is simply impractical at scale and that is what leads us to this situation we find ourselves in.
The coding interview is typically a 45-50 minute long interview where your interviewer provides a problem statement. You are then expected to solve this problem in code as efficiently as possible making use of appropriate data structures and algorithms.
How best to prepare for your coding interview
A quick disclaimer before we get started. Most of this isn’t new information. The intent of this post isn’t to try and peddle some kind of a “secret” to cracking the coding interview. Instead, it will be to re-emphasise a tried-and-tested set of resources which I can personally vouch for.
To start us off, I’d recommend a book; Cracking The Coding Interview by Gayle Laakmann McDowell. The book is an absolute classic and will get you started on Algorithms and Data Structures. There are some great tips and insights about the interviewing process itself in addition to the technical aspect which I will best leave to the author. Make sure you’ve done all the exercises in the book before moving on.
However, I do believe that the book by itself isn’t sufficient for some of the tougher interviews out there. Leetcode is highly recommended to reinforce what you’ve learnt from the book.
The Leetcode Grind
Leetcode is definitely the gold standard platform for interview preparation and there’s a high chance that your recruiter will recommend it to you themselves. I’d suggest solving the following in order
- Leetcode – Top 100 Liked Questions
- Leetcode – Top Interview Questions (there should be a significant overlap between the two)
If you’ve never done any sort of competitive programming prior to this, this might be an unpleasant journey at the start but I promise it gets better over time. Start off with the ones marked Easy. When you start getting comfortable with Easy, move on to Medium and so on.
Spend no more than 30 minutes per question. It feels amazing when you’re immediately able to solve a problem. But the questions that you don’t have an immediate solution to are the ones that help you identify gaps.
If you aren’t able to come up with a solution for a question in time, look at the solution in the Discuss tab and understand the solution. But make sure to perform some kind of retrospection on why you weren’t able to come up with a solution. Did you spend too much time in one line of thought? Maybe the key to solving the problem was using some key information that you missed in the question. If so, why do you think you missed this hint? This does two things for you; it helps you avoid making a similar mistake in the future and more importantly, it forces you into the habit of thinking in new ways for any problem you attempt in the future. Maintain some sort of notes so that you also have something to look back to.
Structure your thought process
Interviewer: *provides problem statement*
Candidate: “Okay I think sorting this and performing a binary search should work”
Interviewer: *provides a scenario where it wouldn’t work*
Candidate: “Okay then I think converting this to a tree and performing a Depth-First-Search should work”
Interviewer: *provides a scenario where this wouldn’t work*
This approach has next to no structure. In my opinion, having a good structure in the way you approach a problem is the single greatest quality in a candidate. You can think of it this way; all the algorithms you’re able to implement are tools in your toolbox. So it’s great if you have a well-stocked toolbox but it’s not what anyone’s looking for. I’d rather pick the candidate that can build a whole bridge with just a hammer (this is also why everybody loves the villagers in Age of Empires 🙃).
A structured thought process lets you look past all the noise in a problem, reduces the problem to its core and can suggest various approaches to solve this reduced version of a problem. While you solve Leetcode Medium and Hard problems, try to deliberate with this. Even if you think you can solve a problem immediately, try to apply some sort of structure on why your solution might work.
“How many Leetcode problems should I solve?”
I have no idea how to answer this question. Some folks are regular on platforms such as Codeforces whereas some are not. Some might have taken a course on data structures and algorithms at some point whereas some may have not. So how much practice you need depends entirely on your background. All I can tell you is, on average, you should be able to solve a Leetcode Medium problem and have a 20-30% chance of solving a Hard problem. That number is just my personal opinion on how prepared a candidate should expect to be for a hard interview.
Write code on paper?
Your objective is to write clean code in one pass. No back and forths of any kind, no spamming the Run button to see if your code compiles etc. That is, you write code once and it does exactly what you intended to do and it passes all test cases. All in one go. It’s no easy task to get to this place but you should be able to do it with sufficient practice.
For this reason, I recommend that once you have sufficient practice on Leetcode you should also practice writing code on paper / Google Docs / Notepad. In your actual interview, you might be expected to write code on a whiteboard or on a platform that doesn’t provide any sort of syntax highlighting so some practice might make you a little bit more comfortable during whiteboarding. This practice also forces you to think through everything ahead of time since it’s a lot harder to perform corrections when writing code with pen and paper.
Mock Interviews
Honestly, do yourself a favour and find someone to conduct a few mock interviews for you. Preferably someone from the industry that has experience conducting SWE interviews. So far, you’ve been practising solving problems by yourself and have put next to no effort into presenting your work to someone else. This is a great way to allow confirmation biases to creep in. Getting someone else to help identify potential flaws in the way you present your work is definitely going to be worth your while.
The Interview
His palms are sweaty, knees weak, arms are heavy
There’s vomit on his sweater already, mom’s spaghetti
It’s time for the interview! It’s not easy to stay calm during your interviews (I know I wasn’t 🥲). But you’ve got this! In this section, I want to talk a little about some things to watch out for during your actual interview.
Think out loud!
Your interviewers are usually instructed to nudge you in the right direction if you seem stuck. It happens way too often that candidates sit in absolute silence whilst thinking to themselves, sketching something on the whiteboard every now and then. It can be pretty confusing for your interviewer to gauge if you’re in need of help.
Therefore, think out loud! Talk about various approaches that you think can and cannot work. I cannot emphasise this enough. Your interviewer isn’t there to see if you’re able to solve a problem or not. They’re there to gauge how you approach a problem.
Making assumptions
Sometimes, you might wish there was a utility method that does something trivial that you don’t want to spend time writing code for. It’s completely okay for you to communicate this assumption with your interviewer.
“I’m going to assume there exists a function convertFromFooToBar(foo) which converts input foo into bar.”
You can offer to revisit the implementation of this function at a later point during the interview (if time permits). Essentially, don’t spend time on trivial parts of the code which you aren’t being tested for.
Clarify everything!
It’s unfortunate when a candidate makes an assumption about the question that isn’t necessarily true. And it happens that they unveil this assumption after 35 minutes into the interview by which it’s already too late. It’s okay if you take the first 5 minutes to just clarify everything about the question.
Space and Time Complexity
The first thing your interviewer is going to ask you about your solution is the space and time complexity. Don’t give them the satisfaction of asking this in the first place 🌞.
Provide the space and time complexity of your solution even before you start to write any code.
Dry run your code
So you’ve written out the code for the problem you were asked for. Awesome! But before you call it, do yourself a favour and dry-run an example with your code. Walk your interviewer through how your code behaves with your input test case. This helps you spot any obvious mistakes you’ve made and correct them before your interviewer points them out for you. Also, consider some of the corner case inputs that your code might have to deal with.
Stuck? Start with Brute Force
Sometimes, it just so happens that you’re completely stuck on a particular problem. Rather than sitting idle for about 10 minutes while making no progress trying to come up with your O(nlogn) solution, start with a brute-force solution. The cool thing about the brute force solution? It’s a valid solution. Once you have this, try to see if you can find any inefficiencies in this solution. Can you make the solution faster? Can you pick up on some detail in the question that you can take advantage of to eliminate some possible solutions?
And that’s a wrap!
Interviewing is fun said no one ever. It’s a lot of work and a whole lot of stress. Remember, you don’t have to nail every single round of the interview. I remember I did well on 2 of my rounds, so-so on one of them and absolutely tanked on the last one.
Lastly, want to avoid a lot of last-minute stress? Start the Leetcode grind way ahead of time. I would recommend a month or two in advance. It’s okay to check with your recruiter if you can take a month or two to prepare for the interview.
You got this! :3