The Final Guide on Landing a Software Engineering Role at a FAANG Company

[Author’s Note: At nearly 5,000 words, you probably don’t want to try reading this on a mobile device. Bookmark it and come back later.]

I am a software engineer who has worked at Microsoft and Google. A while back, I went on a 120 - day long job search journey, aced more than 30 interviews, and landed multiple offers.

During my preparation and discussions with other candidates, I discovered that though there’s a lot of information about interviewing, some of the critical details are missing or hidden deep inside experience posts. Details like communicating your story, communicating your level through system design, or negotiating the offer when the time comes.

If any of you readers know me personally, I like to keep things organized, and I have kept a record of all the resources and steps that helped me get multiple offers from the big tech companies. This article will be a sum total of all the resources I used and the experiences I gained.

My goal is to create a blueprint and a roadmap that can be used by any candidate on their next job search.

Target Audience

• Experienced Software engineer
• Applying for an Individual Contributor role at big tech companies (i.e. Google, Meta, Microsoft, Apple, Amazon, etc.)
• Targeting mid to senior engineering level

Note: If you are interested in a similar post for junior developers, please drop it in the comments or DM me. If there are a lot of interested folks, I will consider making one for junior developers too.

Motivation

Most people I talk to hate the job search and interview process. The top reason I have heard is “the process is flawed, and I want to get it over with as soon as possible.”

I agree that the interview process is flawed, but we can use the flawed system to our advantage through systematic planning and consistent efforts.

Also, a clear motivation is that If you follow the blueprint described in the article, with the job change, you would be able:

• Level up your compensation. I have seen people increase their compensation from anywhere between 30% to 200% when they change jobs.
• Level up your career. By communicating your story and acing the system design interview, you would target Levels at or above your current job.
• Find a job that genuinely interests you.

Based on my observations of all my friends finding new jobs, I firmly believe that if you are doing good in your current role, you will get a new job that you would love. One of the reasons is that it is currently a candidate’s market, with every major tech company hiring.

Don’t believe me that you could get that higher pay? You could look at some analysis done by Matthew Dean in this article .

You will need a slightly higher time commitment to follow this blueprint, but it would be well worth investing time and effort.

Interview Process Overview

The interview process will look something like this:

Recruiter Call → Phone Screen → Onsite Interview (4-6 sessions) → Offer stage

Recruiter call

This is typically a 15-30 minute call with a recruiter to discuss your interest in the company. Before talking with any recruiters, you should already have clarity on your goals for your next job. (Which you have listed as a part of your story). This call aims to communicate those goals and your story and discuss a potential mutual fit.

Also, remember that once a recruiter schedules interviews for you, they will be your biggest ally and a friend throughout the process. Well, at least until negotiation begins. (I hope you realize that they have a vested interest in you succeeding in the interviews and signing an offer.) You should feel free to ask them for any help or resources you need. Most of the resources and links in this blog are provided by recruiters I worked with during my job search.

Post this call, you will move to the phone screens.

Phone screen

This interview is typically a 45 to 60-minute video call with a software engineer where you are expected to share your screen and code live on a text editor. You will likely work on a DS/Algo problem. And for most companies, this round is an elimination round as the intent is to decide whether the company should invite you onsite (on their campus) for interviews. Note: You should clarify with your recruiter what to expect.

Before doing these interviews, you should be thoroughly prepared for the Algorithm interviews. Your objective for this interview is to demonstrate your technical ability, ask insightful questions to your interviewer after the coding portion, and move forward to the onsite.

Onsite interviews

The onsite typically last between 4 to 6 rounds at the company campus itself, but the global pandemic has pushed this to be conducted virtually. This is an advantage for the candidate as now we can stagger and schedule rounds for the time that works well for us and not be forced to use our vacation days for every onsite.

You will face algorithm problem solving, system design, and behavioural and experience interviews. You should be excited to meet many people and enthusiastically demonstrate your technical skills. The objective for the onsite is to give strong positive signals and data points to move forward to the offer stage.

Offer stage

You’ve made it this far, woohoo! At this stage, all you need to do is to determine whether this is the right opportunity for you and to negotiate the package that makes you happy and excited to sign and join.

Weekly Schedule

I have taken the liberty to create a 15-week schedule assuming that you will consistently be preparing and interviewing part-time. You can shorten or elongate this schedule accounting for your situation.

