You know; I used to think I could show up to an interview and ace a code challenge without any extra preparation; besides my computer science studies and my daily coding sessions.
I was...greatly mistaken. After very disappointing interviews, it was obvious something was wrong. I knew I could code, so what was the problem? Well, I discovered several problems, but one of the biggest ones was that I didn't have a process!
Over several years I developed an interview process that allowed me to:
- Feel more confident during code challenges (and...avoid panicking as much haha).
- Increase the chances of arriving at a working solution.
- Showcase my skills even if I can't produce working code.
Today, I want to share my process with you :)
The Big Picture
You are going to:
- Understand the problem
- Experiment by solving several examples
- Identify an algorithm
- Optimize your algorithm
- Write code (Notice how this is step 5 out of 7)
- Discuss possible improvements
- Be proud! We did it!
Let's add more detail on how this system works; but before that, two important points:
- This is a flexible process; play with it and make it your own. As a general guideline; the more confused I am in an interview, the more I rely on the process.
- You can download a nice cheatsheet of the process by clicking here!
With that said. Let's do this!
1 - Understanding the Problem
This is the most important step in the entire process. It was born out of my biggest interview mistakes. Many people start writing code as soon as the interviewer finishes describing the problem.
I think that's one of the worst mistakes you could make in a code challenge. Here's why:
- If you misunderstood the problem, you are going to waste precious time whilst getting back on track.
- You are trying to solve the problem as you code, and, what's worse, you didn't give your brain enough time to come up with a solution.
What do I do then?
Luckily for us, there is an effective way to avoid this pitfall: carefully examine the problem and identify some key details:
- Goals
- Inputs & Outputs
- Scope
- Assumptions
- Constraints
Ask a healthy amount of questions if anything seems unclear. These details will allow you to create a solid algorithm without annoying bugs blindsiding you as you code.
Re-stating the problem
Before moving to the next step, it's useful to re-state the challenge to the interviewer. Think about this as a final chance for you or the interviewer to catch any misunderstandings.
2 - Experimenting with Examples
Is it time to think about for loops? Nope. It's time to visually solve 1-3 regular examples and 1-3 edge cases.
...Why? I need to get to the code dude!
Here is the thing:
Your brain is already an amazing problem-solving supercomputer.
You may be doing yourself a disservice by immediately thinking about loops and variables. You could even end up coding a faulty implementation.
By spending some time visually solving examples, you are going to give your brain enough time to recognize patterns that can be used to solve the problem. These patterns are harder to see if you are already thinking about how to name your variables or other implementation details.
Also, if you have absolutely no idea about how to solve a problem, you are doing something much more productive than just staring at the problem and thinking really, really hard.
Notice how I'm asking you to equally divide your time between regular cases and edge cases. Regular cases are used to identify patterns and edge cases are used to make sure we have a solid algorithm. I often see interviewees neglect one or the other. They are equally valuable!
3 - Identifying an Algorithm
Take a look at the previous step. Think about the process your brain followed to solve the examples. What are the common steps? Can you think of a way to express those steps in a way that can be 'mechanized' by the computer?
Notice how I didn't call this step 'Identifying an Optimal Algorithm'. For now, I'm asking you to focus on finding something that works, and later, you'll focus on optimizations.
How do I keep track of my algorithm?
I recommend that you document your thought process using English as much as you can. However, if you identify the most complicated (or confusing) part of the problem, you could use pseudocode to give yourself a little more clarity.
Having said that, I do recommend that you stick to English since you are going to optimize your algorithm in the next step.
What happens if I can't identify an algorithm?
I can (and will) write several more articles about what to do when you are stuck, but my go-to moves are to try to divide the problem into smaller problems or to reduce the problem into a simpler version.
Don't worry. I'll come back soon with more material about what to do when you are stuck.
4 - Deciding on an Algorithm to Code
Now that you have a solid algorithm, it's time to think about optimizations. I recommend you start by noting your current time and space complexity (also known as Big O).
Once you have that, brainstorm data structures, algorithms, and functions that could improve performance. Have a conversation with the interviewer about whether they want you to optimize for time or space.
Notice how I didn't say 'Finding an O(X) solution' or 'Finding the most optimal algorithm'. Finding the best algorithm is the goal, but don't panic if you can't find it.
Spend a healthy amount of time here, select an approach, and then move on. A working solution is more valuable than an incomplete challenge.
How much time should I spend here before I move to step 5?
That's a great question! I like to give myself 10-20 minutes to write code and discuss improvements, so I recommend you spend 10-20 minutes here. (This assumes a 1-hour interview with only one problem)
I'll write an article with a breakdown of recommended times by interview step, but I hope this is enough information for now.
It's finally time to (maybe) use pseudocode.
As I said before, I don't recommend you always use pseudocode in code challenges, but I recommend pseudocoding areas that are particularly confusing or complicated.
Why? Because pseudocode allows you to think about your algorithm from a high-level perspective; without dealing with the lower-level detail required by code. Keep pseudocode to a minimum though, and use it only to answer specific questions about your approach.
Now it's time to...
5 - Writing Code
FINALLY. Finally!? What great wisdom can I share with you about the "most important step" in the interview process? You'll have to go back to step 1 since that's the most important step. Here, we'll just write some code.
Writing code should be the most boring part of the interview. All of the uncertainty of the challenge should have been clarified in the previous steps. If you have a lot of questions at this point, we have failed at successfully navigating the code challenge.
I do recommend two things for this step though:
- Consistently double-check your examples to make sure that your code is not missing a vital step or edge case.
- Don't forget to state your code's performance. Often the interviewer will remind you about it, but you can't count on that.
6 -Discussing Improvements
Now that you are "done" and the interview is about to end, mention possible improvements to your algorithm:
- What would you change about your algorithm if you had more time to work?
- How would you build a unit-test suite for your algorithm?
7 - YOU DID IT!
You did it! High Five! If everything worked out you should have had a successful code challenge interview. Maybe even a job offer in a couple of days!
Of course, it's easier said than done. In the next several months, I'll be going deeper into each step of this process. In the meantime, head over to cadejo.dev and grab your interview process cheatsheet! Also, reach out on social media to let me know how you like it!
Before I go though, I want to thank all the students and teachers that helped me build this process over several years of my career. I'm standing on the shoulders of giants and I couldn't have done it without you all!
Top comments (0)