As someone that has a non Computer Science college degree and did not have a strong background in algorithms, I always dreaded problem solving interviews and didn't think I'd be able to get a job at FAANG companies. I'm sure a lot of you are in the same position, so this article is a summary of my learnings in the past few years that enabled me to work at 2 of these companies.

I will focus on problem solving questions here as this was the hardest part for me to master through trial and error. I may follow up with articles on system design and behavioral questions later.

This will be a concise guide to help you pass the interview with minimal effort. I won't ask you to read lengthy books, and this article won't necessarily help you become a better engineer, but my aim is to help you do your best in algorithms interviews.

Disclaimers

1. This article is based entirely on my experience as candidate, not on any inside knowledge of interviewing processes. It's based on my experience interviewing at Amazon, Meta (Facebook), Google & Apple, but I imagine it's applicable to many large tech companies.
2. Do your own research on the company and team before your interview. Some companies hold online sessions to help you prepare for interviews which are very useful to learn about the specifics of a certain company.

---

1 Before the interview

1.1 Get the interview, obviously

When you're applying at big tech companies, you are more likely to get an interview round if an employee refers you for the job. I experienced applying online on my own and getting no reply at all, and then applying with the exact same CV through a referral and getting a call within days.

If you know someone at the company, don't hesitate to ask for a referral. Most people will help if you ask, and they may get a bonus if you are hired. If you don't know someone personally, you can try to build more connections through online forums or meetups. You can also reach out to recruiters or managers who are hiring directly on Linkedin.

1.2 Build algorithms foundation

If you don't have a strong background in algorithms (like myself), you need to start with the basic concepts and common algorithms. Your goal here is to be familiar with topics like sorting, searching, array/string manipulation, stacks, queues, hash tables, trees, basic graph traversals.

There's plenty of courses online for this. I personally refer to Princeton Algorithms Course Part 1 & Part 2

Part 1

Coursera https://www.coursera.org/learn/algorithms-part1
Youtube https://www.youtube.com/watch?v=9diDWV-fOnE

You need to know most of the algorithms in part 1, but focus on the more optimized solutions like quicksort & merge sort

Part 2

Coursera https://www.coursera.org/learn/algorithms-part2
Youtube https://www.youtube.com/watch?v=0qF7tPSQdCg and https://www.youtube.com/watch?v=6TW3JSVEJQE

You only need a few topics from part 2, like graphs and tries

There's also a cheat sheet from the course here https://algs4.cs.princeton.edu/cheatsheet/

Your goal is to understand the basic ideas from the course, then you will practice more coding when you start solving problems. Try not to take more than 1-2 months covering this course.

1.3 Practice problem solving

There are a lot of websites to practice coding problems, but what I found most useful is Leetcode which has a paid feature that shows you the exact questions that were asked at a specific company, and also can sort by most commonly asked questions, so you can practice with the most likely & realistic questions eg: https://leetcode.com/company/amazon/

The Leetcode premium plan is $35/months and you will only need it for 1-2 months when you are preparing. If this is too expensive in your local currency or you are a student, you can reach out to Leetcode and ask if they have discounts for your case. Lots of tech companies will happily offer a special discount even if they don't advertise it publicly.

It’s important to cover as many problem ideas as you can, even if you think about a problem for a few minutes then jump to see the solutions. Don’t think too long about problems marked “hard” or dynamic programming problems as they aren’t likely to show up in the interview, just check the solution and move on. Try to code 1 problem every study session and think about a few other problems then read their solutions. Practice to think out loud and narrate the solution as you code.

There's a good statistical likelihood that you won't pass the interviews on your first try, or that you will interview again in ~2 years if you get hired. So you should keep notes of all the problems you read with their links and their high level solution. This will save you a lot of time when you prepare for the next interview as you will start by going through these problems and refresh your memory instead of starting from scratch.

Also, this nice site will send you a random algorithms problem every day https://www.dailycodingproblem.com/

In the final review days before the interview, review the code for the common algorithms like depth first search, breadth first search, tree traversals with different order & binary search

1.4 Debug your code WITHOUT RUNNING IT

This is the single most important tip in this whole article. When you're practicing with something like Leetcode, it's very tempting to run your code immediately and see which cases fail and try to guess what went wrong. This is likely what you do when writing code daily, you write some code and run it to see if it works. This is the worst thing you can do when preparing for interviews.

In a problem solving interview, you usually won't be able to run your code, and interviewers expect you to be able to review your code and spot any bugs. Think of it as reviewing a pull request and trying to find issues with it. You should try to find all bugs and edge cases BEFORE running the code, as you will do in the actual interview. Your goal is to pass all test cases on the first run. More details on how to do this below.

1.5 Practice interviewing

The best practice for interviews is interviews. Try to interview more often. Do not wait 4-5 months to prepare before an interview. You will learn more from failing an interview than any preparation, and most companies allow you to apply again after 6-12 months.

