10 steps for answering interview questions I used to land FAANG interviews

Similar to the STAR model (Situation, Task, Action, Result) — a technique to respond to a question in an interview- this guide is used to answer a coding question in a technical interview.

It is vitally important to strictly follow a set of guidelines to answer an interview question because we tend to be so anxious that we forget all the things we want to say during an interview. In particular, we may speak somewhat aimlessly, wandering from one idea to another.

More than that, an interviewer has at least 3 criteria to evaluate a candidate in a technical (coding) interview

• Problem Solving skills.
• Communication skills.
• Coding skills.

These criteria are all equally important to your interview result. However, if your communication skills are not good, the interviewer might not understand correctly your proposed approach. This might lead to the interviewer underestimating your two other skills …

Therefore, I have prepared a guide in great detail. I used it and got jobs. Now it’s your turn!✌️

1. Clarify the problem

When the interviewer reads the problem to you, I recommend you write or type down what you heard to make sure you understood it correctly.

After understanding the given problem, immediately clarify it by asking some related questions. This is because not all the problems are clear (it does not mean they are confusing or tricky), and you might miss some implicit information. Here are some questions I often ask to clarify:

• Can the array be empty?
• Are there any negative numbers in the input array?
• Do I need to handle duplicates (or whitespace, or case-sensitive)?
• Are there any cycles in the graph?
• Are there any zero leading numbers?

Asking questions also proves to your interviewer that you are a thorough person.

However, do not spend too much time on this step (should spend about 5 minutes) because this is the first one of ten steps.

2. Ask for a test case and create more test cases

If the interviewer gives you a problem without a test case (example input and output), you absolutely can ask for one.

After they give you a test case (or if they’ve already given you one), I recommend you brainstorm and provide more test cases (especially corner cases) to make sure your understanding is correct.

3. Offer a naive solution:

In this step, I always come up with a naive solution in only 1 minute. So How can you get a solution in such a short space of time?

• Tell them the first solution which comes into your mind: it can be a backtracking solution or a solution which uses three or even four nested loops,… just focus on getting it done.
• While practicing, try to come up with several naive solutions in only one minute instead of figuring out an optimal solution in more than 5 minutes.

Don’t forget analyzing the time and space complexity of this naive solution.

Why do we need to find a naive solution when it is not what the interviewer expects?

• To avoid keeping silent for a long time (more than 2 minutes) in the interview.
• The interviewer does not expect to see the optimal solution., Tthey expect to see your thinking process. Offering a solution quickly is a way to show your logical thinking, even if in the end, you can not find an optimal solution (by yourself).
• Moreover, coming up with a naïve solution first lays a concrete foundation for an optimal solution. We can develop the solution from the naive one with some interviewers’ hints.

4. Find a better solution

Obviously, the likelihood of the naive solution being optimal is extremely slim. In this step, we will try to find out a better approach (NOT necessarily the best one, though).

It would be wrong to assume that you can pass the interview by simply offering an optimal solution, and vice versa. The interviewer values your thinking process more than your final solution. I explained in this article.

So the question now is How to find a better solution? Practice makes perfect. The only way you can best perform in this step is having good preparation such as having a solid algorithm background and practicing with many algorithmic problems beforehand.

If after 5 minutes you can not come up with a better solution , do not hesitate to ask the interviewer for a hint when you’re stuck. Doing so is perfectly acceptable. If the interviewer gives you a hint, take it and develop your idea based on it.

On top of that, do not forget to discuss with your interviewer about what you are thinking about. First, if you discuss with the interviewer and explain your thought process out loud, they can navigate you towards a much better route, especially when they notice that you are heading to an impending dead end. Second, it is one way to show your communication and collaboration skills.

5. Double check your approach before jumping into coding

Many candidates start coding as soon as they have a solution. This is a common mistake. You should double check your approach with the provided test cases in the second step 👆.

6. Analyze the time and space complexity

This is a crucial step but most people often forget to do it. I explained how important this is in the previous article.

7. Summarize your solution

In the interview, I always try to interact with the interviewer as much as I can. I do not mean that you have to talk too much, but rather that you should communicate with the interviewer to make sure two of you can understand each other. Consequently, they can follow your code easier. More than that, summarizing your solution also helps you implement it faster with less bugs.

8. Start coding

When implementing, I often define a function first: “To solve this problem, we need a function with 2 params and will return an integer.” Type and speak out loud at the same time.

And then I will implement the body of that function.

Try to code and explain at the same time: in other words, you don’t need to stop coding to explain what you are doing, as this will ultimately waste time. At the very least you should describe the fundamentals of loops, variables, built-in functions, formulas, etc.,…

Another thing you should keep in mind is that some people feel terrible when forgetting a syntax. It is natural even for the best programmers to forget a function or syntax they have been not using for a quite long time. If you are not really sure with the syntax you are about to implement, do not hesitate to ask the interviewer to confirm. It is better than just letting it go and writing a wrong syntax.

9. Double check your code

Once you finish your code, double check it line by line if you still have time, preferably out loud and with one or two sample test cases. So by testing your code and demonstrating that you are careful, you’re really showing them that they’re not going to have to worry about you if they hire you.

Another thing you should check is the time and space complexity. At times, you may inadvertently leave some nits in your code that make the time or space complexity higher than you expected (this happens often when you use built-in functions).

Lastly, you should check whether you can clean your code such as removing redundant variables, merging 2 loops, etc…

10. Discuss the interview question further

It is not an absolute necessity, but if you do still have time, you can discuss other potential solutions such as one which costs less time but more space.

Good luck to all of you~!!