The last post you'll need for SWE interviews!

Why would you believe what i say? Because I am an International student, no prior workex, graduated from 70ish ranked CS school last year - currently at AWS.

Why am I writing this? Because I have received at least 50 DMs asking questions which should have been common knowledge.

This post will be lengthy and cover all aspects (at least all that I can think of) so feel free to jump to relevant sections. Everything in here is aimed at FAANG+ companies or companies that have similar interviewing structure.

For each section, I will outline how to prepare and how to attack interview questions.

1. Resume

Nobody (including your interviewers) is reading your resume. All they will look at is the school you attended, when you graduated, and the name of the company + roles you have previously worked at. But that doesn't mean the rest of the content is not important, it is important for the filters and ranking algorithms they have. The best way to move forward here is to get a list of 10-20 job descriptions of the roles and companies you are trying to get in, and identify the most repeating keywords/phrases. Grab a bunch of resumes from linkedin by searching "google software engineer resume linkedin" or "<company\_name> <role\_name> resume linkedin". Then take inspiration from what all content you see in those resumes, the way they write about their past experiences, what all keywords you see in those resumes, etc. This is an iterative process, you have to keep on doing this for 8-10 time, and doing this once a week is what I'll suggest as this will give you enough time to know what works and what does not. Use free tools like Resume Worded (not sponsored) to get a hang of when to stop refining it. Prepare at least 5-6 resume which have the same content but DIFFERENT LOCATION. For example if you are in NY and applying for AMAZON, use the resume that has Seattle, WA in it, Santa Clara if applying to Google, etc.

Common pitfalls: Usually people create a very generic resume aiming at 2/3/4 different roles. For example, if you are aiming at MLE/SWE/DS/DE etc and adding all sorts of different experiences in one single resume, then that is a recipe for disaster. You need separate resumes and in each of those resumes, you need to mold the job title to suit the target role. Finally, do not add random numbers or metrics in each and every bullet point, they are as useless as those Environment/Sustainability classes in CS degree.

How to tackle resume related questions:

You wont be asked about any of your projects or any technology you on your resume in FAANG+ SWE interviews. If you have worked on a very cool project that you think might impress the interviewer, bring it up in some way when you are introducing yourself. For example, I built a full fledged product that had users using it and I wanted to bring that up. So during my intro, I said "I like to keep an eye out for problems and like to build solutions to those problems", and I kid you not, all the interviewers fell for it and asked me what all problems have I solved in the past. I had a couple of very strong projects/products under my belt. Initiative, looking out for problems, looking for inefficiencies, building something that actually improves lives of people etc are the phrases you should use in the introduction. The interviewers are looking to have a conversation and not interested in listening to the same old pre-recorded tape-like introduction.

1. Behavioral

First and foremost step is to create a doc and write down, in one or two lines, all major events/incedents of your life from college. Examples can be all university projects, course group projects, all internship projects, all the times when you worked in a team, etc. Then, sit down and expand on each and every point, add as many details as you can. Finally, give each story a 3-4 word title (more on this later)

Follow Amazon leadership principles for behavioral prep as they give a very solid structure to follow. No matter what company you target, the core principles will always be the same. I used this document to prepare for behavioral interviews and these questions gave me enough confidence to tackle any curve balls that might get thrown during the interview. The core principles that you should focus on are ownership, insist on highest standards, learn and be curios, bias for action, deliver results, dive deep, earn trust, think big, have backbone - disagree and commit.

How to tackle questions:

