Disclosure: This post might contain affiliate links. If you click through and make a purchase, I’ll earn a commission, at no additional cost to you. Read my full disclosure here.
The goal of this post is to explain how to prepare for Software Engineering interviews. I will give an overview of the structure of the tech interviews, do a deep dive into the 3 types of interview questions, and provide resources for mock interviews.
This is part of a mini-series of posts related to career development. The other related posts are:
- Interview Preparation Guides
- Role-specific information
- Software Engineer Salary In 2023: A Comprehensive Guide
- My Experience As A Microsoft Software Engineer: A Deep Dive
- Career Advice for Software Engineers
- What are the differences between Product Managers, Program Managers, Engineering Managers and Marketing Managers?
- Best Courses and Books to Improve Soft Skills
- Inside the Culture of the Top Tech Companies
- Overview
- Coding Questions
- Step 1: Understand the fundamental concepts
- Step 2: Practice programming questions using LeetCode
- Frequently Asked Questions
- Which programming languages should I use?
- How should I approach the problems?
- How should I prioritize which problems to solve?
- What if I need more detailed/structured solutions for some problems, because the idea is not clear, even after reading the solution?
- How will I know when I am ready to interview?
- System Design Questions
- Behavioral Questions
- Mock interviews
- Salary negotiations after a job offer
Overview
The typical hiring process for the big tech companies consists of 2 rounds of interviews:
- Phone interview (45 minutes): The interviewer either calls the interviewee via a phone call or uses a Communications app (e.g. Skype, Zoom, etc)
- Onsite interview (4-5 interviews, 45 minutes each): This is an in-person interview, where the interviewee visits the company’s offices and talks to the interviewers face-to-face
There are 3 types of technical interview questions:
- Coding problem, e.g. merging 2 sorted linked lists into a sorted linked list
- System design questions, e.g. how would you design Twitter/Uber/Airbnb/Facebook/Skype/etc
- Behavioral questions, e.g. tell me about a time when you had to resolve a conflict
For more information about the types of software engineer interview questions, you can take a look at the following resources:
- Official interview preparation guides for Software Engineers from:
- Facebook (download the interview prep guide at Step 2)
- Official blog post on the Facebook Careers website
- How to Interview At Amazon by David Anderson (Bar Raiser)
- Facebook (download the interview prep guide at Step 2)
- Software Engineering interview guides from Exponent for:
The types of technical questions that are asked during software engineer interviews depend mostly on the experience of the interviewee, as is shown in the matrix below.
Coding problem | System Design questions | Behavioral questions | |
---|---|---|---|
Entry-level Google/Facebook: L3 Amazon: L4 Microsoft: 59,60 | Yes (most important question) | No | No/Limited |
Intermediate Google/Facebook: L4 Amazon: L5 Microsoft: 61, 62 | Yes | Yes (differentiating between Intermediate and Senior level) | No/Limited |
Senior Google/Facebook: L5 Amazon: L6 Microsoft: 63, 64 | Yes | Yes (differentiating between Intermediate and Senior level) | Yes (differentiating between Senior and Principal level) |
Principal Google/Facebook: L6 Amazon: L7 Microsoft: 65-67 | Yes | Yes | Yes (differentiating between Senior and Principal level) |
As is shown in the matrix above:
- Entry-level candidates are only asked coding questions
- The differentiating factor between whether a candidate will get an offer for Intermediate level or Senior level are the System Design questions
- The differentiating factor between whether a candidate will get an offer for Senior level or Principal level are the Behavioral questions, e.g. to understand previous leadership experiences
The following sections go into further detail about how to prepare for each question type.

