6 Steps Template to actually pass your next FAANG technical interview. Part 2 out of 6.
This is Part 2 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 Completixy and Space Complexity
5) Coding (no typos, variable names, code organization and etc.)
6) Dry run / Test code
And today we are going to dive into the details of step 2 — Ask questions about the problem.
As counterintuitive as it may sound, the best way to start the technical interview is by asking your interviewer the right questions.
Let me give you some of the reasons why:
1) There is literally a checkbox on your interviewer evaluation sheet that reads — “Problem understanding”
2) The problem prompt/description is specially designed the way that there are things that are open for interpretation
3) More often than not, there would be some edge cases that would need to be handled in a special manner
Let’s go over each of the reasons.
1.
There is an evaluation sheet with checkboxes in front of your interviewer during the interview. I hope no one is surprised by this fact (I am planning to do a separate post on those checkboxes, please subscribe to get notified when it’s out). At this stage of your interview, your goal is to get your interviewer to check that box. In other words, your goal as an interviewee is to demonstrate to your interviewer that you have understood the problem. The best way to convey that information is by paraphrasing the problem description in your own words.
By the way, it is a psychological trick as well. Separate the problem from the interviewer, and by doing so, you mentally put the problem on one end of the table and put yourself and the interviewer on the opposite side. Literally, try to imagine that. So now, you and the interviewer can work as one team on this problem.
Do you see how it works? Before it was the interviewer asking you a question, but now you paraphrased the question and can say something along the lines of — “Ok, so let’s see how WE can solve this problem”. Again by phrasing the problem in your own words, you communicate to the interviewer you have clearly understood the problem. And now it would be a good time to come up with some example inputs and expected outputs because remember the interview is probably not happening in the LeetCode and you might not be given example inputs. By coming up with your input and output you furthermore reiterate that you understood the problem and are ready to solve it. Those test inputs and outputs come in handy at the end of the interview to dry run/test your code (step 6 of the template).
2.
The second reason why it is crucial to start by asking questions is the fact that the interview prompt is designed specifically in a way that some details are open for interpretation. This way the interview mimics real-world situations and tests your ability to identify those gaps and your ability to properly handle them. We do not live in a perfect world and almost always have to deal with situations where we have to make decisions based on incomplete information. Your job as a successful candidate is to ask the right questions, collect crucial missing information and communicate assumptions and guesses you make to solve the problem in the time-constrained framework. At the end of the article, I have a list of possible questions one can incorporate depending on the specifics of the problem being asked. What you do not want to do is end up making false assumptions, construct your solution based on them and leave your interviewer guessing where you went wrong. That is immediately a red flag for your interviewer.
3.
The third part, the last but not the least reason why you should start your interview by asking questions is that it allows you to take a moment and think of the edge cases for your specific problem. It both demonstrates your problem understanding and shows your seniority level. You want to construct a robust solution that solves the problem in general cases and rear/special cases that tend to come up in the real world all the time.
Here is the list of some common questions to get you in a habit of starting your interview by asking the right questions. Please use this list mindfully, as it is not designed to be comprehensive nor fit your specific question.
- Is the input an array of integers/doubles/characters/strings etc?
- Is the input sorted, in ascending/descending order by start time/end time?
- What should the output be if the input is empty, nil/null?
- Will the answer fit in the Integer?
- Is the string only English letters, uppercase/lowercase?
- Can the numbers be negative/positive/zero?
- Can we assume this property of the Node is unique for every single Node object?
- What does it mean for the 2 intervals to overlap? ([1,2] and [2,4]) are these 2 intervals considered overlapping?
There are 2 additional side notes I would like to briefly touch on.
Do not ask obvious questions. An obvious question would be considered a question the answer to which is already provided in the question prompt. For example, if the problem description reads: “Given an array of positive integers from 0 to 1000, …”. Obvious questions are: “Can we assume the number in the input array are integers/positive/less than 1000?”. It just wastes your time without giving you any additional information and your interviewer might think you cant read or otherwise have a really short attention span.
Why jumping straight to the problem without asking questions might backfire on you? Chances are, you, as a strong candidate, have spent some time (and by some time, I mean a lot of time) solving coding problems on LeetCode. Hence you probably are exposed to quite some variety of problems and you will probably see something slightly similar or what might first look like the same problem during your actual interview. Even then, resist the urge to jump straight into the solution. As the problem asked by the interviewer might be a small variation of the problem you have solved or the approach you have used before might have depended on some constraints that were given to you in LeetCode and are not given to you by the interviewer. In both scenarios, it can be held against you, for either making false assumptions or not communicating your assumptions with the interviewer. Instead, take a deep breath and start by clarifying the question and winning the interviewer to your side of the table.
That is all for part 2. If you have not read part 1 of this article where I talk about the importance of practicing writing the code in Google document, here is the link for you. Otherwise, thank you for your attention and if you like the content please take the time and give it a like and subscribe to be notified about future publications:
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):