Categorize each of your stories in to 1 or two of these buckets (the above principles). Write down the 3-4 word titles on a sticky note, make sure to group the titles based on the bucket as well, stick them around the sides of the screen if needed. During the interviews, you are more likely to be asked a negative question, something like "tell me about a time when you got negative feedback or you broke something", do not say something really stupid here, this is whare you highlight the challenges you faced and how you overcame those challenges. You should know exactly what story you are going to talk about even before the interviewer finishes the question, do not take more than 5-7 MISSISSIPPI to start answering, if you need more time then ask the interviewer to clarify or repeat the question and buy more time. The answers should ALWAYS follow STAR format, however the followups should be answered in only AR format. In STAR, your responses should be heavy on Action and Result (atleast 70-80% of the time should be on these two). Usually there is no ideal length of the answers, I usually speak for 4-10 minutes depending on the question and the story. You don't have to worry about this if you have the right story to talk about, otherwise, just talk slowly.

Do not repeat the story! Not even to different interviewer! So plan out your stories and questions very well in advance.

Expect follow ups! Roughly 2-4 follow ups for each question and roughly 1-2 questions per round so for 1 hr round expect 2 or 3 questions with 2-4 follow ups as a rule of thumb. There's really nothing special about these follow ups, they will just explore a section of your story in depth so make sure you know your stores really really well.

Footnote: During this round, interviewers usually look unresponsive or disinterested, do not worry because they are taking detailed notes of the interview so do not let this affect your spirits. If they question your actions or responses, again expect that and there is nothing to worry here as they are testing the depth of the story and whether you are making it all up. These are very normal and usually you figure it out after a few interviews but in this market getting "few" interviews is difficult.

1. DSA/LC prep

Preparation - There are two steps here, 0 to 1 where you focus on building concepts and a narrow sections of LC problems, and 1 to 100 where you grind blindly like monkeys. People usually skip to the 1-100 step without going through 0-1 and fall flat on their face during interviews when an unknown question is thrown at them. And even if you solve the question and still get rejected, then it boils down to how you solve the question rather than the result (covered in next section).