Week 1 : Ramp up and process understanding

• Draft your story and polish your resume to signal the target level and scope
• Research Companies you might be interested to apply
• Understand the interview process and get a sense of comp ranges from levels.fyi
• Update “open to finding a new job”, with privacy level as recruiters only on LinkedIn.

Week 2-4: DS and Algorithm fundamentals

• Review the network, referral and recruiter connect section.
• Have a Todo list for algorithms preparation and knock something off the list daily.
• Strat solving 2 algorithm problems everyday.
• Talk to recruiters and strat scheduling phone screens for week 7 or 8.

Week 5-7: System Design fundamentals

• Have a Todo System Design preparation and knock something off the list daily.
• Continue solving 2 algorithm problems every day.
• Take the system design readiness checkpoint to see where you stand.

Week 8-9: Technical phone screens and Mock interviews

• Complete the phone screens for most companies
• Start Mock interviews at pramp.io for both System design and Algorithms.
• Keep studying system design based on feedback.
• Draft your STAR examples for behavioral rounds.
• Start scheduling onsite interviews.

Week 10 -13: Ace the Onsite

• Stay calm and focused, and best of luck
• Ask the recruiter for feedback one day after any onsite interview round.

Week 14-15: Offer Stage

• Review offer stage section on the blog.
• Once you sign, send me the notes on how the blueprint can be improved.

If you like to use checklist/todo lists, you can find the above schedule in a checklist format on this . (Feel free to make your own copy and check things off as you complete it.)

Start Here

My recommendation is to follow the weekly schedule by copying this google doc and ticking things off as you complete them.

Your story

Now that you have decided to start the job search process let’s talk about what you want your career to look like. I recommend drafting answers to the following questions, which we will term as your story:

• Why did you join your last company?
• What did you do at your last job?
• Why are you leaving? And why now?
• What are some things you would want to continue doing at your new job?
• What else are you looking for in your new job?

It may not look like it now, but many things in the following steps will depend on how you answer these questions. Here is an example of my story from when I started the job search. Identify and Shortlist companies. Based on your story and goals, come up with a list of 7-10 companies you want to interview with. You will find some companies that are more interesting than others. Sort the list into two buckets: backup and target companies. These buckets will come in handy while scheduling your onsite interviews.

Leveling and compensation

Get a sense of levels and compensation from levels.fyi. If you are unsure what level you should target, consider talking to your connections at that company before you apply to understand your target level.

A word on resume

Make sure you make a clean and polished resume. Ideally, most of the bullet points in your resume should follow the XYZ format.

“Accomplished [X] as measured by [Y], by doing [Z].”

Related resources:

Network and Linkedin

I believe most of my readers are already on Linkedin and have an . If not, the first thing you should do is create an all-star LinkedIn profile.

I emphasize so much on having a LinkedIn profile because, during my job search, I was contacted by over 35 recruiters on LinkedIn, which resulted in me starting the conversations with 6 companies.

While we are on this topic, I would recommend all of you to go and enable open opportunities with the privacy setting as only recruiters on your LinkedIn. You can find the steps . [Make sure the privacy is to set recruiters only and not public.]

The second reason to have a decent Linkedin profile is to build a network that supports you and may have connections that could refer you to the companies you are interested in. Referrals are the best way to get noticed and start the process. Followed closely by starting a conversation with the recruiters that reach out to you. Direct applications should be your last resort.

Tips for Recruiter conversation

This is usually the first conversation you have with the company. As already mentioned in the above section, your recruiter will be your ally and a friend throughout the process. Well, at least until negotiation begins. You should understand that not all recruiters are created equally, and some are better than others. But you should remember to always be cheerful, polite and classy.

Make your recruiter part of your team and work with them to get your desired package.

A recruiter may ask at this stage what your expected compensation is. I personally would recommend against giving any numbers this early. Instead, focus the discussion on determining mutual fit and levelling. It’s better to discuss numbers at the offer stage. If a recruiter keeps pushing, you can tell them a range at the top of your level* and make sure to emphasize that you know the company is competitive and you are sure that a mutual agreement can be reached.

*You can use to get an idea of what the salary ranges are for your level.

Also, look at the negotiation section in this article if more information is needed.

The interviewer’s Perspective

