🤖 How to prepare the coding interview
🤖 How to prepare the coding interview
A step-by-step framework to solve this interview + 🎁 Free Notion Template
Dear software engineer, here’s the guide to crack the FAANG coding interview.
All software engineers fear the coding interview.
For new grads lacking experience, getting the first job is hard. For tenured people, going back to study these interviews is a pain. The internet is full of hardcore grind stories of people doing LeetCode until they collapse. I prefer a structured approach and I bet you also do.
I spend the past couple of months studying for an SDE2 interview at Amazon for an internal transfer. I had to figure out how to prepare it firsthand. Here’s how
This post is one in a 4 post series I’m writing about the technical interview
🗺️ How to prepare the technical interview (Contains an explanation of my study framework)
🤖 How to prepare the coding interview. (this post).
📝 The preparation framework
This is the planning you do before grinding problems.
1) Identify the categories of problems
Hashmaps, trees, graphs, Dynamic Programming, backtracking…
LeetCode has a list of these categories.
2) Identify what you need to refresh and double down on
You may need a few tutorials or a book on Dynamic programming. You’ll use the study resources for these topics
3) Collect your resources for study and practice time.
You’ll explore the resource section of this post and find the best resources for the areas you need to focus on. If you need Dynamic Programming reinforcement, don’t read a book without Dynamic Programming.
🗺️ The interview framework
Start with a clear goal in your mind:
The purpose of this interview is to show fluency in data structures and algorithms.
Not solving a problem perfectly. Not solving it fast and in silence. Optimize for the signals you give the interviewer.
1) Understand the problem
Talk aloud to find your mind to rearrange your thoughts. You don’t even need to use pseudocode. Draw your understanding of a problem with circles, boxes, or whatever is appropriate.
These tips can be useful:
Explain the problem with your own words to validate you are on the same page
Walk through multiple “test cases” of input/output to validate you understood.
2) List the ways you think you can solve the problem, at a very high level
Just natural text. Explain why one solution would be better than another in terms of time and space complexity.
Write down that list. Even if the interviewer is taking notes of your words, having a visual of your thought process helps, they’ll save your code snippet or take a picture of the whiteboard.
It’s also helpful for you to rearrange your thoughts.
Tips:
Don’t start thinking in code, but the nature of the problem. How would you solve it by hand?
Start thinking in the smallest input possible. You’ll generalize later.
Go through a checklist of common data structures and algorithms (Hash tables, trees/graphs, stacks/queues). Does any of them help?
Don’t forget to optimize for space. A common optimization is overwriting the input data structure. If you can do this, just mention it and don’t do it until you have a working solution with another data structure. This is extra complexity, solve your problems step by step.
When you can’t think of anything else, try to optimize your existing best solution. Leave this for last, you don’t want to iterate on a solution that is not optimal from the beginning.
3) Validate before committing
The interviewer can stop you from proceeding if you are missing some possible solution.
Don’t leave this to chance of what type of interviewer you get. Ask explicitly to get a green light to proceed.
4) Code
Keep talking while coding, explaining your thought process.
Do this in 2 phases
Phase-1: Build the skeleton
Go from outside to inside. Don’t code everything top-down, but leave unimplemented functions.
Put TODOs to revisit the edge cases, such as if a loop condition should be < or <=
Phase 2: Finish the code.
If you are short on time, tell the interviewer you’ll assume the existence of your unimplemented functions in the benefit of time.
5) Validate the edge cases
You think your code is “done”. Now spend another 5 to 10 minutes fixing the edge cases.
Walk through the code with the test cases like you did in the first step. Keep talking about what you are doing. Be a human debugger, go line by line, and write in an inline comment the value of important variables values in each line.
Test the typical edge cases: Empty input, 1 element input, test what happens with the first and the last elements. Be careful with null input.
⚙️ Preparation resources
🧑🎓 Deliberate study time
Focus your study time on the category of problems you need more reinforcement.
Don’t study a book from start to finish. Create notes and cheat sheets to organize your knowledge. The coding interview is not an exam to regurgitate memorized knowledge but to apply the knowledge that you understand.
Pick what you need. For example, I only had time to read the first two books for my interviews, but had the list of resources in case I was faster than I expected.
Recommended resources:
📚 Grokking Algorithms → Pretty good visuals.
📚 Introduction to algorithms → Don’t even try to read from start to finish. Use as reference material for specific topics.
📚 Elements of programming interview Java book / Python book → Use this only if it’s your chosen language, I had in my list the Java book
🧑🏭 Deliberate practice time
There’s a curve of diminishing returns as you increase the difficulty of LeetCode problems.
The best way to challenge yourself is with a high volume of Easy/Medium LeetCode problems. This provides enough repetition to solidify a concept and it’s challenging enough to need active recall of the possible solutions without arriving immediately at the optimal solution.
Apply the interview framework when you are solving the problems. You won’t get good at interviewing if you don’t practice like if it was an interview. And check the solutions to understand find other alternatives and get unstuck.
Recommended resources:
🔗 Go to grind75 and create your schedule of easy/medium problems
🎁 The Notion template of my preparation. I went to LeetCode, picked low/medium problems of each category, and put them in a Notion database. Then I started working on them without knowing which category they were for.
🛡️ Siege your brain time
Read lightweight GitHub READMEs to refresh some concepts and browse some LeetCode problems just for fun
Resources:
🔗 Refresh the different types of Data Structures link
🎥 Back to Back SWE YouTube channel
🎥 Gaurav Sen YouTube channel
🎥 Tushar Roy YouTube channel
🍱 Other advice
1️⃣ Pick one programming language and stick to it
Most people recommend Python, it’s less verbose.
When I joined Amazon, I used Python just for the interviews. I had enough time to prepare despite not having used it too much. When preparing for my interviews to switch teams, I used Java. It’s the language I’m comfortable with, I use it day to day and now I have the time restriction of a full-time job. I can’t afford to ramp up in a new language.
Remember, the goal of the interview is to show fluency in the data structures and algorithms. A programming language is just a tool but won’t influence much.
If Java is too verbose, just type faster :)
📊 Create a cheatsheet of your programming language:
With more data structures you just need the name of the class and methods to add elements, remove elements, and look at elements.
Have this next to you when solving problems. In the interview, you can use generic add(), remove(), peek() if you don’t remember
🫀 Study the core techniques:
LeetCode already has tagged the problems by techniques used to solve them. There are common ones you want to know, such as solving with greedy solutions, 2-pointers, linked and double-linked lists…
You won’t know it all. Prioritize.
👔 Be critical with LeetCode solutions
When exploring solutions from other people, be very critical whether it’s relevant for you or not:
Titles like “1-line solution”, or “best space complexity” may contain code unreadable or overly complex changing inline the data structure
Don’t try to memorize weird hacks. Some problems have a trick that makes them easy (or makes them solvable). Unless it’s something reasonable for every software engineer to know, such as bit manipulation, don’t stress over hacks. It’s discouraged by companies to choose problems with one single solution or hacks. If they do, they should provide the hack as a hint.
🎁 BONUS: Don’t forget the object-oriented programming / clean code interview
Many companies have such interviews. Sometimes as a coding problem, others as a code review or take-home challenge.
The approach is similar to the data structures and algorithms problems
Talk aloud about your approaches and validate before typing classes and interfaces
Think about extensibility even if the initial problem is very small. Favor classes and interfaces over if/else and switch statements
Refresh OOP concepts and be comfortable talking about them: Encapsulation, Abstraction, inheritance, polymorphism, overloaded methods.
Refresh design patterns
Practice problems and explore other people’s solutions
Resources:
⭐ Remember interviews are a proxy for competence, not the end goal:
A lot of the resources around coding interviews are about grinding. Remember that the objective is becoming a robust engineer that people would hire, not faking in an exam.
Be a truth seeker. Find the reason why things work this way. Don’t do everything based on assumptions you don’t understand. That’s a house of cards that falls apart once an interviewer asks: “Explain me why a hashmap is O(1) time“
🗃️ Resources from this post
🔗 grind75
📚 Elements of programming interview Java book / Python book
🔗 Refresh the different types of Data Structures link
🎥 Back to Back SWE YouTube channel
🎥 Gaurav Sen YouTube channel
🎥 Tushar Roy YouTube channel
👏 Weekly applause
We passed 1.5k subs this week! The article on my framework to prepare the technical interview was featured in the TLDR web dev issue of Dec 18th
Here are some interesting pieces of content I went through recently:
📝 How To Write an Effective Self-Review by
→ Very relevant for me as it’s feedback season in Amazon. I bet many other companies have the feedback cycle during this time of the year.📝 Becoming a Tech Lead at Google by
with → Despite not being in a Tech Lead position, I find the lessons very valuable. We all have to exercise these leadership traits in our day-to-day job📝 Engineers' Guide to Feedback by
→ Article full of value to make feedback a tool for growth, not to vent or feed your ego. I’m fully aligned with not doing sandwiches but talking openly and with candor when there’s negative feedback.🎥 Lex Fridman interview with Jeff Bezos → Besides becoming a trillion humans and inhabiting space, I LOVE hearing Jeff talking about company cultures. What he created at Amazon is very special.
