Acing the Software Engineer Interview

From zero to hero in 4 months to land 8 offers

The offers I received set to a blueprint background: Google, Robinhood, Airbnb, Uber, Tiktok, Microsoft, Scale, and Cloudflare.

Introduction

The internet has infinite resources for how to study for the software engineer interview. However, it’s hard to navigate these resources without a clear direction. If you make a plan, will it work? Could you focus on the wrong things and bomb your interview? Are you even good enough for this company?

I struggled with these questions when I started preparing.

In this post, I’ll show you my process. We’ll cover how I studied, interviewed, and earned 8 offers in under four months. This post is part of a 4-post series. You can find the first post here.

We’ll define the interview format & tools, guardrails (not rules) I followed, my study plan, a sample routine, and my tips for before and during interviews. My goal in sharing this information is to provide an approach that works!

Interview Format & Tools

Photo by Todd Quackenbush on Unsplash

It’s important to understand some terms.

The interview process is tiered: you’ll move to the next round if you pass the previous one.

The steps are:

1. Recruiter call: discuss the role and the interview process.
2. Coding challenge / Phone screen: an initial interview to determine if you have the necessary skills to pass the onsite.
3. Onsite: a series of 4–5 interviews usually an hour each. The feedback from these interviews are used in the hiring decision.
4. Offer / Rejection: a call or email to let you know you’ve passed (they’ll extend an offer) or failed (try again in a few months).

Each interview has a consistent pattern:

1. Introductions (5 minutes): the interviewer introduces themselves and you introduce yourself.
2. Behavioral / Coding / System Design (30–50 minutes) questions: see below for details on what each round tests.
3. Opt. Q&A (5 minutes): you can ask questions about their role, company, and more.

There are roughly three types of interview rounds:

• Behavioral: describe your professional experiences to answer a question. For example: “Tell me about a time when you struggled with a deadline.”
• Technical / Coding: solve a technical coding question maybe involving data structures, algorithms, debugging, or more. For example: “Given an array of integers and an integer target, return indices of two numbers so they add up to the target.”
• System Design: solve a technical coding question maybe involving data structures, algorithms, debugging, or more. For example: “Given an array of integers and an integer target, return indices of two numbers so they add up to the target.”

The interview process is intentionally designed to test for certain characteristics and experience the company feels are important factors to make a hiring decision. Every company has their nuances and quirks, but the overall process is similar.

It’s also useful to understand some tools we can use to improve our odds of success.

The tools:

• PAID: Leetcode Premium (highly recommended): Leetcode is an online platform to practice coding questions. I recommend purchasing their paid service, Leetcode Premium, because it fixes the difficult problem of deciding what to study. Using the question frequency meter & company-specific question banks, you can raise your odds of seeing a coding question in an interview.
• Blind: Blind is an anonymous workplace chat application. You can discuss a range of topics including compensation and interviews. With Blind, you can get a better sense of interviews by speaking with people who have recently undergone the same interviews. For example, if company X has a debugging interview, you can learn more about how to prepare from someone who has done the interview.
• YouTube: YouTube is an online platform where you can watch videos. For interview prep, it’s a great resource for understanding system design questions. I couldn’t read academic, dry books or articles on system design. Youtube was engaging and I could speed up videos to save time.
• Google docs (highly recommended): Google docs is an online word processor. I recommend using a barebones word document editor like Google docs to practice during mock interviews because you don’t have the help of code autocompletion, syntax highlighting, and debuggers. With google docs, the actual interview feels easier because you’ll probably get an online coding editor with those features.

An example of using Google Docs to practice during mock interviews

With the fundamental building blocks of the interview process as well as the tools covered, let’s dig into the rules — cough, cough guardrails — I followed to land my offers.

Rules vs Guardrails

Photo by Hogarth de la Plante on Unsplash

Before I started interviewing, I reflected on what types of studying worked well for me. I made four conclusions, and I believe these are helpful to anyone:

1. 🏓 Deliberate practice
2. 🪞 Mirror the interview environment as closely as possible
3. 📝 Study the “test” as closely as possible
4. 😱 Reduce surprises / be comfortable

These laid the foundation for every step in my study plan. They provided structure and kept me roughly aligned with my destination, like guardrails do.