If you have ever been on the other side of the interview table or on a hiring committee, you would know that while making the decision, two words keep getting thrown around a lot, i.e. signal and data-point. If you haven’t, don’t worry, I am here to explain.

The interviewer’s job is to get as many signals and data points as possible. So, now you ask what these signals are? A signal is a piece of information that demonstrates your specific skills, knowledge, and experience.

For example, when I am interviewing, I would look for the following signals:

Coachability signal: This signal accounts for how well the candidate responded to hints and feedback, whether they were open to feedback, and whether they leveraged the feedback to improve their solution. This signal is typically analyzed during both problem solving and system design interviews.

Coding signal: This signal accounts for – how deeply does this candidate understand, and how effective are they at actually coding? This is analyzed during the Problem-solving interview.

System design: This signal accounts for – is this candidate experienced and capable of designing and leading a large technical system? This is analyzed during the systems design interview.

Collaboration and Management signal: This signal accounts for — is this candidate capable of either working with or managing a group of people. This signal also accounts for the candidate’s experience in collaborating with or managing large teams. This is analyzed during the behavioral/experience interview.

There are a few more signals that different companies look out for. For example, companies like Google and Amazon look for a signal that accounts for navigating through ambiguity.

Now, you know what the interviewers look for in an interview. Your job during each interview is to emit the signals that demonstrate you are fit for the role and showcase your seniority.

Data structures, Algorithms and Problem solving Interview Preparation

Tech interviews are hard. Imagine being assessed to implement optimal solutions while communicating your thoughts within a nerve-wracking 45 minutes interview.

The good part is you can get better at them with preparation and practice. The preparation includes:

• Understanding the interview expectation.
• Grasping DS and algorithms fundamentals.
• Learning to stick to a structured approach to communicate well.

Problem solving Interview Expectation

Programming Languages: Most companies do not require that you know any specific programming language before interviewing for a technical position, but familiarity with a significant language is generally a prerequisite for success. Not only should you be familiar with the syntax of a language, but you should also be familiar with some of the languages’ nuances, such as how memory management works, the most commonly used collections or libraries, etc.

Data Structures: You’ll be expected to understand the inner workings of common data structures and be able to compare and contrast their usage in various applications. You will be expected to know the runtimes for common operations and memory use.

Algorithms: Your interview will not focus on rote memorization; however, understanding the most common algorithms will likely make solving some of the questions we ask a lot easier. Knowing the runtimes, theoretical limitations, and basic implementation strategies of different classes of algorithms is more important than memorizing the specific details of any given algorithm.

Coding: Expect to be asked to write syntactically correct code—no pseudo code. A few missed commas or typos here, and there aren’t that big of a deal, but the goal is to write code that’s as close to production-ready as possible. This is your chance to show off your coding ability.

Related resources:

• (24 min)
• (2 min)
• (7 min)

Data structure and Algorithm fundamentals

My recommendations

My recommendation is to first understand the interview framework, then understand the foundations and concepts, and finally deep dive into algorithms. Here is the recommended plan:

• The first step is to understand the problem-solving framework. (CTCI) is the best resource for this. Read chapters 1 to 7. These chapters thoroughly break down the framework for solving the algorithm interview. Internalize these chapters and apply this methodology when solving any algorithm question in an interview.
• Review foundations by reading the following chapters in either CTCI or EPI. Here are some of the topics from the top of my mind: Strings, Arrays, Linked Lists, Stacks, Queues, Heaps, Trees, Hash Tables and Maps, Searching and Sorting, Recursion, Dynamic Programming, Greedy Algorithms, Graphs and graph traversals.
• Deep dive into algorithms:
  • If you have to start fresh or haven’t reviewed Algorithms in a while :
    • - Follow the lectures and code the algorithm, ds in a word doc after every lecture. [I recommend watching at 2x]
    • - This is optional as only a couple of companies (like Google and Directi) expect advanced algorithm concepts.
  • If you had studied DS and Algorithms recently and are only reviewing the concepts, then review the top few articles for each DS and algorithm on geeks for geeks.

Other resources for DS, Algo and coding fundamentals

• (not very efficient)
• Google Style Guides for: , ,

Coding practice

When you practice, do not use an IDE. You need to be able to write legible, compilable code without help regarding the layout or spelling of standard library class/method names. I suggest solving algorithmic/DS problems on a word document or on paper to simulate an actual interview.

