If you'd like to support my efforts, please give this post a ❤️ and 🔖 to help others find it!
As many of us know, interviewing for software engineering jobs can be incredibly time-consuming and stressful. Recently, I had my own job search and was able to pass my interviews at Google and Microsoft. I decided to document my prep methodology and share it at https://interviewguide.dev.
What the guide covers
The guide aims to be opinionated and easily-digestible. It covers the following topics:
Preparing mentally
Interviewing is mentally tough. No one wants particularly enjoys being judged nor do they enjoy feeling like they failed. Furthermore, the amount of prep can be daunting.
Creating a schedule (both high and low-level)
One of the biggest mistakes you can make when prepping for interviews is to not have a schedule, including target dates for applying, interviewing, and obtaining a job.
Prep strategies for different interview types
Behavioral
Behavioral questions attempt to gauge how you would behave in stressful or otherwise adverse conditions. There are a couple common types of behavioral questions:
- "Tell me about a time..." These questions are based on the idea that the best predictor of future behavior is past performance. The goal is to get you to present real examples of how you have handled things like conflict and failure in the past so the company can have some insight into how you may behave in the future.
- Scenarios. Rather than looking for past examples, scenario question present you with situations and you're asked how you would handle them. Interviewers are generally looking for problem solving and empathy skills when asking these questions.
Studying for behavioral interviews is incredibly important! Almost any interview you do will have a behavioral component.
Values
Not to be confused with behavioral interviews, values interviews attempt to gauge how you align with a company's value system. For example, Google has its "Ten things we know to be true," which is a set of philosophies against which candidates might be assessed.
Some companies explicitly test against values while others unconsciously make this assessment. Regardless, it's very important to know a company's public values and be prepared to demonstrate how you align with them.
Leetcode
Leetcode-style interviews are probably the most famous, or should I say infamous, type of interview. Leetcode is a website with algorithm and data structure programming problems. In Leetcode-style interviews, you solve algorithm and data structure challenges in front of one or more interviewers. These challenges are performed on a white board or a computer depending on the company's preference and whether the interview is being conducted in-person or remotely.
These challenges aim to test your problem solving, collaboration, and technical skill. Often, interviewers will ask for your understanding of the time and space complexity required to run the algorithm.
These types of interviews were popularized by big tech companies but are used throughout the industry. For those of us who are really uncomfortable with this type of interview, there are plenty of companies that do not use Leetcode-style interviews.
Practical coding
Practical coding interviews are my favorite types of technical assessments because they generally assess the kinds of things you'd actually be doing on the job. For example, if you're applying as a front-end engineer, your practical coding interview might be writing a small HTML, CSS, JavaScript application. If you already work as a front-end engineer, then you're practice for this style of interview every day at work!
Read the practical coding section »
System design
System design interviews are aimed at determining how more senior engineering candidates might go about designing a system. These interviews try to determine how the candidate thinks about systems as a whole, whether the candidate can elicit and clarify vague requirements, and depth of knowledge in the candidate's domain. System design interviews can be very fun but their open-endedness can also be very challenging.
Read the system design section »
Technical knowledge
Technical trivia interviews generally don't involve writing code, but rather ask you technical questions to determine how well you know a subject area. These types of interviews get a bad rap, but their effectiveness really depends a lot on what types of questions are asked. For example, asking about some uncommon/obscure language feature that can be googled quickly is pointless and a bad way to assess someone's domain knowledge. On the other hand, asking someone about a foundational aspect of a domain works may be useful. Technical knowledge questions are fairly common in all interviews.
Read the technical knowledge section »
Communication: before, during, and after the interview
Communication is extremely important. Before the interview, it can help you get an idea of what to expect and make sure you're prepared. During the interview, it helps you clarify problems and demonstrate your ability to problem-solve and be a good colleague.
Read the guide
You can find the guide at https://interviewguide.dev. I would love to know what you think!
Top comments (1)
Hey Nick!
I just read through your guide, excellent material there! I strongly concur with all suggestions there, so I suppose I'm of the same "opinions" as you are.
One thought (not a disagreement) on technical knowledge interviews: As you said, good technical knowledge interviews are focused on making sure the candidate understands the underlying theory, not technical nuance. So, if you don't know, just say so, instead of giving an answer that beats around the bush. Saying you don't know tells the interviewer the same thing as a bad answer (that you don't know!), but it also tells them you have some awareness of your lack of knowledge, and that you're willing to admit it. In my opinion, those are extremely valuable traits in a developer.