It’s worth mentioning I read Elements of Programming Interviews initially but quickly became disheartened by the difficult questions. This led me to cycles of dropping interview prep for a week or so, binging a Netflix series while I soaked in self-pity, getting my motivation back up, tackling the book with newfound earnestness and energy, and then rinsing and repeating like a washing machine.

Eventually, I changed gears and then actually decided to think about what types of studying worked well for me. Let’s cover these principles in detail so you can avoid those motivational ruts leading to you binging all five seasons of Rick and Morty — I don’t judge if you do.

Guardrail #1: Deliberate Practice

Deliberate practice (in the context of interviewing) means studying and practicing components of the interview, gauging your strengths in each, and optimizing your study time by prioritizing weak areas.

It was my solution to the problem of interview prep taking too long and unnecessarily grinding Leetcode.

Here are a list of components for a technical interview:

1. Introducing myself
2. Understanding a given problem prompt
3. Identifying a solution
4. Explaining your approach
5. Coding a solution
6. Pacing yourself to finish within the given time
7. Testing it
8. Debugging your code if it doesn’t work
9. Optimizing your solution

You can probably break it down even further. In my experience, most people tend to struggle with steps 2–5, so I practiced those.

When you’re starting for the first time, you’ll likely be bad at all of these. That’s expected! You can’t reasonably improve if you don’t know your baseline performance. And your baseline performance will probably be bad. After your first few mock interviews, you’ll have a decent idea of the parts you’re struggling with. Write these down and focus on them during your next mock interview.

Guardrail #2: Mirror the environment as closely as possible

For deliberate practice to work effectively, you’ll need the best environment possible. The best environment is the one most similar to the actual interview: timed, mock interviews with a friend or colleague using random, medium-difficulty coding questions.

Mock interviews are emulated interviews where you go through the motions of an actual interview except with a friend or colleague. So, you introduce yourselves (I know, it’s weird), the mock interviewer shares a google doc with you, and you start asking questions & explaining what you’ll do. At the end, you’ll ask some brief questions about their company and wrap up! Afterwards, ask your friend or colleague to give you some pointers & feedback on what you did well and what you didn’t do so well. Ideally, follow a grading rubric you both agree on beforehand so you can more concretely measure your performance between mock interview sessions.

The idea is to use mock interviews as a barometer of actual interview performance.

By mirroring the interview environment using mock interviews, you:

• Familiarize yourself with the stress and strain of an actual interview. The anxiety you feel when you struggle to figure out a question? You’ll feel the same in the actual interview. Poorly communicating your approach so it comes out as a garbled mess? That too. Mock interviews give us the space to feel those emotions and learn to manage them. And by processing them and learning how to effectively control them, you’ll stay cool, calm, and composed under the pressure of the actual interview.
• Increase your speed. I allocated about 30 minutes for the technical coding question itself. Most times, you’ll be given 40 minutes to solve the question in an actual interview, so by practicing under a tighter time constraint, you’ll speed through the actual interview. If you’re just starting out, I recommend you budget 40 minutes and gradually reduce to 30.
• Get feedback. Usually, your friend/colleague and you do mock interviews for each other, meaning you’ll have both the experience as the interviewer and the interviewee. Experiencing both is important since you’ll understand what the other is looking for and where it’s common to get stuck. And after, you can get feedback from your mock interviewer.

Guardrail #3: Study the “test” as closely as possible

Deliberate practice and mock interviews work best when we use the best ingredients to facilitate excellent practice sessions. A key ingredient you’ll need is to practice real, Google / Uber / Facebook / etc. — level questions to acclimate to the difficulty of these interviews.

By practicing with big N company-level questions, we’re studying the “test” because if we had an interview with any of these companies, we can reasonably expect a coding question from them to be like the ones we practiced.

Finally, when studying the “test”, ensure you focus on learning from each interview and identify what went wrong and well. This helps round out deliberate practice by learning from our mistakes.

Guardrail #4: Reduce surprises and/or be comfortable

At the end of the day, this entire process is all about maximizing your chances to land a job offer by passing the technical interviews. There’s plenty of people who are very technically adept but were rejected nonetheless.

When I started studying for technical interviews in the past, I focused on achieving a certain number of Leetcode problems. It could be 200 or 300 — and even those are rookie numbers compared to some — but I’d still get rejected.