0-1: Follow just one source, I only used Blind75. Focus on the concept before jumping on to the problems because if you dont understand dfs bfs or preorder postorder etc, you will struggle in graph and tree problems. Same goes for other concepts like sliding window, stack operations, bit manipulation, etc. I used NC pro for the concepts (NOT SPONSORED) but if you dont want to pay then use the structure of the courses he has. Use the video titles and search them on YT and watch a couple of videos, that should be enough. The two courses I used are this and this, use the titles and that should give you enough exhaustive coverage of the concepts. This along with the Blind75 will help you to build a very solid base and at this point I believe you should be prepared enough to handle interviews (most people don't have enough time to prepare before the interviews so doing this gives you the best bang for your time, however more practice will always help build that infallible confidence)

1-100: This is where you unleash your inner monkey and grind like a maniac (if you have time). Again, structure is extremely important here, so pick up one source, like Striver's SDE sheet or NC 150 or NC 150 or NC 250 or company specific problems on leetcode. Make sure you follow one source for learning and only use these sources for practice problems. What I mean is sometimes different tutors have different coding style or semantics and it is important for your brain to stick to one style.

How to attack the interviews:

Before diving into how to attack the interview, it is important to understand what you are being evaluated on. The evaluation criteria is:

1. Problem solving : Your ability to think and navigate unknowns falls under this. Solving the problem or coming up with an approach will usually get full marks here.

2. Edge cases: You have to identify all the edge cases and explicitly clarify any ambiguous ones. A lot of times your approach fails because at a later stage you realize you did not consider the edge cases. If you are able to think of all the "breaking" edge cases, it will get you full marks here. This is equally important as the 1st one.

3. Clean code: Right variable names, using final in declaration, using names that clearly explain the purpose of the variables and functions, adding appropriate comments, following language specific conventions (like java has camelCase and python has snake_case) etc. At big tech, they give HUGE importance to code readability and extensibility making this a very important criteria.

4. Communication: Think out loud! You must have heard about it a lot and if you are not sure what it means then here you go. Thinking out loud is just yapping about any and all thought that arise in your head. I usually do this when reading the question: "Okay so the problem requires me to traverse a graph so what type of traversal would be ideal? BFS or DFS? It seems unclear on which one to use at this point. What all variables should I be tracking? Ah now I see using a DFS approach would land me into XYZ complications. Let me check out the BFS based solution. Perfect, seems like BFS would be better suited,.... bla bla bla". Time to time, make sure that your interviewer is on the same page, ask him after few minutes "are you able to follow along?"

Your code WILL NOT BE EXECUTED, you will be writing your code in a doc like environment without any autocomplete or suggestions or text highlighting or syntax checkers. Initially the doc will be completely empty, no function signature, nothing on it. Now, this doc is extremely important because usually they use only one doc for all of your interviews so whatever you write on this doc, it will be reviewed during the round table that will make the final decision. So make sure you type out as much as you can on this doc.

The interviewer will post the question, usually 2-3 lines, in the doc. This question might be a little vague at times and it is your job to clarify it.

The flow of your actions should be:

First step should be to ask you interviewer for a couple of minutes to understand the question and then type out the following on your doc:

"""

1. Clarifying questions

2. Edge cases

3. Approach

4. Code

5. Dry run

6. TC and SC

"""
Explicitly explain the interviewer that these are the steps you will be taking to solve this problem. Next jump right into asking clarifying questions, like what do you mean by XYZ, what if the input is empty or what is the range of the input, etc.

Then explicitly state that you don't have any more clarifying questions and you'll jump on to defining the edge cases. Now one tip here is to keep all the edge cases and test cases as short/small as possible as you will need to dry run and you dont want to spend 5 minutes doing that.

Take your time in thinking all the edge cases possible, think out loud while you do that. Jot down the edge cases and explicitly tell the interviewer this what you can think of right now and will add to it if needed as you progress through solving the problem. Of course you need a regular case as well. Rule of thumb is one regular test case and one or two edge cases depending on the problem. Try to club edge cases together if possible, this will save some time during dry run.

Next ask minutes to think about the approach. Think out loud, type the approach in natural language, just plain simple lines like build an adjacency list for the graph, perform a bfs over the graph and store the number of surrounding islands, etc.

Walk your interviewer through this approach and if he agrees and everything goes well, let him know that you'd like to jump in and code it out. Do not forget they are testing you on the code quality (readability, extensibility and maintainability) so keep the tips in 3.Clean Code section above.

Once you have coded the solution, check it before letting the interviewer know, don't rush as it is likely you might miss something small and if the interviewer is not friendly then you might lose points. Make sure to think out loud while coding!

Finally, dry run one or two test cases and walk your interviewer through the process. Keep track of a few state variables, like visited set in bfs/dfs, left and right indexes in sliding window etc. Type out these variables each in a new line below the test case you are dry running, keep a pointer or variable to indicate whatever you are currently processing so that you don't mix things up.

1. LLD/OOP

Preparation: Basic videos on YT to cover these concepts and then again use NeetCode's playlist titles to get practice problems and again look them up on YT or ask ChatGPT for help.

Attacking the interview: This is exactly the same as DSA rounds with just one change. In this round, their focus is solely on code maintainability, extensibility, and readability so pay extra attention to code quality. Use TDD in this round, start first with how you would simulate the problem. For example, if you are asked to code a pizza shop, then think about how the entire thing will start and how will it end. Here, it might start with a pizza shop factory or a pizza shop builder class initialization. Then creating/building the pizza shop that serves a set of pizzas, then initializing the pizza factories + builder classes that would build custom pizzas etc. This is not exactly the same as TDD but you get the idea what is happening. This will help you clarify the relationships between different components and classes very easily.

Rest, follow the same 6 step approach as above except you don't really need TC/SC but if problem requires that then you should point it out.

1. System Design: Never prepared or experienced this firsthand so can't say much about this.

Remember, there is a huge luck factor involved. Usually FAANG+ have these recruiting pipelines where there are a lot of candidates in it at any given time. Due to many reasons, they can close the pipeline and everyone gets booted, including the ones who recently interviewed. This is the case where everything goes well but you just got a little late to the party. All the best!