6 Steps template to actually pass your next FAANG technical interview. Part 3 out of 6.
This is Part 3 of my series of 6 posts, where I go over the ultimate framework to pass your next technical interview for #FAANG / #MAANG / #BigTech for a Software Developer position (Because who wouldn’t want that right?).
Here are the 6 steps:
1) Practice in Google document settings
2) Ask questions about the problem (especially the input given)
3) Outline the approach (in notes)
4) Estimate Time Complexity and Space Complexity
5) Coding (no typos, variable names, code organization etc.)
6) Dry run / Test code
And today we are going to dive into the details of step 3 — Outline the approach (in notes).
There are at least 5 reasons why it will actually make your life much easier once you get into the habit of outlining and planning your solution before writing a single line of code:
1 First of all, it is just simply expected by your interviewer (anything else will be held against your candidacy for rather obvious reasons, some of which are stated below). Remember the goal of this kind of interview is to understand your thought process. It is definitely not to check if you have solved this or similar problems before. So you have to give your interviewer a clear picture, of how you approach solving such a problem, what is the intuition behind different approaches, and what are the tradeoffs of each approach. All of that can be achieved by communicating the decision-making process that goes through your head during the interview.
2 Communicating your approach to solve the problem will help your interviewer assess early on that the solution will be both correct and efficient (the level of efficiency matches the minimal expectations that your interviewer might have). It will only save you time in both scenarios. The interviewer will be able to navigate you to the correct path in case your solution is wrong and does not solve the problem in a general case, or in case you have made an assumption that had simplified the question (proposed the greedy solution for DP problem or assumed array contains only positive integers). The interviewer will be able to hint to you that there is a more optimal solution to the problem. By presenting the outline of the solution first, the interviewer might ask you the questions which, if incorporated correctly, should help you to come up with both correct and optimal solutions in a timely manner.
3 It will serve you as a great reference point to correctly estimate sometimes tricky time (TC) and space complexities (SC) analysis. As you outline your steps to get to the solution, it will be easy for you to correctly estimate the TC and SC each step separately and then arrive at the overall TC and SC. There are cases that involve some input manipulation, such that the input size shrinks (an example would be when you construct a data structure, probably a dictionary, to hold frequencies of elements of the given array, then you sort or search through the frequencies, the smaller subset of the initial input, hence the TC changes). It could affect the SC as well if you do not have to hold the entire input but some subset of it. So after you divide your approach into somewhat descriptive steps, you could just put TC of each step that would help you correctly estimate the time and space complexities of your overall solution. Having a solid plan would help you avoid those costly mistakes. That is a very structured and convincing way to correctly calculate TC and SC all those FAANG companies care so much about.
4 Outlining your approach will also help you structure your code as well as structure your overall coding process. With a well-organized and thought-through approach in place, there would be less jumping around the code and/or moving your code into/out of functions. There might be a discussion in between or some side questions from your interviewer, and when you actually start writing code you might forget where to begin from. A nice detailed outline will help you prevent forgetting things (sometimes we discuss how the input should be sorted by some property and then we could traverse it and so on and so forth, that by the time we get to implementation we might just assume it’s sorted already). Depending on the situation every step could serve as a separate function, for instance:
1) Fast and slow pointers to find a center of a linked list;
2) Disconnect the linked list in the center;
3) Reverse the 2nd linked list;
4) Merge 2 linked lists into 1.
Each step of the process can actually be split into functions and depending on how much time is left and your interviewer you could skip certain parts (black box). Please let me know if you would like to learn more about the black box technique, give me some love and subscribe to my YouTube channel, and comment on the content I share with you guys).
5 Finally, having the predefined structure before you start coding will make it easier for your interviewer to follow your code. There could be different reasons why your interviewer might get distracted and has to get back in sync with you while you are coding, but it will definitely be much easier with the agreed plan outline beforehand.
Those were my reasons for outlining the approach of the solution before writing a single line of code during your next technical interview. I will see you in the next post where we would discuss step #4 — Estimating time and space complexity. In the meantime, please like, comment, and share (in that particular order) this post if you found it helpful, and do not forget to subscribe to my YouTube channel (like the video, comment on them and maybe even share it with your network). Stay tuned.
To correctly set up a Google document for your interview check out this video.
To get a feeling someone would use this very framework in an actual interview setting take a look at this video:
Additional links:
GitHub (I commit my solutions in Swift to LeetCode problems):
Youtube channel (I post solutions to LeetCode problems and similar content useful to prepare for coding interview):