This time around, I focused less on the actual number of leetcode and hours, and more about my comfort level. There were weeks I did 3 leetcode questions and others when I did 15. I considered both cases a success because I felt comfortable with my level and depth of practice during those weeks.

I believe comfort should be your North Star: I believe this so much I avoided doing phone screens or mock interviews the day or two before my actual interviews simply because I didn’t want to torpedo my confidence.

An aspect of feeling more comfortable for me was reducing surprises. So, in the context of the interview, this meant nailing your introduction, conveying your behavioral stories, and asking follow up questions. I effectively removed these parts from the list of interview components mentioned earlier by practicing to the point where I felt reasonably comfortable I could perform well automatically in an actual interview.

Stack every advantage in your favor.

With the guardrails to guide you to a successful study session covered, let’s cover my study plan.

Study Plan

Photo by freddie marriage on Unsplash

In this section, we’re going to cover my study plan. Then, we’ll cover each topic area — nailing your introduction, behavioral, coding, and system design — piece by piece for best practices, specific tips, and a basic first step you can take to make progress.

After we’ve laid out a basic routine, we’ll discuss how to implement this study plan in the context of the actual interview process. So, this includes mock interviews (before doing phone screens & onsites), before the interview, and then during the interview.

Introduction

Your introduction is a small part of the interview, but an important one to set the tone for the rest of the interview. At a high-level, a good introduction contains:

• A greeting for the interviewer
• Telling them your name (so they know how to pronounce it)
• A brief summary of your experience (the most important part)

The general formula I use for my introduction is:

“Hey, my name is [name]. I currently work as a [role] at [name of company] working on the [team]. I joined [number of years since you started] and in that time have worked on [interesting project 1] and [interesting project 2]”

Here’s an a concrete example:

“Hey, my name is Ken. I currently work as a software engineer at Google working on the AdSense team. I joined approximately 2 years ago and in that time, I’ve had the opportunity to work on a lot of interesting projects like pagination of ads and web performance of ads.”

The most important thing to remember for an introduction is to practice until it’s smooth and rehearsed to the point it’s automatic. You don’t want this part taking too much time and nailing this gives you the confidence to do well on whatever comes next.

Here’s a good first step: write down a brief introduction following the formula above. Practice it out loud three times. Make sure to rehearse these during mock interviews too!

With your introduction down, let’s cover how to answer behavioral questions.

Behavioral Questions

Behavioral questions are questions interviewers ask you about your professional experiences. However, they’re not typically used to assess your technical ability, but rather to understand if you have certain traits, experiences, and skills the company values.

Behavioral questions are often constructed from a set of company values. For example, Amazon has 16 leadership principles which form their behavioral questions. Airbnb has 4 core values which interviewers look for in candidates. Uber has 8 cultural norms considered important to the company culture. The list goes on.

The general formula for any behavioral question is:

“Tell me about a time you did [company value].”

For example, a question assessing Amazon’s Bias for Action leadership principle is: “Tell me about a time when you worked against tight deadlines and didn’t have time to consider all the options before making a decision”.

By asking questions like these, the company is prompting you to give a story where you demonstrate the value. If you demonstrate it well, that’s a good sign to the company! If you don’t — or worse, do the exact opposite of the value — it may be a red flag to the company.

While this sounds daunting — there’s tons of companies and each has their own values- the real trick behind doing well on behavioral questions is to write down a few of your answers ahead of time and repeatedly practice these until it becomes second nature to you. These are called Behavioral Stories.

Behavioral Stories

A behavioral story is a written script of what you say for a behavioral question. By writing stories ahead of time, you can practice until it becomes smooth.

To write a good story, keep it short (max 250 words) and write your stories in the Problem — Action — Result format (P.A.R.).

By keeping it short, it’s easier to memorize it.

While you can follow any format, the P.A.R. format is a way of writing behavioral stories in a structured format. You briefly describe the problem, the action(s) you took to fix the problem, and the results of your actions. It keeps your story on track. Also, your interviewer takes notes on your responses and a common format to write these notes in is the S.T.A.R (Situation — Task — Action — Result) or P.A.R. format. It’s easier for them to write down the details if you use a similar format in your stories.