Coding Questions
Step 1: Understand the fundamental concepts
The first step is to understand/refresh the fundamental concepts, e.g. linked lists, string handling, tree parsing, dynamic programming, etc.
Books
The following books are great resources:
- Cracking the Coding Interview: This is a great introductory book
- Elements of Programming Interviews: This book goes into much more depth. Depending on your preferred programming language, you can buy the version that uses C++, Java or Python
- The Algorithm Design Manual: This book is more advanced and can be used as a very useful resource while working on Leetcode problems. Many Leetcode problems are based on the algorithms that are shown in the book
YouTube videos
If you prefer to watch YouTube videos, then you can use the following:
- Back to Back SWE channel: Lots of videos on fundamental concepts. Also, it includes very easy-to-understand explanations of dynamic programming, which is always a tricky subject
- Dynamic Programming for Beginners: Great introduction to Dynamic Programming, which is one of the most difficult types of questions that are asked during the interviews
Classes
Finally, if you prefer to read the structured material online in a class format, then take a look at the following:
- 14 Patterns to Ace Any Coding Interview (by Hackernoon): Great way to start your preparation by mastering these 14 basic patterns
- Problem Solving with Algorithms and Data Structures using Python by Runestone Academy: Includes free open source book, as well as class videos
- Educative.io: Multiple paid courses targeted specifically to interview preparation. All of them are great classes, especially if you are starting with your interview preparation.
- Exponent: Great paid courses to begin your interview preparation:
- Geeks for Geeks: Online portal that goes through several Computer Science concepts and also includes a step-by-step preparation guide, as well as company-specific preparation guides
Step 2: Practice programming questions using LeetCode
LeetCode is the current standard for coding interview preparation. Most candidates will solve hundreds of questions (e.g. 300-500) in preparation for the top high-tech companies. Also, interviewers typically select their questions from the LeetCode question database. There are other similar platforms (e.g. HackerRank), but my suggestion is to use LeetCode as your main website for coding practice.
Frequently Asked Questions
Here are some answers to the most common questions about how to structure your preparation.
Which programming languages should I use?
- If you have extensive experience in a software engineer position, you probably have a preferred programming language that you are most comfortable with. Use that one.
- If the job description refers to a specific language, then use that one.
- If you feel comfortable with multiple languages or want to learn a new one, then most interviewees use Python, Java, or C++. Fewer use C# or Javascript.
- Python: Requires the least lines of code, which is important, when you have time constraints. Also, it’s the only option for ML jobs. However, it might lead to complicated code (especially for interviewers, who are not familiar with Python) and it does not support binary trees natively.
- Java: Supports Object-Oriented Programming and simplifies garbage collection
- C++: Lots of advanced features such as pointers, memory management, etc which make the language very powerful, but also requires more lines of code and is more prone to errors. If you decide to use it, you should also learn STL.
- You can also read some additional thoughts regarding this question from the Tech Interview Handbook
How should I approach the problems?
- In the beginning, try to spend at least 45 minutes on each problem before looking at the optimal solution. As you progress, this number should decrease quite a bit, because in most interviews you’ll need to answer 2 Medium questions in 45 minutes.
- If you look at a solution and understand it, then always return to the problem and write the code yourself (without looking at the solution).
- Keep notes for each problem that you solve, so that you can refer to them later
- Make sure that you understand the pattern that is used to solve each problem, instead of memorizing a solution. This way you’ll be able to recognize patterns between groups of problems (e.g. “This is a new problem, but the algorithm looks similar to the other 15 related problems that I’ve solved”.
- You’ll know that you are progressing when a) you understand the pattern required to solve each problem just by reading it and b) you see the time required to solve each problem get lower (e.g. “I solved problem A in 50 minutes and problem B in 30, even though both of them use the same approach”)
How should I prioritize which problems to solve?
- Start with the Blind 75, which is a curated List of Top 75 Questions (also available as a LeetCode list, but it’s missing the problem “Cherry Picking #741“). This list was created by somebody who finished 500 LeetCode problems and kept track of the most useful ones.
- Continue with Neetcode 150, which is a curated list that includes 75 additional problems, on top of Blind 75.
- Afterward, it’s a good idea to review LeetCode’s Top Interview Questions. This list has been created by LeetCode and consists of very popular questions. It also has a partial overlap with the previous list. Make sure that you finish with all the Medium problems on that list.
- Take a look at the curated list of 170+ Leetcode questions grouped by their common patterns by Sean Prasad (answers shown here)
- The Tech Interview Handbook has a 5-week list of Leetcode problems to practice on a weekly basis
- Buy LeetCode Premium (currently $35/month). Look at the top problems for the companies that you are targeting. At a minimum, practice with the lists that include the top 50 questions for Google and Facebook.
- Remember that most Easy problems are too easy for an interview, whereas the Hard problems might not be solvable within the interview slot (45 minutes typically). So, it’s very important to focus most of your time on Medium problems. A good ratio of Easy/Medium/Hard is 20/70/10.
- If you identify an area, that seems more difficult than others, you should take some time to dive deeper by reading books/tutorials, viewing videos, etc in order to understand the concepts better.
- Practice with the mock interview sets. They have a time limit and prevent access to the forum, so they are more geared to a real interview. You can also compare your rating against everybody else, who did the same set of problems.
What if I need more detailed/structured solutions for some problems, because the idea is not clear, even after reading the solution?
Observe how others approach the problems, evaluate different solutions, and learn from their detailed thought process, instead of directly looking at the optimal solution:
- Nick White’s LeetCode Solutions playlist on YouTube: Nick has recorded himself solving ~190 LeetCode problems
- Kevin Naughton Jr’s LeetCode Coding Interview Questions playlist on YouTube: Kevin has recorded himself solving ~120 LeetCode problems
- User Grandyang from Cnblogs has solved > 900 Leetcode problems and has posted his solutions with comments in Mandarin (English translation via Google Translate)
- Hacking the Coding Interview by Educative.io: This is a paid course that covers ~80 LeetCode problems in detail
How will I know when I am ready to interview?
- The most important metric is how fast you can solve each category of problems.
- Remember that the duration of most interviews is 45 minutes, which is not much time. During these 45 minutes, you’ll have to solve either 2 Medium problems (most common case) or 1 Hard.
- Here are some same target times for each category:
- Easy: 5-10 minutes
- Medium: 15-20 minutes
- Hard: 30-40 minutes
- In order to reach those levels, you’ll need to solve around 200-500 LeetCode problems, which corresponds to 3-5 months of preparation time. These numbers are just a rule of thumb, as the actual time depends on your current coding experience and knowledge.

System Design Questions
Step 1: Understand the structure of the expected answer
Your first goal should be to understand what the system design interview is about, i.e. what types of questions are asked, how to structure your answer, and how deep you should go in your answer.
- Read the section “How to approach a system design interview question” from the System Design Primer
- Read the course materials from Hired In Tech to get another view of the sample structure
- Start with this example from Practice Coding Interview to see a full answer
- Educative.io classes
- Grokking the System Design Interview class (section “System Design Problems”)
- I highly recommend buying the full class, especially if you are starting with system design. It is a great class to understand the basic structure of a system design problem
- Grokking the Object Design Interview class
- Great class to learn about Object-Oriented design
- Grokking the System Design Interview class (section “System Design Problems”)
- Exponent class
- Read the System Design Cheatsheet by vasanthk
Step 2: Dive deeper into the building blocks required to answer these questions
After going through a few of the above examples, you have probably heard lots of new terms and technologies that you are not so familiar with. In order to be able to answer these types of questions you will need to dive deeper into a lot of different technologies.
Fundamental concepts
My suggestion is to start with the following videos that provide an overview of how to design scalable systems.
- Building Dynamic Websites – Harvard CS75 (Summer 2012) by David Malan. The linked video is from lecture 9, which summarizes the whole class, but if you want to dive deeper into specific areas, you can also view the rest of the videos in the class
- Distributed Systems in One Lesson by Tim Berglund
- Four Distributed Systems Architectural Patterns by Tim Berglund
- Building Financial Systems on Eventually Consistent DBs by Rahul Pilani
Intermediate concepts
The following websites have a sample list of additional design concepts that you should be familiar with:
- System Design Primer (section “Index of system design topics”)
- Gaurev Sen’s YouTube Tutorials
- Grokking the System Design Interview (section “Glossary of system design basics”). This is a good list of topics that you need to know
- Mario Gerard (section “Here Is My List of Fundamental Technical Workings A TPM Needs To Know” – scroll towards the bottom)
Advanced concepts
Finally, if have enough time and really want to dive deep into system design, then you can read about more advanced concepts at the following resources:
- The High Scalability blog has a series of posts titled Real Life Architectures that explain how some popular websites were architected
- The book “Designing Data-Intensive Applications” by Martin Klepmann is the best book regarding system design
- The “Amazon’s Builder Library” explains how Amazon has built their own architecture
- If you really really want to dive deeper into how existing systems are built, you can also read the published papers on GFS, Dynamo, Haystack, Cassandra, Bigtable, Raft, Paxos, Chubby, Zookeeper, Spanner, Haystack, Kafka, Azure Storage, TAO by Facebook, Memcache
The list of resources is endless, so make sure that you don’t get lost trying to understand every little detail about every technology available. Also, feel free to go to the next step, where you practice with additional questions, and use this section as a reference.
Step 3: See how others answer design questions
Now that you understand the structure and the building blocks, your next goal should be to get a good understanding of how other people answer these types of questions. Videos are a great way to do this. YouTube has a lot of great channels answering how to design Twitter, Pastebin, Uber, etc. Here are some great channels to start with.
- Tushar Roy – System design
- Success in Tech
- System Design Interview channel
- YouTube playlist with multiple system design videos
Step 4: Practice, practice, practice
The most important part of your interview preparation is to practice real design questions. The following websites have questions and answers:
- System Design Primer (sections “System design interview questions with solutions” and “Additional system design interview questions“)
- System Design Preparation by shashank88 (section “Common Design Questions“)
- Grokking the System Design Interview class (section “System Design Problems”)
- System Design Interview (section “Hot Questions and Reference“) by checkcheckzz
- Crack the system design interview at tianpan.co

Behavioral Questions
The behavioral interview questions are the best way to test your problem-solving skills and your communication skills by evaluating your past experiences in real-world scenarios. Most of the questions focus on how you handled technical problems on past projects. The goal is to determine whether the software developer is a good fit and a team player.
Some examples of behavioral questions are:
- Tell me about a time when you influenced or pushed back on a tech design.
- Tell me about a time that you made a trade-off call that involved engineering
- Tell me about a project that you’re most proud about
- Tell me about a time that you failed
- Tell me about a time when you had to resolve a conflict
- Tell me about a time when you led a team
The SCRIPT Framework
The most common framework to answer behavioral questions is the STAR (Situation, Task, Action, Result) framework. However, I believe that his framework is not enough. As I explain in my blog post STAR is Not Enough: Tips For Behavioral Interview Questions, I recommend that you use the SCRIPT framework.
- S: Story Title
- Begin with a captivating title for your story to grab attention and set the tone for your narrative.
- C: Context Explanation
- Detail the context, including the project, the team members involved, and the important task at hand, ensuring you paint a vivid picture of the situation.
- R: Role Definition
- Clearly define your role in the scenario, highlighting your job description, leadership skills, and how you contributed as a team player.
- I: Issue Identification
- Identify 3 specific problems you encountered, like a tough decision or a challenging situation under a lot of pressure.
- P: Problem-solving Actions
- Describe 3 actions you took to address each problem, emphasizing your time management skills and your approach in similar situations.
- T: Tangible Outcomes
- Conclude with the positive outcomes of your actions, such as meeting a tight deadline or achieving better results, showcasing your ability to handle stressful situations.
Answering A Question using the SCRIPT Framework
To demonstrate how the SCRIPT framework can be applied, we need to look at specific examples.
Let’s take the question “Tell me about a time you faced a difficult problem at work. How did you solve it?” and answer it using SCRIPT:
S (Story Title): “The Bug Hunt Odyssey”
C (Context Explanation): In my last job as a Software Engineer, we were in the final stages of a major product release when we encountered a critical, elusive bug. The project was already running tight on schedule, and this bug threatened to delay the launch.
R (Role Definition): As a senior member of the development team, I was responsible not only for coding but also for ensuring the quality of our deliverables.
I (Issue Identification):
- Intermittent Bug: The primary issue was an intermittent bug in the software, which was difficult to replicate and trace.
- Inadequate Testing Methods: Our existing testing procedures weren’t robust enough to catch this type of elusive bug.
- Pressing Deadline: The project was on a tight schedule, and any delay in fixing this bug would postpone the product launch.
P (Problem-solving Actions):
- Targeted Test Design: I developed a series of specialized tests aimed at consistently replicating the bug to understand its pattern.
- QA Team Collaboration: I worked closely with the Quality Assurance team to refine our testing strategy, ensuring a more comprehensive coverage.
- Extended Work Hours: To mitigate the time lost in bug fixing, I extended my work hours, focusing on resolving the issue without impacting our delivery timeline.
T (Tangible Outcomes): My approach led to the identification and resolution of the bug within 48 hours. We met our launch deadline, and the product was well-received, contributing to a 15% increase in client satisfaction scores. This experience also led to the adoption of more robust testing procedures in our team.
Using SCRIPT, this response not only outlines the actions taken but also emphasizes personal involvement and the tangible impact of those actions, offering a comprehensive and engaging narrative. For more information about SCRIPT, take a look at my blog post STAR is Not Enough: Tips For Behavioral Interview Questions.
Please note the following:
- Prepare 3-5 answers using the SCRIPT framework before the interview and write them down (in a text file, on paper, etc)
- Your answers should not be longer than 2 minutes
- Remember to use “I” instead of “we” in your answer, because the interviewer is interested in the actions that you took and not in what the team did
You can find lots of resources about these questions on the internet (also check YouTube), so I won’t go deeper into these questions. Here are some good links to start with:
- Grokking the Behavioral Interview by Educative.io (free)
- 7 Proven Job Interview Questions—and What to Look for in the Answers from the Hire Team (by Google)
- Common behavioral questions from the Tech Interview Guide
- How to Ace Your Behavioral Interview
- 45 Sample Behavior Questions to Use During Non-Technical Interview With Developers
- Behavioral Interviews for Software Engineers
- Amazon Interview: Behavioral Questions & Leadership Principles for Software Development (SDE) Roles

Mock interviews
After going through all the materials above and getting ready to start the interview process, it is always helpful to get some feedback in a low-stress environment. Mock interviews help you test your knowledge and get feedback from another person.
Here is how you can find interviewers for mock interviews:
- Pramp.com (free): This website connects you with other peers, who are also studying for interviews so that you can all learn together
- Exponent: This site has 3 options for mock interviews:
- Peer interviews (1 free, rest are paid): Every day at 6pm PST, you can be matched with another person doing Software Engineering interviews, so that you can practice together
- Top Software Engineering Interview questions (free): This is a list of the top Software Engineering interview questions that are asked by top companies. You can see how other peers answer these questions or you can answer them yourself and get feedback
- Mock interviews (paid): You can select mock interviews from a list of experienced Software Engineers in the top tech companies
- PractiseCodingInterview.com (paid), GainLo (paid), and interviewing.io (paid): These websites will match you with experienced interviewers, who are currently working in the top high-tech companies
- Use your network: You can talk to other developers that you know (either from your own company, via LinkedIn, etc) and ask them to do a mock interview for you

Salary negotiations after a job offer
Did you get a job offer and you want to maximize the compensation that you are being offered? If so, then you have 2 main ways:
- Ask for the help of a professional
- Levels.fyi negotiation services: Chat with former tech recruiters who’ll guide you on exactly what to say to get you a higher offer
- Do It Yourself (DIY)
- Levels.fyi: Find the salary band for your level in any tech company
- 71 Brilliant Salary Negotiation Email Samples by Lewis Lin (book): Learn how to negotiate your salary with easy-to-use email samples and phone scripts
Is this for people who are in software engineering already? would this plan work for a non-tech pm to TPM?
This is an interview preparation guide for those, who want to find a job as a Software Engineer.
The preparation guide for Product Management interviews is at https://engineerseekingfire.com/how-to-prepare-for-product-manager-interviews/
The preparation guide for Technical Program Manager interviews is at https://engineerseekingfire.com/how-to-prepare-for-technical-program-manager-interviews/
This is what’s wrong with out industry…
5 years from now: solve 2 hard problems in 30 minutes.
Thank you so much for this post. I found it very helpful and I have made a note of some points mentioned here.
I would like to know what was your typical daily schedule like? How did you distribute your time to cover this?
Amazingly compiled list. Thanks a lot man! 🙂
Correction: Python does support heaps. There is a standard package heapq.
There are no built-in binary trees in Python, though. But you can always say “imagine we have such library…”
Thanks, Kirill! I fixed the text above.
Thank you Fireman!!! I was so lucky to stumble on this today since I plan studying from the basics to get into big tech company despite being a junior in CS. Your guide is a perfect road map for my plan and I am going to follow your advice to achieve my goal!
Happy to help, Nghi! Good luck!
Thank you fireman. I am currently aiming for a SDE 2 position at Amazon and this post is very helpful to me. Just a question, in the system design round of a typical SDE 2 interview, how often do you run into a interviewer who goes past the things taught in grokking or system design primer and drills you on very domain/technology specific questions ?
Well, a typical interview is 45 minutes. In the beginning you will spend a few minutes for introductions and at the end you will spend a few minutes to ask questions to the interviewer. As a result you have 30-40 minutes for the actual interview. During that time you will have to answer the interviewer’s question. If that question is a Leetcode Hard problem, then that’s the only time that you get. Practice, practice, practice…
You need to solve a hard in 30-40 minutes, are you crazy. No one can do that unless you are John von Neumann. Some of the hard problems are based on PhD work that people spend 3-4 years to solve.