If you have an important interview at a company you like, try to arrange 1-2 interviews at other companies (with a similar process) before it as practice. This way you will be less stressed about the important interview and if you end up getting multiple offers you will be in a better place to negotiate.

Even if you aren't actively looking to move, it's useful to interview every 1-2 years. This will help keep your interviewing skills sharp, and if you get a better offer it can help you negotiate a raise or promotion if you decide to stay.

If you can't easily get interviews at multiple companies, there are online services to set up mock interviews with experienced interviewers and get their feedback. I haven't tried these services so I can't recommend any of them. If you have a recommendation, please leave a comment with it.

---

2 In the interview

2.1 Before coding

• Most companies switched from whiteboards to a code editor for coding interviews. If you have a choice, I recommend using a text editor as it’s much easier and faster to modify your code than on a whiteboard.
• If you have a choice of which programming language to use, choose the one you’re most comfortable with. You want to focus on solving the problem, not remembering syntax. If you know multiple languages, choose one that’s faster to write. For example: manipulating lists and maps is easier in JavaScript or Python than Java.
• Ask questions to clarify the problem and confirm your understanding.
• Ask about the input & output formats, and valid ranges.
• Mention any assumptions you make (don’t assume trees are binary search trees or balanced).
• Draw/solve the problem verbally with some examples to validate your ideas.
• Mention non-optimum solutions briefly but try to come up with a more performant solution before starting to code.
• Mention the expected space & time complexity of your solution and if there are bounds on complexity, eg: if you must check all array items the complexity can't be lower than O(n). Make sure you include any steps like sorting or copying lists in the complexity.
• Think about possible preprocessing scenarios that can optimize the overall solution, like sorting an array before traversing.
• Some problems can be optimized by mutating the input, ask the interviewer such a solution is acceptable.
• Don’t start coding until you and the interviewer feel good about the solution.

2.2 During coding

• Outline the skeleton of the solution with comments, this prevents you from forgetting a step and helps the interviewer follow along.
• Write correct code, not pseudo-code. Minor syntax mistakes are usually not a problem.
• Apply all best practices of the language you use. Show the interviewer that you can write clean, maintainable code.
• If you’re using an uncommon language or one that the company does not use, explain any advanced language features you use that the interviewer may not be familiar with.
• Split your code to smaller functions with expressive names to clarify intent and make it easier to test. You may not need to implement some small functions if the interview says they aren’t important, which can save you some time.
• Explain your solution and decisions as you code. Think about which alternative provides a more accurate solution, is this solution opinionated or generic?
• Leave a // TODO for input validation and other non-critical steps if you don’t want to spend time on them initially. The interviewer will notice your attention to these details.
• Use clear & expressive variable names to help the interviewer understand and help yourself avoid mistakes. Instead of names like i or j, use something like currentBookIndex
• Use variables for array access to clarify intent, eg: currentCell = grid[rowIndex][columnIndex]
• Think about early return conditions and optimizations.
• For most problems, the solution should not be too long or too complicated. If your code exceeds ~30 lines and has several if/else branches, try to rethink it.
• When stuck, think out loud and try to draw your thoughts on paper. Listen to the interviewer if they provide hints, they won't trick you.
• Mention any limitations or potential optimizations. You can leave comments to revisit them if you have time later.

2.3 After coding

This is the critical part. Most people think they are done after coding the solution and don't pay attention to these steps. I personally failed multiple interviews just because I was too tired or too hasty to follow them properly

• Run through the code verbally. Read the actual code you wrote carefully, not what you think you wrote. Forget that you wrote the code and examine it like it's garbage code that some idiot posted on Stack Overflow. You are biased to think that your own code is bug free and it takes effort to train yourself to interrupt this bias. If you can't find 1-2 bugs, then you need to try harder.
• Look for specific parts of code that tend to cause bugs like: off by one errors in loops, math calculations, recursion exit conditions, what if a loop has no elements, what if a stack/queue becomes empty, what if input is null, empty input array, array of 0/1/2 items, input with duplicates, 0 or negative numbers, ...
• Verify that space & time complexity match what you expect.
• Ask the interviewer if you should come up with test cases for the code. List test cases with all different scenarios as if you are writing unit tests for your code.
• Ask the interviewer if you should trace the code with a test case. Choose a small but non-straightforward test case to trace and debug your code on paper/board. Go through the code line by line keeping track of variable values and look for any bugs and modify your code as needed.

---

Final remarks

Problem solving interviews require some specific skills which may not always be relevant to your actual job. You need to train for these skills and understand that it might take a few tries to get it right.

If you fail, remind yourself that these interviews are not a great measure of your skill as an engineer which is impossible to measure in an hour. It doesn't matter how many times you fail as you only need to make it once. Learn from your failure and document all questions you encounter in interviews or practice to help you prepare better next time.