Finally, before I write a story, I write a brief set of qualities I’d like the story to demonstrate. These are generally universal qualities and experiences like proactivity, mentoring junior engineers, working across teams, etc.. These inform my writing and generalize my answers for a wide variety of behavioral questions. When answering a behavioral question, you can tweak your story slightly to emphasize one quality over the other.

Here’s the format:

[Story name]

Qualities: [write the qualities you want to emphasize]

Problem: [briefly describe the context and the problem]

Action: [describe the actions YOU took and make sure they contribute to the solution of the problem]

Result: [what was the result of you taking the action above and has it solved or reduced the problem?]

Here’s a short example:

Server-side Pagination

Qualities: tackling a difficult problem, getting consensus from different teams, being curious

Problem: my org required a pagination API for our platform and there wasn’t consensus between different teams on the API format.

Action: I gathered all the design docs on pagination within my org, streamlined the API to use common, industry-standard parameters like a next token and limits, and wrote a new doc to explain the API.

Result: after circulating the API between different teams and giving them example implementations, the new pagination API has largely become the standard within my org (and removed a variety of single-use cases) and has improved developer velocity by 10%.

When you answer a behavioral question, you can mentally leaf through your 3–4 stories and choose the one best fit for the question. I recommend you memorize 3–5 stories with as distinct a set of qualities and experiences as possible so you can answer a wide variety of behavioral questions.

To take a first step: in a bullet-point fashion, list 3 or so experiences at a high-level. So, an example bullet point could be: Server-side Pagination @ Amazon on the platform team.

Then, for one, expand on the point by writing out a 50-word description of the problem, 50-word description of the action you took to fix the problem, and a 50-word description of the result. Repeat this for all stories.

With behavioral stories nailed down, let’s move on to coding.

Coding Interviews — Fundamentals

There’s two distinct parts to preparing for coding interviews: learning the fundamentals (data structures, algorithms, etc.) and practicing Leetcode.

To learn the material, I leveraged my ability to watch tons of videos — thank you Netflix — without too much stress and watched BaseCS on Youtube. Here’s their medium articles and youtube videos. Highly highly recommend these articles and videos. While I was covering a particular topic, I tackled related questions on Leetcode.

While I was studying a particular data structure or algorithm, I also kept in mind how often it could turn up in an actual interview. Here’s a list of the topics I studied:

1. Arrays (very common): there’s a lot of ways to make array problems difficult including: the two-pointer technique, sliding window, and matrices. String-based problems are similar to arrays.
2. Linked Lists (very rare): I got all of 1 question in my 50+ interviews. If you do get one, most problems tend to focus on managing pointers or detecting cycles.
3. Stacks (common): usually used as a supporting data structure to solve a problem. Stack questions are a popular way to spice up a problem from your vanilla array questions. They’re especially useful for parsing and maintaining order to data.
4. Queues (rare): queues are used in other algorithms like BFS. I don’t recall seeing an interview question where queues were the spotlight but it’s useful to know them.
5. Trees (very common): trees are non-linear data structures and have a ton of use cases. The most common problems I received focused on two types of trees: Binary Trees & Binary Search Trees.
6. Tree Traversal Algorithms (very common): the ones you’ll want to focus on are in-order, pre-order, post-order, and level-order. For advanced interview questions, I got a lot of level-order traversal questions.
7. Trie (rare): I received 2 difficult trie questions during my interviews and they usually comprised something related to efficiently storing and parsing a string’s prefixes.
8. Heaps & Priority Queues (rare): heaps manifest themselves within Priority Queue related questions and those tend to be used in graph-related problems (Dijkstras for example). Take the time to learn how to implement a priority queue or use the library version.
9. Hash Tables (very common): hash tables can be the main focus of a question or a key way to optimize a solution. In my interviews, I always considered using a hash table. Sets & dictionaries are your bread and butter to optimize a slow-running solution.
10. Binary Search (common): this honestly tends to be a pain to remember and while the algorithm is easy to understand, the implementation and usage in problems are a world of pain. I received 5 binary search questions and did well on about 3 of them. In the future, I’d probably spend more time studying this.
11. Sorting algorithms (rare): typically, I used the library sort function when required. However, in the cases where sorting is the problem, learning mergesort and quicksort are the two most important ones.
12. Graphs (common): like trees, graphs are non-linear data structures used as a second go-to interview question when interviewers want to turn up the heat in difficulty. Examples include: traveling from node to node, exhaustively covering the graph, cloning the graph, or managing pointers (in the case of directional graphs).
13. Graph Traversal Algorithms (very common): learn three algorithms: DFS, BFS, and Dijkstras. A very rare and difficult type of interview question is topological sort. Also, I didn’t study any “name” algorithm like Kruskals, Prim, Bellman-Ford, etc.. with the exception of Dijkstras.
14. Recursion (common): recursion questions are used to test how you organize and re-use code. I often found there was an elegant solution to a problem using recursion.
15. Back-tracking (common): a slight twist from recursion based problems reserved for more difficult algorithm questions.
16. Greedy algorithms (rare): I don’t believe I encountered any overtly greedy problems and thankfully I didn’t spend too much time covering the topic. I recommend spending a day refreshing your understanding of greedy problems.
17. Dynamic Programming (very rare): I only got two (one from Google & Microsoft). I have no idea how to do these questions well and they’re essentially my kryptonite. I’d still take some time to familiarize yourself with some of the concepts — like tabulation & memoization — as they’ll be useful to you even if you don’t fully understand Dynamic Programming.

