10 tips to smash the code interview

Throughout my career, I have been lucky enough to have been involved in hundreds of coding interviews, on both sides of the table!

I have been helping bootstrapping new engineering offices in new locations and therefore I had the chance to interview many talented software engineers. I have also been long enough in the industry to have done my fair share of interviews as a candidate. By the way, I always failed with the FAANGs, so you might want to take everything that I am about to share with you with a grain of salt... 😅

In the last few months, my friend Padraig O'Brien involved me in a pro-bono activity that he is doing to help software engineers land their first software engineering role. In the context of this project, I have been doing pair programming with engineers to simulate coding interviews and help them to overcome some common obstacles. Thanks to this activity, I had once more the opportunity to observe common mistakes and come up with a list of suggestions that should help engineers to keep it together and shine during the coding interview!

In this article I will try to share the top 10 tips I have collected while doing this activity.

If you are already bored by my verbosity, you can check out a TLDR; version of these tips on the Twitter thread below:

Although, if you find that useful, you might want to come back to this article, because I am going to be sharing a lot more context and some additional resources here!

By the way, just to be 100% clear, when I talk about code interview I mean face to face coding interviews where the candidate is given an assignment and they have to provide a solution and discuss it with the interviewers. My suggestions should work for in-person interviews as well as remote ones.

Now, with all the intro out of the way, are you ready for the first tip? 🤗

1. Understand

Photo by Road Trip with Raj on Unsplash

Before thinking code, make sure you understand the assignment. Read the description carefully and don't be afraid to go back and read again something that is not clear after the first pass.

Often the description of the assignment contains math lingo which might be a bit tricky to process. For instance:

• the i-nth number in the list
• the number of elements in the list is n-x where n is something and x is something else

Don't be afraid of this terminology when you see it. It is OK to ask for clarification if you are unsure about the actual meaning.

Even if you think you understand what it means, it might be useful to write down simple examples where you replace the variables with actual values.

Let see an example:

The input list contains all the odd numbers from 1 to n.

Here, our variable is n. Let's see what the actual list looks like when we replace n with a given value:

n = 1
list = [1]

n = 2
list = [1]

n = 3
list = [1,3]

...

n = 10
list = [1,3,5,7,9]

By doing this exercise you should be able to get a better picture of what kind of data structures you are going to work with. This approach can also help you to build test cases to validate that you are going in the right direction as you progress with the implementation of the solution.

2. Break it down

Photo by Florian Klauer on Unsplash

Interview problems are generally the combination of multiple smaller problems.

It's absolutely OK not to have the entire solution in your head straight away. Divide and conquer is often the best way to go when coding!

You should try to identify all the small steps you have to do in order to solve the problem. Then you should focus on tackling them one by one as if they were separate problems.

Let's discuss a particular assignment:

For a given sentence, return the average word length. Punctuation should not be considered.

First of all, let's apply the previous tip and let's come up with an example we can use to visualise the problem better:

The art challenges the technology, and the technology inspires the art.

Our goal is to return the average length of all the words in this sentence (ignoring punctuation signs).

We could split this problem in 3 smaller problems:

1. Remove punctuation from the input string
2. Split the sentence into individual words
3. Calculate the average length of all words

You can see how every step builds up on the result of the previous step.

I personally find useful to write down comments as placeholders to keep track of all the different steps I identified and keep myself in check as I move forward. So my initial implementation might look like this:

function wordsAvg (sentence) {
  // 1. Remove punctuation
  // 2. Split the sentence into individual words
  // 3. Calculate the average length of all words
}

Some people prefers to create dedicated functions for every sub-problem. This is a great approach too and makes sub-problems easier to test independently!

function removePunctuation (sentence) {
  // TODO
}

function splitWords (sentence) {
  // TODO
}

function lengthAvg (words) {
  // TODO
}

function wordsAvg (sentence) {
  const cleanSentence = removePunctuation(sentence)
  const words = splitWords(cleanSentence)
  return lengthAvg(words)
}

A small note here. One might argue that step 1 and step 2 can be done in a single step (by splitting words in a more sophisticated way). While this would be absolutely fine, the suggestion here is to keep things as simple as possible and, generally, the smaller a problem is, the simpler the solution gets.

But we will talk more about simplicity later... 😊