Note: Some companies may have an integrated IDE in the browser window, but most don’t, so it is safer to practice on a standard word document.

My recommendations

If you are new to DS and Algorithm coding, follow the

Otherwise, you can just solve . This list of problems covers various topics to get you ready for any coding interview.

Also, I like to solve a random coding problem daily other than my preparation and practice, and

to achieve this, I subscribed to //www.dailycodingproblem.com/

Other resources for additional practice:

System Design Interview Preparation

Your system design interviewer will likely be a senior engineer who’s going to ask you an open-ended question like “Implement a flight booking system” or “Create a feed for Instagram”.

Your goal will be to drive the conversation for the next 60 minutes, solidify the problem requirements, and design a system that solves it. This is a chance to demonstrate your skills, knowledge, and experience in technical leadership.

System Design Interview Mindset

After tons of conversations with people preparing for this interview, I have realized that most people come in with the mindset that this is an exercise building hypothetical systems. I can see this when candidates say things like they “would not do in real life.” and may end up ignoring some of the more significant technical problems they see, thinking this is, after all, just an exercise. But, this emits a wrong signal to the interviewer, who might believe you didn’t see that technical problem. (Just as shown in the meme above.)

You need to change this mindset; instead of building hypothetical systems, let’s build a real system. Imagine driving an actual work meeting at the start of an interview. The meeting aims to solve the given problem by brainstorming the design and roadmap.

At the end of this 1-hour interview, your goal is to have a design roadmap and plan divided as tasks between a team. (This is the Northstar goal, but just the technical design with trade-off might be enough for most interviews.)

Making this small change in mindset will change how you approach this interview. Instead of participating in just a hypothetical discussion, you will lead the discussion and develop a much more realistic design.

High-Level Design

HLD interview framework

I personally follow a framework of dividing this interview into 3 phases.

• Requirements gathering
• Technical Design and trade-offs
• Deep Dive and more possible improvements

It is better explained in .

HLD knowledge expectation

Databases

The more you know about how relational and non-relational databases work and what trade-offs exist between them, you will be better prepared. However, most companies don’t assume any particular level of expertise.

Distributed Computing and scaling

While most companies have internal tools that help with scaling, it’s essential to understand a few basic distributed computing concepts. Understanding topics such as service-oriented architectures, map-reduce, distributed caching, load balancing, etc., could help you develop a better design for some of the more complicated distributed architecture questions you might encounter.

Internet and Networking Topics

Most companies expect our engineers to be familiar with the basics of how the internet works. You might want to brush up on how browsers work at a high level, from DNS lookups and TCP/IP to socket connections. They aren’t looking for network engineer qualifications, but a solid understanding of the fundamentals of how the web works is a requirement.

Recommended learning

Try solving the questions in and then go through their provided solutions. This resource is a really great way to learn and internalize how to drive excellent system design discussions.

The is also a great resource if you need more learning.

HLD Mock interview readiness Checkpoint

Try answering all the following questions before moving on to prepping and starting mock interviews:

• When would you choose a SQL DB over No SQL?
• What are different types of data stores to store an image? What are the key things you would look for while selecting your image data store?
• Long polling vs web-sockets.
• What is an excellent technique to speed up repeated read calls?
• Disadvantages of Caching.
• What is a CDN? When should you use a CDN?
• What is the CAP theorem?
• What is the relative performance for HDD, SSD, RAM, and network calls.
• What are availability and reliability? How would you measure them for a system?
• What happens behind the scenes when you open a link in your browser? Do you know what these terms mean: TCP/IP, DNS lookup?

Other resources:

Low-Level Design

Note: Not all companies have this round, so check if the companies you are interested in ask these questions. I was faced with an LLD question in Google and Amazon.

You should have a working knowledge of a few common and useful design patterns and know how to write software in an object-oriented way, with appropriate use of inheritance and aggregation. You probably won’t be asked to describe the details of how specific design patterns work but expect to have to defend your design choices.

Resources:

LLD Mock interview readiness Checkpoint

• What is concurrency? Do you understand cohesion and consistency?
• Do you know how to use at least the following design patterns:
  • Strategy pattern
  • Observer pattern
  • Factory method
  • Singleton pattern
• Inheritance vs aggregation

Mock Interviews