This is not exhaustive, but it gives you 80%+ of the results you want for the least amount of effort.

I omitted a few topics. These are use-case specific topics you can cover if you know they’ll show up.

• Binary related questions (masks, shifting, using the different operators like XOR). I omitted these because they tend to only really show up for embedded systems or lower-level systems like hardware engineering.
• Object-oriented design questions (inheritance, encapsulation, SOLID principles, etc.). I code functionally so these weren’t really my style. However, I received a single OOP-design question from Snap and although I nailed the other 3 interviews, I bombed this one magnificently and as a result didn’t receive an offer.
• Parallel programming / concurrency / operating systems / databases / etc. — similar to binary, these are job-specific and not something I’d like to work with on a daily basis.
• Frontend (JavaScript, CSS, HTML, React, etc.) — I interviewed as a full-stack engineer, but I have absolutely no idea how to interview for frontend. Unfortunately, these types of questions showed up for Robinhood and Uber, and I mucked my way through them by relying on pre-existing knowledge. I should have studied this more.

As a first step: using the topics above, just watch the baseCS videos on YouTube and take some brief notes. You’ll prime your brain to recognize some of these. You can also do a few Leetcode questions on these topics as you cover them.

Also, create a schedule for yourself to cover these. For example, you’ll learn about Arrays for a week and do Array leetcode problems. Then you’ll study Linked Lists for two days and do Linked List leetcode problems. I’d follow the list from above in order and spend a proportional amount of time to cover subjects based on rarity. You can also follow the routine discussed later in this article.

After a basic coverage of the data structures & algorithms, you should feel reasonably confident you can discern what a coding question is asking and the inklings of a solution using data structures or algorithms.

It’s time to learn how to deal with Leetcode.

Coding Interviews — Leetcode

Leetcode is tough to grind. If done properly, you can be confident you’re grinding the minimum number of questions you need and come away with a huge amount of knowledge by understanding the kernel of the approach to a problem. Most problems are variations of a few patterns.

My overall strategy was to first study high-frequency Leetcode questions. My goal was to maximize my odds of seeing a similar question in an actual interview. Additionally, I mostly focused on medium-difficulty questions. They represented the bulk of my questions (65%) while the remainder came from hard (25%) and easy (10%) difficulties.

While you’re studying a topic, cover questions using the data structure or algorithm. You can filter by topic and also sort by frequency to get the best set of problems to review while covering the topic. After you’ve covered all the data structures and algorithms, start looking at all the high-frequency questions in general (regardless of topic). Lastly, as soon as you’ve scheduled an interview, start reviewing the company’s question bank and sort by frequency and within the last 6 months. If you finish the 6 month list, go on to a year.

And that’s basically how I studied Leetcode — studying high-frequency, medium-difficulty questions in a tiered approach to maximize my odds of seeing a question or a similar one.