3. Don't run

Photo by Islam Hassan on Unsplash

Once you have a good understanding of the sub-problems you have to tackle, try to focus on one problem at a time.

Make sure every step is completed and works correctly before moving to the next one.

You don't necessarily need to write unit tests for that (even though it might be a good approach), sometimes just printing the output is enough to validate that your approach works.

If you are doing this on a whiteboard and you can't really execute the code, you should be able to simulate the execution manually. We will discuss this a bit more in another tip.

4. Don't generalize too early.

Photo by Kelly Sikkema on Unsplash

It's ok to have a solution that works only for one particular case. Once you have that, it's easier to make it more generic and progress with the assignment!

Once again, let's present an example:

Given a non-empty string s and an integer k, write a function that takes s and k as inputs and returns true if s can be converted to a palindrome string by removing at most k characters.

Now, checking that a string is palindrome is already a challenge on its own, you better start writing a solution that does only that.

Then you can implement a solution that tries to remove only one character and check if the string is palindrome.

Only then it makes sense to generalise and expand your solution to support an arbitrary k.

These challenges might get an order magnitude more complicated as you try to find a more generic algorithm, so don't overdo! Start simple and keep raising the bar as you progress.

Moreover, solving the simpler version of the problem, will provide you with an excellent structure that you can expand on for the more generalised version.

5. Be a robot (just a bit)!

Photo by Rock'n Roll Monkey on Unsplash

We already said that it makes sense to keep your current solution in check. Is your code really doing what you think it's supposed to be doing?

You don't have to run the code to be able to assess that. In most cases, you should be able to simulate the code execution... in your head!

There isn't really a playbook on how to do this simulation. I think the easiest way to approach this is to follow every line and see which statements should be executed and which values are currently assigned to every variable.

It might help to create a little table where you keep the current values for every variable.

Being able to do this mental simulation will not just help you to review your current progress and move closer to a correct solution, but it will also show the interviewers that you can understand and debug code as you read it.

6. Overcommunicate

Photo by LinkedIn Sales Solutions on Unsplash

In coding interviews, communication is key! Communication is, in fact, the most important element of the whole process.

You see, most interviewers don't put too much weight on whether you will actually solve the problem in time or not. It's great if you complete the assignment with clean and performant code, but in reality, most interviewers are more interested in seeing how you approach a challenging problem.

In some cases, the whole coding interview is structured to be a collaborative exercise where you are almost pair-programming with the interviewers.

Therefore it's very important that you make sure you explain what you are thinking and what you are trying to achieve at every step of the process.

It's also good to ask for clarification and even for help if you feel you need that. What would you do if this was a real production problem you were trying to solve and you felt like you are stuck? You'd probably ask for help, right? The goal is to collaborate and make progress, so if you need help to make progress, ask for help. There is nothing to be ashamed of that.

Sometimes interviewers will sense that you are going down a rabbit hole or that you are getting stuck and they might decide to throw a bit of help your way.

Communication is not just one way. Make sure to listen to the interviewers and be ready to catch some hints or suggestions. Maybe those suggestions will bring you to a path that you haven't explored yet and it's great to show that you can react to suggestions and feedback.

7. It doesn't have to be perfect

Photo by Vitolda Klein on Unsplash

As you work through your solution It's absolutely OK to take shortcuts or to simplify the problem.

No one is expecting you to come up with the most comprehensive, optimized and elegant solution on the first try.

Perfection often comes from iteration. Start simple. If you can make it even simpler, do it!

Once you have something that works, you can start to improve it.

This is especially important when it comes to performance. Often coding challenges can be solved using a brute-force approach while probably there is a more sophisticated and optimized solution to them.

It's a good idea to start with the brute-force approach and provide a solution to the problem. Then, you have an opportunity to review your solution, discuss your choices and maybe an idea for a more optimized approach will pop up in your mind. If that's not the case, maybe the interviewers will suggest to you something that you can use to think about an alternative and more performant approach.

You are probably getting the gist of all these suggestions. The main trick is to show progress. If you keep it simple and not perfect, it's easier to do progress. Continuous improvement is progress and this is how things get done in real life most of the time anyway.

8. Exercise

Photo by Victor Freitas on Unsplash

