The Ultimate Software Engineering Job Search Guide

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. This includes details like communicating your story, communicating your level through system design, or negotiating the offer when the time comes.

I have kept a record of all the resources and steps that helped me receive offers from 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 in 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 others finding new jobs, I firmly believe that if you are doing well 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. 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. 

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. 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 lasts 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 behavioral 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

Below is a 15-week schedule based on the assumption 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 with which you might be interested to apply.
• Understand the interview process and get a sense of comp ranges.
• Update status to “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 to-do list for algorithms preparation and knock something off the list daily.
• Start solving 2 algorithm problems every day.
• Talk to recruiters and start scheduling phone screens for week 7 or 8.

Week 5-7: System Design Fundamentals

• Have a to-do 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 the offer stage section on the blog.
• Once you sign, send me the notes on how this blueprint can be improved.

If you like to use checklist/to-do lists, you can find the above schedule in a checklist format on this Google doc. 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 the 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. Identify and shortlist companies. Based on your story and goals, come up with a list of 7-10 companies with whom you want to interview. 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].”

Network and LinkedIn

I believe most of my readers are already on LinkedIn and may have an all-star LinkedIn profile. If not, the first thing you should do is create an all-star LinkedIn profile. I emphasize so much having a LinkedIn profile because, during my job search, I was contacted by over 35 recruiters on LinkedIn, which resulted in me starting 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 here. [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, or at least until negotiation begins. You should understand that not all recruiters are created equally, and some are better than others. 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 leveling. 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.

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: signal and data-point. 

The interviewer’s job is to get as many signals and data points as possible. So, now you ask: "What are these signals?" 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 this candidate understands, and how effective they are at actually coding. This is analyzed during the problem-solving interview.

System Design 

This signal accounts for questions such as: "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 questions such as: "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.

Data Structure and Algorithm Fundamentals

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. Cracking the Code Interview (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 :
    • Coursera - Algorithms, Part 1: Follow the lectures and code the algorithm, DS in a word doc after every lecture. [I recommend watching at 2x].
    • Coursera - Algorithms, Part 2: 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.
    • Geeks for Geeks - Data Structures
    • Geeks for Geeks - Algorithms

Other resources for DS, algo, and coding fundamentals:

• bigocheatsheet
• Book: Beautiful code
• Book: Elements of Programing Interview
• Coding Interview University
• Course: Udacity - Intro to Algorithms
• MIT Open courseware - Introduction to Algorithms 
• Google Style Guides for C++, Python, Java

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.

Recommendations

If you are new to DS and Algorithm coding, follow the interview bit programming course.

Otherwise, you can just solve the blind list: 75 practice questions on Leetcode. 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.

Other resources for additional practice:

• Codeforces
• HackerRank
• Topcoder
• Google Code Jam

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 conversations with people preparing for this interview, I have realized that most people come in with the mindset that this is an exercise in 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. However, this emits a wrong signal to the interviewer, who might believe you didn’t see that technical problem. 

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 this step-by-step guide.

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 their 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 Grokking the system design interview 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 course Hired in Tech - System Design 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: High scalability - examples

Low-Level Design

Note: Not all companies have this round, so check if the companies you are interested in asking these questions. I was faced with an LLD question by 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:

• Refactoring Guru - Design patterns
• Book: Head First Object-Oriented Analysis and Design

LLD Mock Interview Readiness Checkpoint

• What is concurrency? Do you understand cohesion and consistency?
• 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:

• Pramp: Free mock interviews for problem-solving and HLD system design

General Interview Tips

By now, you should have already gathered all the tips I am planning to share by going through CTCI and Grokking system design. 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, 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 not be received as well as 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.

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 to-dos. However, 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 the STAR method).

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

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

Resource: Ace the Amazon Leadership Principle interview questions

Offer Stage

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

Here is 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. This was basically a reverse interview. There is an upside if your manager really wants you, and 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 at 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 it is 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:

• Ten Rules for Negotiating a Job Offer
• How Not to Bomb Your Offer Negotiation

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.
• The best negotiators are the ones who are ready to walk away.

Another great (but lengthy) resource: Salary Negotiation

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.