Mock interviews are the best way to get into the rhythm of interviewing. I recommend doing a few mock coding and system design interviews every week you prepare. This will make sure you know how you are tracking and the areas of improvement. You can use the following sites for Mock interviews:

• - free mock interviews for Problem-solving and HLD system design
• - paid

General Interview tips

By now, you should have already gathered all the tips I am planning to share by going through and . These are some critical things if you didn’t have sufficient time to go through them:

• Talk through your thought process about the questions you are asked. In all of the interviews, interviewers evaluate your technical abilities and how you approach problems, and how you try to solve them.
• Ask clarifying questions if you do not understand the problem or need more information. Many interview questions are deliberately underspecified because interviewers are looking to see how you engage the problem. In particular, they are looking to see which areas leap to your mind as the most critical piece of the technological puzzle you’ve presented.
• Think about ways to improve the solution you’ll present. In many cases, the first answer that springs to mind isn’t the most elegant solution and may need some refining. It’s definitely worthwhile to talk about your initial thoughts to a question, but jumping immediately into presenting a brute force solution will be received less well than taking time to compose a more efficient solution.
• You should have a few questions prepared for the interviewer. It goes a long way when you’ve taken the initiative to research the company before your interview.

Other resources: (30 min)

Behavioral and experience interview

Most people I know don’t prepare much for this interview. They feel like the questions are random, and I understand that it’s challenging to make it a priority with all your other todos. But I believe that this interview can make or break the decision to hire you.

The interviewer wants to understand two things:

• Are you a culture fit?
• What is the right level for you?

I recommend preparing 5-6 strong work examples and stories that share data points with strong positive signals. This will ensure you can answer the interview question while maintaining an excellent flow of information. These work examples need not be fancy or complex. What matters most is that the example is well received and understood by the interviewer. Plus, well-prepped stories are compelling, and the interviewer can see how you feel and can resonate with them. Also, stories are a great way to illustrate your experience, which is crucial in deciding the level.

Here is a sample question where you can demonstrate your experience applying customer obsession: Discuss a time when you went above and beyond for a customer?

There are multiple ways to answer the above question; I recommend following the STAR method while answering any Leadership principle-related questions. STAR stands for “Situation - Task - Action - Results” read more on .

Once these examples are well-prepped, try answering the behavioral questions for practice.

Tip: this is the list of all questions I had prepped for, and I absolutely rocked every behavioral and experience interview.

Resources: My blog post -

Offer Stage

Commendable job on making this far! Once you have got the offers, you can interview the team and the company. You may want to meet the managers and teammates multiple times before making any decision.

A data point to make this clearer: I met 7 different managers at Google before making my team decision. After meeting them, I had follow-up meetings/chats with the ones that had me interested. So, this was basically a reverse interview. There is an upside if your manager really wants you; the recruiter has an ally for getting you a more suitable offer now.

Note: At some companies like Amazon, you will get to meet only the team/hiring manager for the role you applied to. This is because hiring is mostly driven by the team and not a company-wide level for these companies.

One thing you should do before meeting the Hiring managers is to list down around 7-10 questions that you would want to ask if time permits. These questions can range from general to very team-specific or technology-specific questions. These questions should be designed to gather more information about the team, technology, and manager to make an informed team decision.

Negotiating the best offer

An hour or two of research on negotiating could net you an additional 10-30% pay bump. I would say definitely worth your time!

There is a lot I want to say about negotiating, but I feel it would be best for you to follow the same articles I used to get started and hear it from the horse’s mouth:

Once you have read through the above articles, here are a couple of points I want to re-emphasize:

• Know your worth and target level (use levels.fyi)
• It is better to negotiate over an email than over a call.
• Best negotiators are the ones who are ready to walk away

Other great(but long) resource:

After you sign the Offer

• Party, party and party hard! You have earned it.
• Send a note to everyone involved (Maybe even stay connected on LinkedIn)
• Let other companies know that you have decided to go another way.
• Drop me a message with any feedback/improvements on this blueprint.

Parting Advice

• Talk to your recruiter. They can help you with unique insights and resources to succeed in the interviews.
• Be kind to yourself. The interview process is stressful, and it is easy to blame yourself when things go sideways. Remember that this is not the end. There are many more companies and be kind to yourself.
• Always be positive and classy.
• Be curious to learn and ask questions.

An aggregated list of Recommended Resources

• (CTCI)
• - free mock interviews

First published