If you are reading this, well you agree with me that coding challenges are hard! So one thing that could definitely help you is... a lot of practice! Before any code interview try to spend some time exercising yourself.

Solving coding challenges is a skill on its own and even if you are a seasoned engineer, you'll need the exercise if you want to keep your coding challenge muscles in good shape.

If you exercise you'll develop your own methodology on how to approach most coding challenges and arrive at the interview more prepared and confident.

If you need some suggestions on which websites you can use for exercise, this is my list in order of preference:

• AlgoMonster: A great website that is focused on helping you to fill all the theory and practice gaps for smashing your next coding interview. It also contains common interview coding challenges from companies like Amazon and Microsoft.
• CodeWars: it has a lot of challenges and supports a broad variety of programming challenges. Probably my favourite!
• HackerRank: probably the most famous platform for coding challenges. It is used a lot also for interviews, so it's a good idea to familiarise yourself with its interface and its coding challenges.
• LeetCode: has a lot of coding challenges and resources. I feel this one is more geared towards beginners, so if you are starting now you might find it more welcoming than the other platforms.

9. Fill the theory gaps

Photo by Aaron Burden on Unsplash

Sometimes coding challenges require you to know certain algorithms or data structures.

The more you exercise the more you'll realize what are the gaps in your theoretical knowledge.

Coding challenge platforms like the one discussed in the previous tip will often give you suggestions and will allow you to see other people's solutions. This is another great way to see if something is missing in your theoretical knowledge.

For most entry level interviews I think you should be comfortable with the following concepts (data structures and algorithms):

• Lists (arrays, vectors, tuples)
• Objects (maps, hashmaps, structs, or dictionaries)
• Sets
• Bidimensional matrices
• Queues
• Stacks
• Binary search
• Recursion VS Iteration
• Mutability (Mutable VS immutable)
• Sorting

For more advanced coding challenges and positions:

• Multi-dimensional matrices
• Trees
• Heaps
• Breadth-first search (BFS) and Depth-first search (DFS)

While you practice with different exercises and confront different solutions, try to make a list of the concepts that come up more often and review them if you feel your knowledge is lacking!

10. understand complexity

Photo by Tim Johnson on Unsplash

Some coding interviews will require you to discuss the time/memory complexity of your solution (big-O notation).

It's one of the most intimidating topics when it comes to computer science, but you don't have to become an expert on it.

In reality, you just need to understand the very basics and be able to give a rough estimate of the complexity of your own solutions.

These are some good resources you might want to check out if you feel you need to improve in this area:

• Big O Notation: Using not-boring math to measure code's efficiency
• All you need to know about “Big O Notation” to crack your next coding interview
• Algorithm Complexity and Big O Notation
• Asymptotic Notations

Make sure to read enough so that you have a good understanding of how to estimate complexity.

Every time you practice a coding challenge, make sure to practice also this aspect and ask yourself "What's the time and space complexity of my solution?"

Do you need help landing your first job?

As I mentioned at the beginning of the article, my friend Padraig is helping engineers to land their first job (btw, I didn't say he is doing it for FREE!).

Padraig can help you to review your CV and cover letter and get you ready for your first round of interviews.

If you want some help, make sure to follow Padraig on Twitter and connect with him on LinkedIn.

You can also book some time with Padraig on his Calendly. But I suggest you reach out to him first! 😋

Are you interviewing for a Node.js position?

I hope you won't mind, but it's time for a little bit of self-promotion here. If you are preparing for a Node.js role, you might want to know that I am the co-author of the best-selling book Node.js Design Patterns.

This book is written to take your Node.js (and JavaScript) knowledge to the next level, making sure you really master how the runtime works and common patterns and techniques to write production-level code.

You might want to have a look at it if you preparing for a Node.js position. 😜

If you do, let me know what you think. I can always use some good feedback to improve the book in future editions!

It's a wrap

Well, that's all I have to share. At this point, I can only wish you the best of luck with your interviews.

Let me know if you found these suggestions useful and, if that's the case, please, consider liking and sharing this article with your friends. You can also follow me on Twitter for more software engineering content. 🤓

If you have any additional tips, I'd love to learn from you. In this line of business, we should always be learning! 😋

See you in the next article!

Credits

Cover picture by Alex Chumak on Unsplash