DEV Community

Cover image for Follow these steps to ace your next Coding Interview
Caleb Gucciardi
Caleb Gucciardi

Posted on

Follow these steps to ace your next Coding Interview

Hi 🙋‍♂️, over the past two years I have done a lot of interviews and I created a small template of steps to follow when trying to solve a coding problem.
This will help you focus during the interview because it provides a framework to apply whether the problem seems easy or scary/impossible.


Be a Detective

The first thing your interviewer is going to do is to give you the problem statement. You need to be a detective! Ask clarifying questions, ask about edge cases and write everything down (with comments for example).

The edge cases will help you in the coding phase; having everything written down is important so you don’t forget to take care of them!

Remember that to solve a problem first you need to understand the problem… before thinking about any solution be sure to be on the same track as your interviewer.

This phase is crucial also for another reason, often the problem statement reveals some keywords that need to resonate in you immediately. Do you want some examples?

  • The input is sorted
  • The output needs to be sorted
  • The input is a [list, graph, tree]
  • You need to implement a class to solve…
  • Find all the solutions so that…
  • Find the fewest steps to…
  • Find the Kth element in…
  • …

There are a finite number of triggers and any of these links to a specific data structure or algorithm to solve the problem. I’m planning to write an article only to address this topic.


Propose the Impossible

Now comes the fun part, you need to propose a solution.
We usually know how to solve any LeetCode-style problem, the hard part is finding the best solution.

Wait… you know how to solve the problem! 🥳
The so-called brute-force solutions are extremely important, they show your interviewer that you understood the problem and that you know how to solve it with a naive approach.

After I propose a brute-force solution I also provide the time/space complexity so that when I am about to give the optimal (or sub-optimal) solution, I can make the comparison.

Last but not least if you don’t find the optimal solution you at least have proposed something. The majority of interviewers are going to ask you to code the brute-force one to evaluate your coding skills.


Look for the Answer in every possible Universe

If you followed the previous steps you now have:

  1. comments with answers to clarifying questions and possible edge cases
  2. focus on specific keywords/triggers of the problem statement
  3. a brute force solution

What if you have no idea how to solve the problem?
Well if you have, propose it to the interviewer and if they seem happy move on to the next step.

If you are sweating because you don’t have any idea what to do,
here is the solution: “Start listing everything you know”

How many data structures do you know? list them all.
How many algorithms do you know? list them all.

Of course, it is important to sort the list according to its relevance to the current problem, if one of the triggers is “the input is sorted” that means that you should start with: binary search, merge, two pointers, etc…

When I say you need to list what you know, I mean you need to go from one data structure to another, from one algorithm to another, highlighting their strengths and advantages and how they might fit the problem.

Once you find the right fit you’ll see that everything match and that particular data structure (or algorithm) will open all the doors for the solution.

I usually try to involve the interviewer in this process as well. I talk to the interviewer as if he is already a colleague, I imagine that we are working together trying to solve the problem, I don’t see them as someone who wants to judge me, my attitude is relaxed because I am genuinely trying to find a solution.

Listing everything you know shows the interviewer that you are prepared and will be more willing to help you find the right path

Prepare a way and Take it

This is the last, easiest step… right?

I’ve done many mock interviews with friends of mine and often I see this pattern: “Ok I have a bare idea of the solution, I’ll start coding”

WRONG!
You have no idea how to code this solution, instead of coding right away you should make a plan of what to do, before writing code you should already have every line of code in your mind, do not improvise!

A way to do it is to write comments inside the solution function

# answers to clarifying questions
# 1. ....
# 2. ....

# possible edge cases
# 1. ....
# 2. ....

def solution(...):
  # first initialize what needed to solve the problem

  # start looping through the input
    # check condition X
    # update the answer
    # remember to exit if Y is true

  # return solution
Enter fullscreen mode Exit fullscreen mode

This is just an example, I find this step particularly helpful with recursive solutions, you need to plan carefully every move.

Once this is done, it is a matter of translating it into code and testing it. Always test it. You will find bugs. How many times have you written code that has no bugs on the first try?

Conclusion

I hope these steps may help you be more focused, relaxed and confident in your next interview. You may need some time to get used to each step but practice makes perfect.

If you found this article useful, please share it with your network, it will help me a lot, thank you. 🙌

Top comments (0)