While you’re doing a problem, if you can’t figure it out, make sure you stop after 15–30 minutes. Cut your losses as soon as possible so you don’t waste time staring at a blank screen. Read the top-voted answer on the problem’s discussion tab, and rewrite the solution from scratch so you understand how it works. In my experience, half of the difficulty in solving a problem is in identifying a working approach. Working backwards from a clear & clean solution by rewriting it makes it easier to absorb the solution instead of trying to both problem-solve and then code for a solution.

Often, you’ll bounce back and forth between watching BaseCS videos, giving up, practicing LeetCode, giving up, and repeating….. That’s natural. Just focus on consistency — do one question a day at minimum. More if you can. Be mindful of your energy and your off-days. Take plenty of breaks to avoid burnout. Relax, you’ll get this job.

Also, plan the problems you’ll do in advance. This removes a key decision step so you can start the day without figuring out what you want to do.

Finally, use Blind’s 75 list as a cram list if you need to convince yourself you’re making progress. It’s 75 questions and you can probably omit a few of these.

System Design

Barring one interview (where the interviewer was awful and kept telling me to read the problem over and over again when I asked a question, cough cough Envoy), I absolutely destroyed my system design interviews. I demonstrated an understanding of reliance, fault-tolerance, bottlenecks, and suggesting appropriate solutions.

Whenever my friends ask how I prepared, I give them unconventional wisdom: watch two YouTube videos. I kid you not. In fact, generally speaking, I studied System Design by watching YouTube videos and drawing out the diagrams on paper. I’d also add any notes and comments if applicable.

Those two videos are:

1. Google Systems Design Interview With An Ex-Googler — Designing a code deploy system by Clement
2. Either Tushar’s video or Guarav’s video on Designing a messaging application (pick one): Whatsapp System Design: Chat Messaging Systems for Interviews or System Design : Design messaging/chat service like Facebook Messenger or Whatsapp

The gist of my approach to practicing system design interviews was to mimic the thinking process and copy the approaches until I learned the tricks, pitfalls, and rules of thumb.

After you’ve watched the two videos, expand to other topics:

1. Designing a web crawler
2. Designing a news feed
3. Design TinyUrl
4. Design Search autocomplete
5. Design Netflix
6. Design Uber / a location tracker

Once you’ve completed a video, you should have a beautiful set of diagrammed notes and annotations. You can skim these before an interview to refresh your memory, tips & tricks, and things to watch out for.

With System Design covered, let’s move on to a sample routine to put this altogether.

Routine

Photo by Debby Hudson on Unsplash

This routine is an example. You can mix and match, cram, or skip content.

3 months out

1. Cover Arrays (5 days), Linked Lists (1 day), Stacks (3 days), and Queues (1 days). Watch the corresponding videos on BaseCS and do some Leetcode problems for each topic.
2. Setup weekly mock interviews with a friend.
3. Craft a google doc template for your interview questions as shown in the Interview Format & Tools section. Ideally include a grading rubric at the end. Make a copy of this template every time you do a mock interview. Here’s my template.
4. Create a new leetcode session (to track your progress)
5. Save up on some PTO time (if you’re working).
6. Start and finish your 3–5 behavioral stories.

2 months out

1. Cover Trees & Tree Traversal Algorithms (5 days), Heaps & Priority Queues (1 day), Hash Tables (3 days), and Binary Search (2 days). Watch the corresponding BaseCS video and do a few Leetcode problems for each.
2. Continue mock interviews.
3. Research companies you’d like to interview with.
4. Opt: review other topics or do more Leetcode questions.
5. Opt: watch System Design interviews on Youtube, maybe 2 every week.

1 months out

1. Sorting algorithms (2 day), Graphs & Graph Traversal Algorithms (4 days), Recursion (3 days), and Dynamic Programming (2 days).
2. Continue mock interviews .
3. Add recruiters on LinkedIn and message them to set up phone screens. You can also apply online.
4. Set up some interviews with smaller companies you don’t care about for real-world practice sessions.
5. Opt: review any other topics you want or do more Leetcode questions.
6. Opt: Review system design concepts and continue watching 2 a week videos on Youtube.

Before a Phone Screen

1. Get any info you can from your recruiter on the phone screen and the types of questions.
2. Avoid any mock interviews the 3 or so days leading up to this phone screen.
3. Search on Blind/Leetcode Discussion for the company name + phone screen for any info you can find on the questions.
4. Review the company’s question bank on Leetcode sorting by high frequency. Type out your solutions, print them, and carry these around with you so you can review whenever.
5. Inform anyone you live with when you’ll be doing a phone screen. Or, find a quiet place you can interview.
6. Opt: review other topics you want.

