Attacking Your Next Coding Interview
The all too familiar jump scare from receiving a new coding challenge in your inbox 🤢. Why is it so frightening to receive such good news?
Because we’re not prepared…
More specifically, we don’t know:
- how to prepare
- what will be asked of us
- what that engineer on the other side is really looking for
This is an in-depth guide on how to attack your next coding interview with confidence and prevent being blindsided by a simple backtracking sudoku solver.
LET’S BEGIN!
Practice makes perfect… This is why we cannot start preparing for this 1 week in advance. In my experience, starting the preparation a solid 3 months in advance can make you so familiar with the process, you’ll be walking into your next interview with the firm expectation of nailing it every time.
Think about this: if you’re trying to run a marathon, when would you start training?
Most experts suggest starting 12–20 weeks in advance, to become familiar with running approximately 50 miles a week four months before race day. Your body needs to get comfortable running long distances before we can attempt to perform at such a high level.
Coding interviews are no different!
In order to perform at a high-level, we must first put in the time well in advance. Because it takes time to develop the muscles in your brain and build a comfortability of the process. The only way to accomplish this is practice practice practice.
The secret to succeeding in these interviews is a function of time:
success(time_spent): return time_spent * learning >= min_comfortability
There is no shortcut. This is truly the only way to master coding interviews. And if you’re unwilling to put in the time to master the foundations of algorithms & data structures, then don’t even start.
So instead of taking a rejection letter, unpassed tests, or broken code as a failure, understand it is an indication of lack of preparation. Because in this space, comfortability is king đź‘‘.
Now that that’s out of the way, we can dive right into the actual material:
Algorithms & Data Structures
Every coding challenge or in-person technical interview you encounter is centered around your foundational knowledge of data structures, and your ability to use them to solve real problems (aka: create a working algorithm).
Some of the most popular data structures to be familiar with include:
- Arrays
- Link Lists
- Hash Maps <— (dictionaries in python)
- Stacks
- Queues
- Binary Trees
And honestly, that’s it! You’ll be able to tackle a majority of coding problems with these basic data structures. Being able to understand how they work, how to implement them from scratch, and what they are good for is key 🗝.
The implementations of these structures sometimes given to you for free in languages like python.
my_dict = {key: value}Fundamentally, this is a key-value lookup table, sometimes called a Hash Map. And the best part, is you don’t need to import a library to use it! Find out what features your language of choice offers and use them to your advantage.
So this begs the question:
Which Language Should I Use?
Answer: What you’re most comfortable with!
There are idealistic views of good and bad languages to use for coding interviews, but that really depends on what work you are interviewing for. For example: if you’re applying for a job as a web developer and familiar with JavaScript, use that! Or if you much prefer a statically typed language like C++, Go, or Rust, then that works too!
I’ve even been in a situation where a company “did not offer” coding interviews in my particular language of choice (Golang). But at the end of the day, when asking the engineer if I could code in Go on the spot, they urged me to use the language you’re most comfortable with. Because really, at the end of the day, they want to see you succeed!
Which brings us into the mind of the interviewer.
How do we know what the interviewer is actually looking for?
BECOME THE INTERVIEWER
No, like actually! PRAMP.com has a free peer to peer platform to conduct mock interviews with other engineers. Here’s how it works:
First, you fill out your estimated skill level and language of choice and Pramp will match you with similar engineers for a 1hr interview.
Just select a time-slot of when you’d like to start and you’ll receive a coding problem to ask your fellow engineer. You should read the problem, understand the solution, and even try it out for yourself. So when you log on, you can provide tips and pointers to your partner if they get stuck.
The real value of this is that you get to play both sides of the interview. You’ll encounter people across the spectrum from halfway working functions to ingenious solutions. COPY THE LATTER! When you find an interviewee that really seems to understand their problem instantly and lay out their plans of solving it, PAY ATTENTION. Understand what they are doing right, and what makes their thought process different from those who struggle with their solutions.
From my experience, seeing the engineers who could dissect a problem into its most basic parts and solve each part in a clean and concise manner was the most eye-opening spectacle. I identified, right from the start, how they thought of problems, which reflected what I was doing wrong on my attempts. They were paving the way for me in leading by example.
But understand that you will not IMMEDIATELY knock every problem out of the park from the beginning. In fact: I remember my first ever Pramp Interview because I couldn’t even begin to solve it. I felt so bad I wasted my partner’s time by absolutely floundering with my half-thought-out solution. It was so bad, that I did NOT want to do another interview because of how awkward and uncomfortable it was.
Understand this is natural.
Remove your ego and self-deprecating afterthoughts from the pursuit of your knowledge. Even when you log on every day, and have to claw tooth and nail for a solution to no avail, these are the learning moments. True failure is stepping away from these coding challenges and not understanding why and where you were stumbling. Check the solution and move on.
The roughest part of the whole experience is truly the beginning. But if you don’t quit, and continue learning in spite of these embarrassing moments, you will truly succeed.
In between these mock interviews, you’ll want to sharpen your skills with practice problems on your own. This is where a platform like leetcode or hackerrank comes in handy.
Choosing between either of the two really doesn’t make any difference
Mastery of these practice problems will come with the foundational knowledge of the most simple problems. So jump at all the easy problems FIRST, and don’t be afraid to peek at the solution if you get stuck. These are the most likely problems to be asked of you in any coding interview. So getting familiar with these variations of problems is quite important.
And do one problem a day.
Why?
Repetition.
You’ll build real familiarity with the process of formulating a strategy and coding a solution when you literally do it every day. I’m not saying you should do 10 problems a day; in fact, I would strongly discourage that kind of eagerness. Because at a certain point, if you push yourself too hard, you’ll fail to learn the problems you encountered and just stumble through each one without learning much. So realistically, 1–2 problems a day is the consistency you want to maintain.
If you follow this cadence up to the day of your interview, you’ll have seen so many problems that anything asked of you will really be a variation of something you’ve already encountered. Build this comfortability with each type of problem.
So then what are the types of problems?
… and many more!
But don’t be worried about mastering ALL types of problems. You’ll encounter similar problems in your daily practices that will make you think:
Wait… Haven’t I seen this before?
That’s because it’s one of these types of problems.
Once you begin to identify the types of problems and effectively group them into categories, you're beginning to master the process. And realistically, with enough time, you’ll see almost every problem out there.
At this point, you’re going to be heading into your Pramp Interviews without worry. Because each time, you’re focused on identifying the problem by its parts and solving it like similar problems you’ve encountered. The methodology of solving a problem will be more clear to you, and the process will be like muscle memory for your brain.
When you get to this point:
You’re Ready
So now you can look forward to your next coding interview as you’ve put in the time and developed a familiarity with problem-solving like an expert. You’ll know exactly how to dissect the solution and be thinking of the Big O space & time complexity ahead of time. Since you’ve been the interviewer on so many occasions, you’ll even know what you should communicate to the engineer sitting on the other side of the interview table. And they’ll know you’ve prepared, which will be a clear indication that you can be successful in whatever role they place you in.
This is the very achievable reality you will find yourself once you’ve actually prepared. And the most empowering thing is that it’s your choice and your choice alone to see this reality through.
So good luck and Happy Hacking đź’»
