### After The Interview Person leaning on large book holding a pencil # Communication After the Interview ## Immediately after the interivew Generally, I send a follow-up email to my recruiter _immediately_ after the interview. In this email, I'll let them know that I appreciate all the work they did to facilitate my interview process, I'll let them know that I enjoyed the process (only if I thought it was a good process and the interviewers were good), and that I'm really looking forward to hearing back about the position. If your recruiter hasn't yet told you how long it takes to make a decision, this is a good time to ask. I'll do this follow-up regardless of how I _think_ I did on the interview. Ever since I passed a FAANG interview that I thought I did poorly on, I always assume I have a shot until I officially hear "no." ## Following up Hopefully, your recruiter has told you how long it takes to get a decision back to you. If you haven't heard by a day or two after that period of time, send a gentle follow-up. Recruiters are often juggling a bunch of candidates for many positions. It's a good idea to keep top-of-mind and they won't be annoyed. Your email can just reiterate how excited you are for the position and ask if the recruiter has any updates on your status. ## Potential outcomes There are a few potential outcomes I have seen at this point: - **An offer.** Huzzah! - **Hiring manager discussion.** If the recruiter sets you up with a discussion with your potential future hiring manager, this is a really good sign. You're at least in very strong contention for an offer or they already know they'll make one. - **More interviews.** Some companies will send you to more interviews if they want to hire you but need a bit more information to feel comfortable making that decision. Which having to do more interviews can be frustrating, I think this is actually a great result! The company is willing to spend more time and energy on hiring you. - **Not selected.** My most frequent result! This always stinks, but remember the baseball player analogy I made earlier: the best players in the game only get on base 1/3 of the time. The best interview candidates do even worse than that. When you're not selected, you usually just get a template email from the recruiter. ## Handling offers Congratulations! Negotiating is out of scope for this handbook. I will say that you will put yourself in the best position if you have multiple offers since that gives you negotiating power. If possible, try to find out how well you did in the interviews. Some recruiters will tell you that you really knocked the interview out of the park, meaning the company wants you and you can probably negotiate more. ## Handling not being selected Feeling rejected stinks. It's important to remember that it's not the rejections that count: if you have 10 rejections and one offer, then you win! When you do hear from a recruiter that you haven't been selected, see if they're willing to give you specific feedback from your interview sessions. It's an incredible opportunity to learn and improve. That being said, many companies won't give you any feedback. But it's worth a shot! --- ### Am I Ready Checklist with a check and three Xs # Am I Ready to Start Interviewing? ## It's not a yes/no question This is _such_ a common question. The problem is it's not actually a yes/no question. Someone who has done little prep could get lucky: they could get an interview that perfectly matches things they already know or the few things they studied. Conversely, someone who has done a ton of prep might get very unlucky or have a bad day. ## When in doubt, interview If you even feel remotely prepared, **go for it** . What the worst that could happen? You don't get the job. In that case: - You've gained some great experience - You can likely apply to the same company again in 6 to 12 months - You get over your fear of failure (if that's something you experience) When in doubt, do the interview! --- ### Before The Interview Person with a backpack on a hike # Communication Before the Interview ## Recruiters are your friends Most of your contact before an interview will be with the recruiter (and sometimes a separate coordinator). With respect to the interviews, recruiters are your friends. I recommend framing your interactions with them with the mindset that they want you to succeed. This means that you should ask them questions that will help you be successful! ## Questions to ask Before your interviews, there are a bunch of questions you should probably ask your recruiters. Here is a non-exhaustive list for both on-site and virtual interviews: ### On-site or virtual interviews - Ask about dress code if they haven't told you already - Ask what interview rounds you'll have. Behavioral, leetcode, practical coding, technical knowledge, values? Many people are surprised to hear that you can ask this and a lot of the time the recruiter will tell you what rounds you'll have. They may even tell you the order of these rounds. - Ask if you can use your preferred language for the coding rounds (assuming you have coding rounds). Generally the answer is yes, but it's also possible the company has a specific language or framework they want you to use. - Ask if you can use the Internet for practical coding rounds. ### On-site - Confirm time and location. If you'll be traveling by plane or other company-paid mode of transportation, confirm logistics and a point-of-contact. - Confirm interview a couple days in advance to make sure nothing has changed. ### Virtual - Ask about what video software will be used. Download whatever software will be used and test it out days in advance. - If there is a coding portion, ask how that's going to be conducted: will you be developing locally and screen-sharing? Or will you be using a shared, online environment like CodeSandbox? Whatever the answer, make sure you practice using that setup. ## Be a good person I have seen far too many candidates self-sabotage by being rude or impolite. Being a good person doesn't just count in the interview rounds—it counts when interacting with recruiters as well. Treating someone with respect is the right thing to do, but it has the added benefit of giving you a better chance to get the job. Consider two candidates with identical technical skills, but one is a really nice person who seems great to work with and another came off as a bit of a jerk. Who would get the offer? --- ### Behavioral Smiling dog pointing left with nose # Behavioral Interviews ## What is a behavioral interview? Behavioral interviews gauge your soft and interpersonal skills rather than your technical accumen. Pretty much every company has a behavioral interview component. This is for some very good reasons: - No one wants to work with a jerk - Engineers often have to handle ambiguity - Companies want engineers that perform well under stress It has become increasing popular for companies to try to assess your _emotional intelligence_ and _empathy_ as well. They want to know that you can see things from other people's points of view and that you can negotiate tricky interpresonal relationships. ::: tip RESOURCE ALERT! One of my favorite resources for behavioral interviews is [Jeff Sipe's YouTube channel](https://www.youtube.com/c/JeffHSipe). He's a former Google recruiter and does a great job talking about the kind of empathy and interpersonal skills tech companies look for. I highly recommend you watch some of his videos. ::: ## Types of questions There are two main types of behavioral interview questions I have come across: - **Past experience.** These questions often start out with the phrase "Tell me about a time..." The interviewer expects you to provide an example of something that actually happened in your work (or academic) history. - **Hypotheticals.** These questions are scenarios presented by the interviewer asking how you'd handle a made up situation. The interviewer wants you to _not_ provide an example from the past but rather come up with a solution to a problem they have provided you. It's important to know which question you're being asked! Far too often people provide the wrong type of answer to one of these questions. When in doubt, _ask the interviewer_! > "Would you like me to provide an example from my work history or are you interested in how I would solve this problem in the future if it arose?" In the following sections, I'll tell you how I prepare for both of these types of interviews. ## Preparing for past experience questions My favorite way to prepare for past experience questions is to make a table. There are a limited number of common themes in behavioral interviews: - Challenges - Successes - Failures - Things you enjoyed - Leadership - Conflicts Those become the rows of my table. The columns are all the different projects I want to talk about. I try my best to come up with an example for each row from each project. Here's a fictitious completed table: | Theme | Project A | Project B | Project C | | ---------- | ----------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | | Challenges | Deployment process was a mess. I helped implement CD. | Team morale was low. I created social events and 1:1 calls. | Complex, nested form logic shared between clients. I implemented JSON schema that could be consumed by various parties and used to validate data. | | Successes | Reduced average request time from 1.5s to 750ms. | Handled exponential application growth from 1,000 requests per day to 50,000 requests per day. | The product beta launched with 1,000 users. customers. | | Failures | I pushed code to production that formatted dates incorrectly and caused an API endpoint to fail on every request. | N/A | Mismanaged relationship between tech team and partner tech teams caused some partners to back out. | | Enjoyed | Teaching developers about CD. | My first exposure to CDNs and rapid scaling. Really enjoyed learning about this subject area. | I got to sit in on user research. Was really interesting to see how users actually use the software. | | Leadership | I had to present my vision for better engineering practices to the CTO. | No one was an infrastructure specialist so I stepped up to lead that area. | N/A | | Conflicts | Some senior engineers were resistant to the changes I was proposing so I had to convince them in 1:1s and demos. | N/A | Team members could not come to consensus on data schema validation method. I championed a process to use a structured design document. | ### The STAR method The STAR method is a popular framework for answering past experience questions. STAR stands for: - **S**ituation - Lay the foundation for the story. Where were you working? What was the project? What role were you playing? Who else is involved in the story? - **T**ask - What task was at hand when the story takes place? - **A**ction - What action did you personally take to make the situation better (or if it was a mistake, what mistake did you make)? - **R**esult - What was the result? How did your action get things back on track? Or what happened as a result of your mistake? If appropriate to the situation, add a final thougth on what you learned. Companies like when candidates are capable of reflection and self-improvement. ### Quantify! Be sure to quantify your successes. Many organizations are data-driven and expect you to be as well. If possible try to tie your successes to revenue generated or, if not possible, tie your successes to something known to be correlated with revenue generated. Some good metrics that you may have affected: - Revenue - Number of users - Application performance metrics - Availability - Code quality measures - Team velocity ### Be careful with negatives Explain all problems and challenges with _empathy_. For example, if you had to deal with a disgruntled colleague, make sure you don't describe that person as "bad" but rather that they must have been going through a tough time. I'm not saying to lie, but I would definitely advise you to _never_ badmouth a former employer or colleague. ### Talk about lessons learned Companies will likely ask you about mistakes or failures. All of us have made mistakes, but not all of us learn from them. Whenever you talk about your mistakes, make sure to talk about lessons you learned from those mistakes and, if you were able to take corrective action in the moment, talk about that too. ### Example past experience questions The following examples are graciously taken from the [Tech Interview Handbook](https://www.techinterviewhandbook.org/behavioral-interview-questions/) under the MIT license. Make sure you check out this incredible resource for more information on behavioral interviews (and interviewing in general)! 1. Tell me about a time when you had a conflict with a co-worker. 2. Tell me about a time in which you had a conflict and needed to influence somebody else. 3. What are the most interesting projects you have worked on and how might they be relevant to this company's environment? 4. Tell me about a time you had a disagreement with your manager. 5. Talk about a project you are most passionate about, or one where you did your best work. 6. What is something that you had to push for in your previous projects? 7. What is the most constructive feedback you have received in your career? 8. What is something you had to persevere at for multiple months? 9. Tell me about a time you met a tight deadline. 10. Tell me about a problem you've had getting along with a work associate. ## Preparing for hypothetical questions In my experience these are a bit tougher than past experience questions due to their ambiguity. One of the best tips is from the aforementioned Jeff Sipe, who recommends asking clarifying questions (almost like a coding interview!) so you really understand your relationship to the sitation. Let's look at an example to see what I mean: > Interviewer: "How would you handle someone who seems disengaged with work and is not carrying their weight on the team?" The wrong thing to do here is start directly answering the question—you don't have enough information! Rather than diving into the answer, some great questions to ask would be: - What is my relation to this individual? Am I their manager? Colleague? Subordinate? - When did this start? Was it recent? Has it been going on for a while? - Is there an event that appears to have triggered this behavior? It's possible the interview says "it's up to you" in response to a lot of these questions, which is totally fine! That means _you_ get to provide the clarification and answer it in a way that best suits you. ### Interpersonal problem-solving A lot of hypotheticals will involve conflict with another individual. Empathy is important here. You'll want to make sure your proposed solutiont treats the other party like a human. Make sure your approach solves problems _collaboratively_ with that individual. In the previous example where we have an employee who is disengaged and not performing, perhaps we recommend a 1:1 to try to get to the bottom of the situation and then collaboratively come up with an action plan to get the employee back on track. ### Example hypothetical questions Here are some hyopothetical questions I have heard asked over the years: 1. How would you handle someone who seems disengaged with work and is not carrying their weight on the team? 2. What would you do if your manager wanted to go with a technical approach that you disagree with? 3. How would you convince a colleague that your technical approach is better? 4. A junior engineer on your team is being excluded from team activities. How would you fix this situation? 5. What would you do if you realized your team was going to miss a deadline? 6. A manager on a different team knows you're an excellent engineer and asks you for help but intentionally avoids speaking with your direct manager. What do you do? ## Watch Jeff Sipe's videos I'm mentioning Jeff's videos again because they really were important to me. Once you have a matrix of all your experiences, Jeff will teach you how to present that experience in a way companies want to hear: with empathy and open-mindedness. He also provides a lot of good tips of recognizing what exactly companies are looking for when they ask specific types of questions. 🎥 [Jeff Sipe's YouTube Channel](https://www.youtube.com/c/JeffHSipe) ## Out of our comfort zone Behavioral questions, especially those that deal with interpersonal relationships, can be very much out of an engineer's comfort zone. It's tough—on one hand we're being asked to reverse a linked list and on another hand we're being asked to troubleshoot behavioral problems. Because the behavioral part is tough for a lot of folks, this can be an area for you to really shine if you prep thoroughly! --- ### Creating A Schedule Woman putting task on a schedule # Creating a Schedule Creating a schedule is the most important and most neglected part of the interview process. Without a plan, the job search and interview process is far too open-ended. ## What kind of schedules to create I generally put together two schedules: - **A higher-level schedule.** This is the overall timeline of when you plan to start applying, start interviewing, and land a job. This schedule generally spans a few months (unless you urgently need employment). - **A lower-level schedule.** What will you be studying each week? When will you be studying? When will you be resting? This lower-level schedule generally spans a week or two. ## What if I miss my milestones? Schedules are a best-guess and are not perfect, but they can help you course-correct. Let's say you plan to start applying in June and start interviewing in July. If you send out tons of applications in June but get no interview by July, then you've missed a milestone—and that's okay! You should do two things: - Figure out _why_ you missed your milestone - Adjust your milestones If you didn't get a response all month, it's possible you need to adjust your résumé to better stand out. Missing a milestone gives you control because you can start course-correcting. ## Schedules vary greatly One of the least fair part about interviewing is the amount one person can prepare varies greatly from the amount another person can prepare. If you are younger and relatively unattached, you may have a lot of free time. If you have a spouse, children, and/or other obligations, it becomes a _lot_ harder. Some people spend 4 hours a day prepping and others can only prep a few hours per week. ## Stick to the schedule You should make sure your family agrees on your schedule and then you should try to stick with it. I have never felt truly prepared for interviews, but you just do your best and dive in. Interviews themselves end up helping quite a bit with prep—you practice communicating, you build confidence, and you reduce your fear of failure. ## Example schedule An example schedule that I have made for myself is below. ### High-level schedule My plan was to start studying in January, start applying in Feburary, start interviewing in March, and ideally accept a job by May. | JAN | FEB | MAR | APR | MAY | | ----- | ------------- | ------------------------- | ----------------- | --------------------- | | Study | Study + Apply | Study + Apply + Interview | Study + Interview | Target Job Acceptance | ### Low-level schedule I time-boxed my prep to Monday, Wednesday, Friday from 8-10pm (after work and after I put my kid to sleep!). Importantly, I scheduled time to _not_ study so I didn't burn out. The following is a two-week schedule that I repeated throughout my prep time. | SUN | MON | TUE | WED | THU | FRI | SAT | | --- | ------------------- | --- | ----------------- | --- | ------------------ | --- | | | 8-10pm (Behavioral) | | 8-10pm (Leetcode) | | 8-10pm (Knowledge) | | | | 8-10pm (System) | | 8-10pm (Leetcode) | | 8-10pm (Knowledge) | | If you're junior, you may spend less time (or none at all) on System Design and more in other areas. Importantly, do what feels right for you and adjust as necessary. It's far better to have something imperfect than having nothing at all. --- ### Credits # Credits Thank you to the following people/resources that enabled this guide: ## Yangshun Tay Yangshun Tay wrote the Tech Interview Handbook, the Frontend Interview Handbook, and the Blind75 leetcode problem list. A true pioneer in the tech interview space! - [Follow Yangshun on Twitter](https://twitter.com/yangshunz) - Check out the [Tech Interview Handbook](https://www.techinterviewhandbook.org/) or the [Frontend Interview Handbook](https://frontendinterviewhandbook.com/) ## DrawKit All of the chapter images throughout this guide came from DrawKit. Check them out for awesome illustrations! https://drawkit.com/ ## Vitepress This guide was authored using [Vitepress](https://vitepress.vuejs.org/). It was an amazing experience that let me focus on the writing process. Give it a try! --- ### During The Interview Two people talking online # Communication During the Interview ## This is extremely important Communicating well during an interview is a skill that will set you apart from many other candidates. As we interview prep, we tend to get into a few erroneous mindsets: - I _must_ know everything - I _must_ get the most efficient solution - I _must_ not make any mistakes But we're forgetting what companies and interviewers are actually looking for at the end of the day: they are trying to see what kind of employee/colleague you'll be. The best colleagues I've ever had haven't met any of the three criteria mentioned above. In my experience, a more accurate list of competencies interviewers generally look for are as follows: - Candidate can get to a good solution on technical challenges and can _communicate_ how and why they arrived at this solution - Candidate asks the right questions to resolve ambiguous requirements - Candidate demonstrates the ability to handle challenging technical and interpersonal situations - Candidate is relatively friendly/agreeable (or at least not a jerk) ::: info THERE ARE ALWAYS EXCEPTIONS I'm sure there are companies out there that need you to get the most efficient solution or they'll fail you. My experience is this is more the exception than the norm. ::: ## Things you should do during interviews Here is a non-exhaustive list of communication tips when you interview. - **Ask clarifying question.** I would pretty much never go straight into solving a question unless it's very, very clear. Otherwise, asking questions shows you are discerning and exacting about requirements. You can also demonstrate your knowledge of the domain: a question such as "should I be concerned about [some real-world consideration] when I answer this question?" demonstrates that you understand real-world nuances. - **Over-communicate about your thought process.** One of the biggest mistakes candiates make time and time again is being silent while they try to figure out, or solve, a problem. Interviewers can't read your mind, so the only way for them to get positive signals, aside from a correct answer, is to hear how you think. This also has additional benefits—if you're going down a bad path, the interviewer may stop and redirect you! - **Ask genuine questions about the company or job.** During most interviews, you're given the chance to ask the interviewer questions about the company or job. In fact, this is often at the end of the interview and will be the interviewer's last impression of you. It's a low pressure way to demonstrate that you're interested in the job! Use this to your advantage. - **Be friendly.** Interviewing is really stressful and stress can make us act in suboptimal ways. Try to remember the human element: you probably like working with friendly people and your interviewer does too. - **Be optimistic.** I have passed interviews that I was _sure_ I was failing during the interview. Do not trust your panicky interview brain. Assume that you always still have a shot to pass the interviewer and act accordingly. ## Communicating when you're stuck It's pretty common to get stuck during coding challenges. At this point you might be panicking and your brain is churning through everything you studied. It's really important, however, to not clam up in this moment because your interviewer has no idea what you're thinking. I recommend the following when you're stuck: 1. **Try to discuss your thought process.** This is ideal but not always possible. For example, if you're stuck on a Leetcode-style problem you could say something like "I'm not quite sure what the solution is yet, but I'm noticing the elements in this array are sorted, so I suspect a good solution would involve binary search." Anything you can communicate demonstrates you're not just sitting there but rather than you're doing some analysis. 2. **Mention that you're taking some time to think.** It's not always possible to give a play-by-play of what you're thinking, especially if you're deep in thought. In that case, mention to your interviewer that you're going to take a minute or two to think. This at least gives them a hint that you're not just frozen but rather are working out a solution. 3. **Subtly ask for a hint.** If you've been stuck for a bit, asking for a hint is often the best way to go (solving with a hint is generally better than not being close without a hint). Rather than saying "can you give me a hint," which I think is a bit too pointed, I prefer something like "hmm, I'm a bit stuck on how to do [X]. Do you have any suggestions for me to consider?" ## The "good colleague" lens I always try to approach communication with prospective employers with the "good colleague" lens. How can I behave and communicate such that this person will want me as a colleague? --- ### Etiquette Smiling dog # Interviewing Etiquette ## Good etiquette is mandatory I'm always surprised by how many candidates self-sabotage by having poor interview etiquette. Interviews are the time to put your best foot forward. Companies know this and will assume that if you have poor etiquette at your best, then your day-to-day is probably worse. ## Things to keep in the back of your mind As always, this is not an exhaustive list of ways to have good interview etiquette, but hopefully you get the idea. - **Show up on time.** I have settled on five minutes early as a good time to be at the interview (either virtually or in-person). If virtual, make sure everything has been tested ahead of time and you're logged in at least right no time. In person can have a bunch of additional risk: traffic accidents, subway delays, etc. I personally would rather eat lunch or have a coffee next door to the interview for half an hour than risk being late. - **Thank people for their time.** Being an interviewer is hard and coordinating interviews is hard. Thank everyone (recruiters, coordinators, interviewers) for their time and assistance. It's the right thing to do and also reflects well upon you. - **Be friendly, gracious, and positive.** Attitude is so important in interviews. We often spend so much time thinking about cracking coding challenges that we forget that we're interacting with a human. Try to act like someone your interviewer would want to work with on a day-to-day basis. - **Don't be critical of the company or its processes.** When asking questions about how the company or project operates, you might find something that strikes you as not being a best practice. That's okay—there's actually probably a good reason they do things the way they do and, if not, maybe you can help fix things! But what you _shouldn't_ do is start telling the interviewer they need to fix their processes. This actually happens! Don't do it unless the interviewer explicitly invites you to (e.g., "we're having trouble doing [x] given the constraints, I'm wondering how you would approach the problem."). - **Know about the company, its values, and what you would be working on.** Every company wants to feel special. It's worth it to take 30 minutes or so to read through a company's values and learn about whatever product you'd be working on. - **Be honest/forthright.** It can be pretty obvious when you're making up a scenario to fit a question. Hopefully you have examples for each behavioral question, but if not, it's okay. Do your best to redirect to a hypotentical answer instead (e.g., "I'm not sure I have a great example of this from my past, but how I would generally want to approach a situation like this is..."). - **Ask questions that demonstrate your interest in the role.** Ask questions about how the team operates, how the product fits into the organization's vision, and really anything else that makes you seem interested in the role. Note: I hope you actually are interested in the role, but at the very least you should make sure you _appear_ to be interested. ## Etiquette is a two-way street Interviews are also a company's chance to put its best foot forward. If you feel disrespected or mistreated during an interview, make note of that. If this is how they treat candidates they're trying to woo, they might treat employees even worse. --- ### Feedback # Submit Feedback This guide is always a work in progress! I'd appreciate any input you have to make it better. The best ways to send me feedback is [submitting an issue on Github](https://github.com/nas5w/interview-guide/issues). --- ### Index Person hiking wearing a backpack # Preface ## Welcome to my interview guide! My name is Nick and I'm a senior software engineer. I have participated in around 100 software engineering interviews on both sides of the table—as a candidate and an interviewer. I have passed interviews at both big tech and FAANG companies as well as smaller startups. This guide is my attempt to codify my opinionated interview process for the benefit of the software development community. ::: tip THESE ARE MY OWN VIEWS Everything in this guide represents my own views and not the views of any of my current or past employers. ::: ## Supporting this guide This resource is, and will always be, free of charge. If you'd like to express your support for this work, I would appreciate if you starred the repository on Github:
You can also _very_ optionally "buy" this online guide for whatever price you want. I appreciate any support! [Buy now](https://buy.stripe.com/4gM9AUfsj6xt6Es53y4c800) ## Target audience This guide is directed at both new and experienced software engineering candidates. It focuses on individual contributor (IC) engineering rather than engineering management. If you are interviewing for engineering management positions, there may be still be some beneficial sections of this guide; however, much of it may not be applicable. ## Goals and non-goals There are a number of incredible existing resources that I believe tend to be too comprehensive to be directly actionable. The niche I'm trying to fill is providing my specific, opinionated process for prepping for interviews. My way of doing things won't work for everyone, and that's totally okay! But if you like my process, I'm hoping this guide is very actionable. **Goals:** - Be opinionated and actionable - Be easy to read - Focus on methodology **Non-goals:** - List every resource under the sun - Contain the depth and breadth of information that exists in other excellent resources - Address adjacent topics like how to get an interview or how to negotiate salary ## How to read this guide This guide isn't _too_ long, so my recommendation is to read it front-to-back at first. Since it's intentionally opinionated, you may find that my approach won't work for you, and that's totally okay. There are a lot of concepts that I believe will just "stick" once you read them the first time through. During your prep, I recommend you check back to relevant sections as appropriate to refresh your memory. --- ### Leetcode Man programming on laptop # Leetcode-Style Interviews ## What are Leetcode-style interviews? Leetcode-style interviews are probably the most infamous type of software development interview out there. In these interviews, you're given an algorithm/data structure challenge that you have to solve either on a whiteboard or computer. The interviewer is judging your coding, critical thinking, communication, and problem solving skills. Often, you're expected to communicate decisions and tradeoffs you're making and discuss the time and space complexity of your solution. While many companies (especially big tech companies) conduct Leetcode-style interviews, it's important to recognize that many other companies _don't_ perform these kinds of interviews. [This Github repo](https://github.com/poteto/hiring-without-whiteboards) has a list of companies that don't perform Leetcode-style interviews. Additionally, if you're interested in a company and are curious as to whether they do Leetcode-style interviews, be sure to check out the interview section of their [Glassdoor](https://glassdoor.com) page. If you're really uncomfortable with the idea of algorithm and data structure challenges, you can definitely find great jobs where you don't have to solve these puzzles. ## How you're evaluated It's common to panic and think "I must find the optimal solution" when facing a Leetcode-style problem. In my experience, this isn't the case. I had one FAANG interview where I think I provided the optimal solution for maybe one out of the four Leetcode-style problems but _still_ got the job offer. While it's impossible to generalize this _too_ much (companies vary), you're usually assessed on the following topics: - **Coding ability.** Do you have a good grasp of control flow and logic? Can you write code relatively quickly and is it well-formated? Do you name variables logically? - **Algorithms/data structures.** Do you use algorithms and data structures appropriately? How optimal was the space and time complexity of your solution? Did you correctly assess the space and time complexity? - **Communication.** Did you explain your work well? Did you ask clarifying questions? Did you talk about tradeoffs? Can you explain technical concepts? Were you closed off or rude? - **Problem solving skills.** Did you take time to understand the question and ask the right clarifying questions? Did you give the interviewer the impression that you'd be rigorous in approaching new challenges? As you can see, the algorithms and data structure part is just a small piece of the puzzle. At least for me, this was a big load off my mind: of course you should try to do your best to come up with an optimal solution, but you can get pretty far by honing your skill in some of these other areas. ## How to prepare for Leetcode-style interviews I promised an opinionated guide and in this section I won't disappoint! My first suggestion is to purchase a [Leetcode](https://leetcode.com) premium membership. This can be a controversial opinion, but I truly think the added features justify the $35/month. The two biggest benefits to me are: - Official Leetcode-provided solutions - Company tags for questions, sortable by frequency **Note:** If $35/month will put you in a bad position financially, don't buy it! You can find the same information for free, but it just takes a bit more time to seek it out. For example, there are some good solutions to various problems on YouTube. Additionally, you can find company-specific questions in the Leetcode forums. ### Using the NeetCode 150 Leetcode is a huge site with thousands of questions. So where to begin? Enter _Neetcode_. [NeetCode](https://neetcode.io) really saved my bacon when it comes to Leetcode-style interviews. NeetCode provides a list of 150 curated, categorized problems to practice. In addition to curating a list of problems, the author has created _excellent_ video solutions for each problem. The following screenshot shows the NeetCode user interface. The process I recommend for using NeetCode 150 is as follows: 1. Do all of the "easy" problems in one category. This helps you learn the fundamental data structures and algorithms associated with this category of problem. 2. Repeat this for each category, going down the list. 3. Once you've done all the "easy" problems, repeat the process for the "medium" problems. This will check how well you retained some of those core data structures and algorithms and be a good bit more challenging. 4. Finally, repeat for the "hard" problems. These are mostly going to be quite tough! As you do each problem, make sure to try to assess the space and time complexity of your solution. [The Big O Cheatsheet](https://www.bigocheatsheet.com/) can be a handy reference when you're trying to figure out complexity. ### When you're stuck For each problem, I recommend trying to solve the problem on your own for at least 30 minutes. If it's a "hard" problem, go for 45 minutes to an hour. Inevitably, you'll get stuck. In fact, if you haven't done a lot of Leetcoding, you'll probably get stuck on "easy" problems (I certainly did). What helped me the most is the NeetCode tutorial video associated with each problem. They're very well done, usually whiteboarding the theory behind the solution before writing the actual code. The official Leetcode-provided solutions can also be a big help: they typically start with a "brute force" solution and then work up to smarter and smarter solutions with improved space and time complexity. Once you understand the approaches, go back to LeetCode and write the solution yourself without the video. This was extremely important to me—watching a video of the solution and actually writing that solution out are very different things. ### Do all the problems if you can Do all the NeetCode 150 problems if you can. I actually couldn't—there were some "hard" problems for which I never got a functioning solution. Oh well! ### Company-tagged questions Users can report to Leetcode when they see a question at a certain company. Leetcode tags questions with these companies and computes the most-frequently reported questions per company. If you subscribe to Leetcode Premium, you'll have access to this feature. Many companies actively avoid asking questions that have leaked onto Leetcode; however, I still found practicing these tagged questions to be fruitful because it gives you a flavor for the types of questions certain companies ask. My recommendation is to navigate to a company's tagged questions (assuming you'll be interviewing with that company) and sort by frequency so you can complete the most frequent questions at that company. ### Practice talking through solutions It's going to feel strange at first, but it's really good practice to describe what you're thinking and doing as you solve practice problems. You don't want the interview to be the first time you do this! ### Use Glassdoor Use [Glassdoor](https://glassdoor.com) to look at a company's interview page. Often, people will write about the kinds of questions they're asked. You may find they focus on a specific category of Leetcode problem (or maybe they don't even ask Leetcode-style questions). ### Use whatever language you know best There are a lot of takes on what the best language is for Leetcoding (hint: it's Python). But the truth is you should just use whatever language you're most comfortable with. I have had a front-end focus most of my career, so I used JavaScript. If you have no best language, then use Python (it's terse, readable, and has some nice built-in data structures). It's unlikely a company will require you to use a certain language, but I _have_ heard of it happening. Make sure to check in with your recruiter to verify you can use your chosen language! ## How much Leetcode practicing is enough? This is a very hard question to answer! I did somewhere around 220 total questions last time around and had a lot of success during my interviews. That being said, some people do well practicing less and some people don't do well practicing more. There are a couple of realities here: - Quality of your practicing is more important than quantity. If you complete a ton of questions but only because you look at the answer every time, you're not really developing your problem-solving skills. - There's a good bit of luck when you're interviewing. Practicing more problems increases the likelihood that you'll have success in an interview, but there's always a decent chance even the most practiced person will be stumped. The truth is I never felt truly ready to interview for Leetcode-style questions, but I did a couple hundred questions and just went for it. ## Hone your soft skills I've talked a lot about solving Leetcode problems, but in reality there's another piece of the Leetcode-style interview process that's comparably important: you should aim to leave the interviewer thinking, "wow, I'd love to work with that person." I (think) I have had success in this area by doing the following: - **Overcommunicate.** The interviewer has no way of knowing what you're thinking unless you tell them. This is especially important if you haven't figured out a solution yet and you're thinking through options. - **Be friendly.** Leetcode-style interviews are stressful. By default, when we're stressed, we are not very happy. Interviewers see _a lot_ of candidates who are all business trying to crank away at these coding challenges. You can stand out a lot if you smile and are conversational/friendly. - **Ask questions checking your logic.** Interviewers mostly want you to succeed, especially if you seem like a good person. My favorite question to ask during a Leetcode-style interview is, "does that make sense?" I'll use this after I have proposed an approach to the problem and explained its time and space complexity. If you're on the money, the interviewer will often say, "yeah, that sounds great to me!" If they want to see something different (e.g., there's a flaw in your logic or your solution won't be efficient enough for them), they'll often tell you that. That's a huge benefit to prevent you going down the wrong path! You can't necessarily control whether you get a Leetcode problem you'll be able to solve optimally, but you _can_ control your demeanor/soft skills during the interview. This could be the difference between getting the job and not getting the job! ## Recap This was a long section, so I'd like to provide a recap. 1. Practice Leetcode-style questions by using the [NeetCode 150](https://neetcode.io/practice). Do all the easy questions, then the medium questions, then the hard questions. Spend at least 30-60 minutes trying to figure out each question yourself before watching the NeetCode walkthrough video. 2. Practice talking through questions as you solve them. 3. Use Leetcode company tags to find the most-frequently asked questions at a company. 4. Use [Glassdoor](https://glassdoor.com) to see what types of questions are asked at a company. 5. Don't develop tunnel-vision on just solving the problem. Make sure you focus on coming off as a good potential colleague. --- ### Practical Coding Man presenting something in front of a webpage # Practical Coding Interviews ## What are practical coding interviews? 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! ## Types of practical coding interviews I have generally seen two types of practical coding interviews: - **Pair-programming.** Usually you're writing the code and screensharing (or projecting your screen if in person). It's up to the company/interviewer how much they will participate in the exercise. - **Take-home tests**. You're given an assignment to complete on your own at home without someone looking over your shoulder. ## How to prepare for practical coding interviews The nice part about practical coding interviews is that, if you're currently working in the industry, you're likely practicing for this type of interview every day at your current job. That being said, there are some specific steps you should still take to prepare for these interviews. ### Ask a few questions ahead of time When you find out from your recruiter that you'll have a practical coding exercise, be sure to ask them the following clarifying questions: - **What environment will I be using?** Some companies ask you to use a shared, online environment (e.g., CodeSandbox) while others will have you use your local machine and screen-share. Whatever the answer, be sure to practice in that environment. - **Am I expected to use a particular language or tech stack?** For Leetcode-style questions, you can usually use whatever language you want. For practical interviews, I have seen a bit less wiggle room. A React company might want to build a React app with you, a Django company might want to build a Python API with you. Make sure you know what the company expects. - **Can I use external libraries?** Most practical challenges I've done don't need external libraries, but it's usually good to clarify this ahead of time. - **Can I use Google?** Many companies don't care if you use Google for these challenges. After all, they're trying to see how you would work in the real world and in the real world we use Google quite a bit. ### Be very careful to meet all requirements Make sure to read requirements carefully and continually check back in on them. When you're finished the assignment, ask the interviewer if we can step through the requirements to make sure they're all met correctly. ### Find out if you're expected to write tests In the real world, we write automated tests for our software. In practical coding interviews, this is much less of a certainty. This could be something you ask of the recruiter ahead of time, but at the very least be sure to ask during the interview. ### Find out if the interviewer wants this to be a collaboration They might just want to watch you code, but it's also possible they want to know what it's like to work collaboratively with you. I actually prefer the collaborative model: it gives you a chance to show off your communication skills, proves you'd be a great colleague, and keeps your interviewer engaged. ## Example problems Practical problems are _very_ domain-specific. That being said, here are some examples you can practice building based on your discipline. ### Backend - Build a CRUD API - Implement specific business logic in a function or class - More TBD ### Front-end - Write an app that fetches data from an API and displays it on the page - Implement JavaScript array methods (`map`, `filter`, `reduce`) - Implement `Promise.all` - Create a loading bar - Create a slider component - Create an image carousel --- ### Preparing Mentally Woman meditating # Preparing Mentally for the Interview Process ## You've got this! First and foremost, you've got this! Software development interviews are hard and there are a lot of things you need to prep. But everyone going after the same jobs are _also_ mere mortals. The key is to make a plan, do your best, and be persistent. ## Software development interviewing is really hard Companies often ask you to devote several hours interviewing (and countless more preparing). During interviews, people look over your shoulder as you complete coding challenges, judging you as you go. Talk about stressful! ## You have to prepare mentally Given how time-intensive and stressful software development interviews can be, it's a good idea to prepare mentally for the process. In this section, I talk about a few things you can do to "weather the storm" during your interview process. ## Set goals with dates Far too often someone tells me they're preparing for software engineering interviews, but they haven't put any of the following milestones on the calendar: 1. start submitting résumés to companies 2. start interviewing 3. accept a job Milestones #2 and #3 are more in your control than you might think. If you miss any of your planned dates, you should start _course correcting_: what can you be doing differently to get better results? The timing and spacing of these milestones likely varies dramatically based on your comfort level with interviewing and your current situation. For example, if you're out of practice with interviewing and you are comfortable in your current position (e.g., at university or in a stable job) then perhaps you give yourself a couple months to complete each step. Conversely, if you have just been laid off unexpectedly and you need employment badly, you may want to perform each of these steps as soon as possible. ## Time-box your prep sessions For some folks, thinking about interview prep can dominate your life if you're not careful! For others, it can be hard to just sit down and do it. In both cases, it's a great practice to _time-box_ your studies: perhaps it's an hour per night, maybe two. Or maybe an hour every other day. Regardless of the amount of time, I strongly suggest you document your plan and stick to it. When you're not in the time-box, enjoy life and try not to think too much about it. This deliberate time off will help combat burnout. ## Make sure your family is on board In the next section, we'll talk about combining milestones and time-boxing into a schedule. Once you have a schedule, make sure your loved ones are on board (if applicable). This is especially important if you need to do fewer chores or a bit less childcare while you're studying. If you have a plan and your family is on board, it'll make it much easier to manage your prep along with your personal life. ## Reframe your thinking around failure The last piece of mental prep I can suggest is a big one: reframe how you think about failure. One of the biggest reasons people avoid technical interviews is fear of failure. I suggest approaching technical interviews how a baseball player approaches an at-bat. If you're unfamiliar with baseball, it's _really good_ if a baseball player gets on base one third of the time. That means 67% of the time, the baseball player doesn't make it—they "fail." But this doesn't make them a bad baseball player, it's just hard to get on base. That's how software engineering interviews are. They're not easy and you often don't get the job—but that's totally okay. I personally have had a bunch of interviews where I performed poorly. Some where I just sat there and had no idea how to answer the question. None of that mattered though because each time I _eventually_ got a great job, and that's all that matters. --- ### Questions For The Company Person asking questions # Questions for the Company ## Prepare these in advance Questions for the company are critical. They show the company that you're prepared and interested in them. But, even more importantly, they can help you suss out whether a company is right for you. ## When to ask questions Hopefully every interviewer with whom you speak will give you a chance to ask questions. Often, this comes at the end of an interview session. This is a great opportunity to learn about the company and whether you would want to work there. Definitely have at least a few questions for each interviewer, even if you ask the same questions to a couple different interviewers. From their perspective, it's a red flag when a candidate doesn't have any questions (how interested could this candidate be?). ## What to ask Questions to ask can range from general, process-related questions to more domain-specific questions. Some example questions I tend to ask as a web app engineer include: - **How is the project managed?** Agile, waterfall, agilefall, Kanban? I personally like agile better because I think it reduces project risk. - **What does the lifecycle of a new feature look like? What does the lifecycle of a bug look like?** These questions try to determine if the company has reasonable ways features are determined and what phases a feature goes through to get to production. Likewise, I try to determine what kind of vetting bugs go through and how they're prioritized. In this question I also try to determine whether the project uses modern practices like automated testing and continuous integration. - **How often do you ship code to production?** I'm a fan of shipping constantly since it reduces the pressure on any one deployment and also makes deployment more trivial. Of course, this isn't always possible, but it's good to understand what this looks like for your prospective project. - **What's something interesting you worked on recently?** For fellow engineers, I'm curious what tasks they did recently that were interesting. There's no right or wrong answer, but it might give you a sense of the work. - **What are your biggest challenges right now?** This question is always interesting because you get answers that range from difficult business challenges to areas of technical debt. - **What kind of technical debt does the codebase have?** I usually preface this question by saying "I know that every project has technical debt of some kind." It helps show you're pragmatic and their answers will give you a hint about what kind of challenges you might face on the project. ## Outcomes I aim to leave the "questions for the interviewer" part of the interview with two outcomes: - The interviewer thinks "wow, this candidate is really interested in this job" and -x I have enough information to actually make that determination. --- ### Resources Person grabbing file # Resources ## Other guides/handbooks Check out these other awesome handbooks loaded with advice on tech interviewing. | Resource | Description | Link | | ---------------------------- | ----------------------------------------------------------------------------------- | -------------------------------------------------- | | Tech Interview Handbook | Detailed handbook covering many technical interview topics in depth. | [Link](https://www.techinterviewhandbook.org/) | | Front-end Interview Handbook | By the same author of the Tech Interview Handbook but aimed at front-end engineers. | [Link](https://www.frontendinterviewhandbook.com/) | ## Behavioral interviews Ace your behavioral interviews with these resources. | Resource | Description | Link | | ------------------------------------- | ------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------- | | Jeff H. Sipe's YouTube channel | A recruiter who spent 5 years a Google talks about recommended responses to behavioral questions. | [Link](https://www.youtube.com/c/JeffHSipe) | | Top 30 behavioral interview questions | Behavioral questions from the Tech Interview Handbook to practice. | [Link](https://www.techinterviewhandbook.org/behavioral-interview-questions/) | ## Leetcode-style interviews Tackle those pesky algorithm and coding challenges. | Resource | Description | Link | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------- | | Leetcode | The site after which these interviews are named. In my opinion, this is where you should be doing the bulk of your practicing. | [Link](https://leetcode.com) | | Neetcode | Practice the **Neetcode 150** and the **Blind 75** using this checklist. | [Link](https://neetcode.io/practice) | | Neetcode YouTube channel | Just phenomenal explanations of leetcode solutions. These are linked from within the Neetcode checklist mentioned above as well. | [Link](https://www.youtube.com/c/NeetCode) | | Grind 75 | The creator of the Blind 75 created a new list and a website that helps you plan your studies. I didn't use this resource during my search but it seems nice. | [Link](https://www.techinterviewhandbook.org/grind75) | | Big O Cheatsheet | Time and space complexity of the most popular algorithms used in Leetcode challenges | [Link](https://www.bigocheatsheet.com/) | ## System design interviews Crack the system design interview | Resource | Description | Link | | -------------------------------------------- | -------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | | The System Design Primer on Github | Guide for prepping system design interviews and includes flash cards for studying. | [Link](https://github.com/donnemartin/system-design-primer) | | The System Design Interview for IT Companies | Another Github-based guide for system design interviews. | [Link](https://github.com/checkcheckzz/system-design-interview) | | The RADAD framework | A good framework for progressing through system design interviews from the Front-end Interview Handbook. | [Link](https://www.frontendinterviewhandbook.com/front-end-system-design/#radad-framework) | | 31 system design interview questions | A good collection of system design interview questions to practice. | [Link](https://igotanoffer.com/blogs/tech/system-design-interviews) | ## Technical knowledge interviews Good resources for brushing up on technical knowledge questions. | Resource | Description | Link | | ------------------------------------------------- | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | | Front-end Developer Interview Questions on Github | A very comprehensive list of front-end developer technical knowledge questions. | [Link](https://github.com/h5bp/Front-end-Developer-Interview-Questions) | | Backend Developer Interview Questions on Github | A list of backend developer technical knowledge questions | [Link](https://github.com/arialdomartini/Back-End-Developer-Interview-Questions) | | A Googler's front-end interview questions | Questions one Googler mentions are his go-to for senior candidates. | [Link](https://medium.com/codex/my-google-front-end-interview-questions-bca96925c16a) | ## Other useful resources Don't quite fit into a category but they're important! | Resource | Description | Link | | ------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------ | | Hiring Without Whiteboards on Github | Hate leetcode-style interviews? This is a list of companies that use other ways of assessing candidates. | [Link](https://github.com/poteto/hiring-without-whiteboards) | | Glassdoor | Look up company reviews, see if people complain about work-life balance, investigate what a company's interview process looks like. | [Link](https://glassdoor.com) | | Levels.fyi | Crowdsourced data on compensation for many tech companies. Use this to determine whether you should even apply to a company or if it likely won't meet your salary needs. | [Link](https://levels.fyi) | --- ### Support # Support this guide There are a few ways you can help support this guide. ## Helping the guide grow First and foremost, giving the guide a "star" on GitHub will help it become more popular. Please click the button below to give it a star! ## Pay what you want I set up a Stripe page if you'd like to "buy" the online guide. I appreciate any money you'd like to throw my way! [Buy now](https://buy.stripe.com/4gM9AUfsj6xt6Es53y4c800) --- ### System Design Person explaining complicated system # System Design Interviews ## What are system design interviews? System design interviews generally give you a set of requirements for a relatively complex system and ask you to come up with a design. Often, these requirements start off somewhat vague to test whether you know what types of questions to ask to gain clarity about the system. These interviews are generally aimed at more senior candidates since juniors can't be expected to have performed too much system design work in their careers. These interviews can be some of the best barometers of a senior engineer's knowledge, but I personally find them to be the trickiest due to their open-ended nature. ## Types of system design interviews I have seen two types of system design interviews: - **Pure design.** You just focus entirely on specifying the system and talking through how you would design it. You may draw up some diagrams to help convey architecture to the interviewer. - **Design + coding.** The problem is slightly smaller in breadth. You talk through the design of the system and then you write some code to start implementing it. System design interviews look a lot different depending on your specialty. I have interviewed for both front-end and full stack web application engineer positions. For front-end positions, system design interviews tend to focus on designing a UI component and then implementing the HTML, CSS, and JavaScript for that component. For full stack positions, I have seen more pure design problems where you talk through various topics like how you'd make the application scale, database schema, and API design. ## How to prep for system design interviews The way I practice system design interviews is to do the following: 1. **Create a list of the considerations that applies to the domain for which I'm interviewing.** For example, if I'm interviewing for a front-end position then my interview will likely involve topics like accessibility and internationalization. 2. **Find relevant system design questions online.** There are a lot of good examples online. Also, it's not too difficult to come up with your own examples. 3. **Design the systems.** Take 45 minutes to an hour to design one of the systems you've identified. Make sure you draw out/sketch architectural pieces, which will be helpful during the interview. When you're done, review your work and make sure you've addresseed all the topics that came up in the list you made. If there are any deficiencies, do some studying of those areas. ### Creating a list of topics Here are a couple lists of topics for front-end and backend positions. If you have a different specialty, do so googling to find out the relevant topics for your domain. #### Front-end - Accessibility - Performance - Security - Caching - Device types / responsiveness - Languages / internationalization - Componentization - Component API - User experience - Multi-tenancy - Analytics / telemetry #### Back-end - Database design - Scalability - Security - API design - Caching - Availability - Reliability - Performance - Authentication / authorization - Telemetry ### The part you can't practice too well: asking questions One tough aspect of system design interviews is you really don't know which items in the above lists the interviewer will be interested in, which is why you need to ask a lot of questions. For example, a good front-end clarification would be asking whether the system should support multiple languages. If the interviewer says "yes," you should spend some time explaining the achitecture for supporting different langauges. If the interviewer says "no," then you can skip this topic as you design your system. ### Use the RADAD framework The Frontend Interview Handbook talks about the [RADAD framework](https://www.frontendinterviewhandbook.com/front-end-system-design/#radad-framework), which I found to be a really useful way to spend my time during the interview. The following is a copy/paste from the Frontend Interview Handbook to give you an idea of the framework, but I absolutely recommend you navigate to the handbook itself for more detail: - **Requirements clarifications/alignment** - Ask about the requirements of the system. - **Architecture** - Outline the architecture of the system (could be a UI component or an app, depending on the question). Draw diagrams where relevant. - **Data model** - How would the component store any data passed into it? What data structures are used? - **API design** - What's the API for using this component? What options will be allowed on the component? - **Deep dive** - User Experience (UX), Performance, Accessibility (a11y), Internationalization (i18n), Multi-device support, Security This list is very front-end focused, but it applies equally as well to backend or full stack system design interviews. ### Find out where to spend most of your time Once you've asked as many clarifying questions up front that you can think of, I recommend asking if there's a particular part of the system the interviewer is interested in. A lot of times the answer is "no," and you get to choose the focus. But in the event that the interviewer is particularly interested in one part of the design, that's a really good piece of information to have. Make sure to take notes as you're asking clarifying questions! Here are some good clarifying questions, which may or may not be applicable depending on the system you're being asked to design: If you're being asked to design a messaging service, you may ask: - How real-time the messaging needs to be - Whether there any special security requirements (e.g., end-to-end encryption) - Whether we have insight into anticipated usage numbers - How long messages should be retained - Whether messaging should support media (e.g., images and video) If you're being asked to design an calendar component, you may ask: - Whether it needs to support multiple languages / internationalization - Whether it needs to support date ranges or just a single date - What browsers and devices it will be used on - What type of data should be stored in the calendar ### Relevant system design questions The following is a non-exhaustive list of system design questions I have heard of. Feel free to practice these examples. Also, be sure to google around for other examples to practice. #### Back-end - Chat / messaging application - Twitter / micro-blogging platform - Link shortener (e.g., bit.ly) - Any create, read, update, delete (CRUD) API - Public library checkout system API - Video streaming service - Pinterest #### Front-end - The front-end for anything listed in the back-end section - Specific components: - Date-picker - Image carousel - Modal - Accordion Here's an additional resource with system design interview questions and answers: - [31 system design interview questions (and sample answers)](https://igotanoffer.com/blogs/tech/system-design-interviews) --- ### Technical Knowledge Woman explaining something and asking a question # Technical Knowledge Interviews ## What are technical knowledge interviews? Technical knowledge interviews involve asking you questions about your domain in an attempt to see if you understand its underlying theory. Technical knowledge interviews are a mixed bag: sometimes they're performed well and truly measure whether the candidate is knowledgeable about their domain. In some cases, however, companies test a candidate's knowledge of little-known language features or other trivia. Fortunately, I have seen the former case more than the latter case, especially in recent job searches. I think (or at least I hope) companies are coming around to the fact that nuances can be easily googled and underlying theory is far more important. ## How to prep for technical knowledge interviews Studying for technical knowledge questions is actually fairly _simple_, but can be time-consuming. It's also stressful because every software development domain has tons of associated theory. You can't possibly know it all! The way I study for these interviews is to: 1. **Find relevant lists online.** People have contributed large lists of knowledge questions online for various domains. Find some relevant to your domain (I list a couple below). 2. **Skim through the list.** Read through these lists. Hopefully you know how to answer a decent number of questions on the list (it's okay if you don't!). For any topic you don't quite know, write it down on your own separate list. 3. **Flash cards!** Call me old-fashioned, but I really like flash cards for developing knowledge. There are phone apps nowadays, so it's even easier. My recommendation is to make a flash card for each topic you need to understand a little better. The nice thing about flash cards is you might be able to multitask with them. For example, if you commute on the subway to work you could turn that into technical knowledge flash card time. ## Some relevant lists Here are some lists I have used to find technical concepts to study: - [Front-end Developer Interview Questions on Github](https://github.com/h5bp/Front-end-Developer-Interview-Questions) - [A Googler's front-end interview questions Questions](https://medium.com/codex/my-google-front-end-interview-questions-bca96925c16a) - [Backend Developer Interview Questions on Github](https://github.com/arialdomartini/Back-End-Developer-Interview-Questions) --- ### Types Of Interviews Man overwhelmed by many tasks # Types of Interviews This section contains the most common types of interviews you'll come across when finding a software engineering job. Each interview type will be discussed in much more detail in subsequent sections of this handbook. ## Behavioral interviews 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. ::: info BEHAVIORAL INTERVIEW EXAMPLE QUESTION Tell me about a time you had a conflict with a team member and how you handled it? ::: ## Values interviews 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](https://about.google/philosophy/), 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. ::: info VALUES INTERVIEW EXAMPLE QUESTION At our company, one of our core values is "team above individual." How have you exemplified this value? ::: ## Leetcode-style interviews Leetcode-style interviews are probably the most famous, or should I say infamous, type of interview. [Leetcode is a website](https://leetcode.com/) 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. ::: info LEETCODE-STYLE INTERVIEW EXAMPLE QUESTION Write an algorithm that takes an array of numbers as an argument and returns the same array. If an element in the array is a multiple of three, the output value should be `"fizz"`. If an element in the array is a multiple of five, the output value should be `"buzz"`. If an element in the array is a multiple of both three and five, the output value should be `"fizzbuzz"`. **Example:** _Input:_ [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15] _Output:_ [1, 2, "fizz", 4, "buzz", "fizz", 7, 8, "fizz", "buzz", 11, "fizz", 13, 14, "fizzbuzz"] ::: ## Practical coding interviews Practical coding interviews involve collaborative coding to solve a job-related problem. This is one of my favorite interview types because, unlike Leetcode-style interviews, it focuses on the kind of work you might do on a day-to-day basis. For example, if you're a front-end engineer, your coding challenge might be to write HTML, CSS, and JavaScript to a specification. In these interviews, it's extremely important to fully understand the requirements and the level of interaction/collaboration the interviewer expects. ::: info PRACTICAL CODING INTERVIEW EXAMPLE QUESTION Let's write the HTML, CSS, and JavaScript for a website that will fetch and display a Github user's profile information. ::: ## System design interviews 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. ::: info SYSTEM DESIGN INTERVIEW EXAMPLE QUESTION How would you design a real-time, web-based chat application? ::: ## Technical knowledge/trivia interviews 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. ::: info TECHNICAL KNOWLEDGE EXAMPLE QUESTION Tell me about some measures you might implement to make sure your web application is secure. ::: ## Combined interviews Many companies, especially smaller ones, combine multiple of the above interview types into each interview. In some cases, it's because they prefer each interviewer see all sides of a candidate. In other cases, there just aren't enough interview sessions to have distinct interviews. ## What interviews should I prep? That's a lot of interview types! The interviews you should prep for depend a lot on the types of companies to which you're applying. Realistically, the only type of interview you don't need to prep is the leetcode-style interview _if_ you know the companies at which you're interviewing don't do leetcode interviews. If you want to know what types of questions certain companies ask, I recommend the following: - Look at the company's interview section on [Glassdoor](https://glassdoor.com/). - If you're preparing for an interview at a specific company, ask your recruiter. In pretty much every case, my recruiters have told me the exact types of interviews I'll be undergoing. You'll notice the latter point as a theme throughout this handbook: ask the recruiter. They're an incredible source of information at a company and they want you to succeed. Treat them well! --- ### Values Light bulb # Values Interviews ## What are values interviews? Values interviews are similar to, but not to be confused with, behavioral interviews. It's tempting to conflate the two, especially if they're being conducted in the same interview session. Many companies have core values that they list publicly. For example, Google has its [Ten things we know to be true](https://about.google/philosophy/). If a company at which you're interviewing has core values, you should expect to be evaluated against them. Therefore, it makes sense to prepare for them. ## How to prepare for values interviews You can only really prepare for values interviews when you know the companies to which you're applying. My recommendation is to prepare the values part shortly before the interview (sometime within the week before). The good news, in my opinion, is preparing for values interviews is relatively easy. ### Build off your behavioral interview prep You will have likely done your behavioral interview prep already. I recommend reviewing your behavioral prep and tailoring your stories a bit to fit the company values. Don't lie, of course, but just make sure to explicitly mention the company's values. For example, one of my experiences involved improving tooling to enable a project to accomplish true continuous deployment. If I was applying to a company that had a value like "Fail faster and iterate," then I'd make sure to mention that value _by name_ in my continuous delivery story. ### Write down or print out the company's core values Having the company's core values in front of you will help jog your memory. Interviewers won't mind that you have the core values printed out. If anything, it shows you did some research and are serious about the company. ### Reference core values as a reason you applied (if that's true) I'm guessing you agree with a number of core values that any company you apply to has. It's fairly common for companies to to ask "why do you want to work at this company?" That's a _perfect_ opportunity to mention the core values with which you align! --- ### Where Should I Interview Map with X marked on it # Where Should I Interview? ## It depends Where you should interview depends a lot on your personal preferences. Are you intent the "prestige" of a FAANG (Facebook, Apple, Amazon, Netflix, Google) company? Or big tech? Or do you explicitly _not_ want to be in a big tech company? Do you want to avoid doing Leetcode-style interviews? ## Interviewing with big tech FAANG and big tech have pros and cons. One advantage of gaining employment with one of these companies is having "Google" or "Apple" on your résumé opens a lot of doors—your response rate for job applications will increase greatly. Of course, big tech has its cons. These companies are large and you may not have a chance to make the size impact that you could at a smaller company or startup. Additionally, you may not enjoy the bureaucracy. With respect to interviewing, FAANG and big tech companies tend to do Leetcode-style interviews. If you don't want to do Leetcode, you should look elsewhere. ## Making an informed decision If you're considering a company, [Glassdoor](https://www.glassdoor.com/) is your friend! Use it to look up ratings and interview processes at a potential employer. If you're interested in what salary you might make at a company, use [levels.fyi](https://levels.fyi). It crowd-sources salary information from company employees. ## If you're on the fence, apply If you're ever on the fence about applying or interviewing somewhere, my advice is to go for it! Worse case, you get some great practice. Best case, you get an offer and either accept it or use it as leverage against another offer. --- ### README # Interview Guide Welcome to my [interview guide](https://interviewguide.dev)! My name is Nick and I'm a senior software engineer. I have participated in around 100 software engineering interviews on both sides of the table—as a candidate and an interviewer. I have passed interviews at both big tech and FAANG companies as well as smaller startups. This guide is my attempt to codify my opinionated interview process for the benefit of the software development community. ## Support this guide You can support this guide in a few ways: 1. ⭐️ star the repo 2. share it with anyone who might be interested 3. [pay what you want for the guide](https://buy.stripe.com/4gM9AUfsj6xt6Es53y4c800) ## View the guide To view the guide online, navigate to [https://interviewguide.dev](https://interviewguide.dev). ---