An hour before your Phone Screen

1. Rehearse your introduction and skim your behavioral stories.
2. Setup your environment: check the laptop & internet is working, phone is charged, you have a bottle of water, you’ve eaten a light snack, and used the restroom.

During a Phone Screen

1. If your screen is a coding challenge (and not a live phone screen), use print statements liberally to check if your code does what you expect. Also keep in mind how many questions there are and pace yourself accordingly.
2. If your screen is a live chat, greet the interviewer (ask them how they’re doing), and after they’ve introduced themselves, give your introduction.
3. If you’re asked behavioral questions: pause, pick your most applicable story from the 3–5 you wrote, and launch into the story.
4. If you’re coding, open up the online coding editor and examine its functionalities. Select your preferred language. Once the interviewer pastes the question in the doc, take time to read it. DON’T START CODING — ask any questions, cover some of the examples given, or make you own.
5. Mentally leaf through data structures and algorithms and pick one. Try the brute-force solution if you know it. Remember, code on the page is better than no code at all.
6. Explicitly write out or verbally explain your initial approach to the interviewer and ask if they’re okay with trying this approach. Run through any examples you think are necessary to vet your approach.
7. While coding, use clear variable names, comments if needed, and leverage library functions (when allowed).
8. After you’ve coded your brute-force or similar solution, test it on the examples provided or the ones you came up with. Ensure you get the correct output. Importantly, don’t spend too much time detailing all the intermediate states and changes in the variables, just skim over how your code handles the different examples.
9. If necessary to optimize your solution: identify the bottleneck in your code, think about the minimum runtime (for example, processing arrays usually means at minimum O(n) runtime because there’s n elements to look through), or mentally leaf through all of the data structures, testing them each against the problem to see if they’ll help you in some way.
10. Answer any follow up coding questions with the same approach from above.
11. Keep an eye on the time and wrap up coding by cleaning up functions, variables, and adding comments. Explain how you would make it even better, we want to sprint across the finish line strong!

Before Onsite

1. Get information from your recruiter on the types of rounds and the contents of each.
2. Take time off for the day of the interview.
3. Research on Blind or Leetcode discussion channels for recent onsite questions.
4. Review the top-frequency questions using Leetcode Premium’s company-specific question banks.
5. Inform anyone you live with you’ll need a quiet environment or make arrangements to have your interview somewhere else.
6. Avoid any mock interviews the 3 or so days before the onsite.
7. Research the company and understand their products and culture.

During Onsite

1. Repeat the steps mentioned in the During a Phone Screen section from above. The following steps are specific to onsites so keep them in mind as well.
2. Pace yourself, don’t use all of your energy on the first interview. We’re running a marathon today.
3. If you have time between interviews, review any company-specific problems and their solutions. You may receive a question you were just looking at!
4. During break times between onsite interviews, ensure your video and microphone are off. Close your laptop if you can.
5. Take a break or use the bathroom if you need to between interviews.

Summary & Reflection

Photo by mckenzie toyne on Unsplash

Phew, thanks for reading this post. I hope it helped you! Let’s cover some of the important points:

• 🎯 Deliberate Practice. Interviews come with a lot of moving parts. With the right tools and practice, you can build a blueprint for how to approach all interviews. This frees up your working memory and gives you more thinking space during the interview. To practice, analyze sections of the interview you could do better, go through the motions, learn from your findings, and repeat.
• 💪 Stack every advantage in your favor. For me, watching videos rather than reading books like Cracking the Coding interview or Elements of Programming Interviews was a major mindset shift. Memorizing my introduction & behavioral stories was another. Interviewing is already filled to the brim with stress and anxiety — make it easier on yourself.
• 📈Consistency. Following a routine, like guardrails, keeps you on track and directs you to your goals. The way I studied and my routine had a direct and measurable impact on my success and end offers.

Feel free to comment on what you’d like to hear more about. I review every comment. In the meantime, stay tuned for the next post, how to team match to find the team for you!

If you’d like to support my writing, sign up for a medium membership here: https://kencortereal.medium.com/membership.