5-Step Strategy You Can Use for Your Next Coding Interview

Unlike coding tests, where you solve algorithm problems with a keyboard silently, coding interviews go beyond keyboard communications.

It can be a daunting task, as the interviewer can see every move you make on a shared screen.

And if that wasn't nerve-racking enough, you also need to speak out, expressing your thought process to not only elicit some hints from the interviewer but also keep the conversation flowing.

That's why I was thrilled to see this algorithm design template when attending a coding practice hosted by Women Who Code San Diego:

After following each step in the template during several practices, I have developed a methodology to reduce awkward silence in my coding interviews.

Here's my consolidated 5-step strategy:

Step 1: Clarify the Problem

A lot of coding interviews involve writing out a function to solve the problem. Sometimes the interviewer might interpret the task differently.

To ensure you are both on the same page, you can start by confirming the goal of the problem, followed by the input you are given, and the output the interviewer expects to see.

Step 2: Brainstorm Examples

To further demonstrate that you understand the problem, you can also create some examples and confirm with the interviewer.

If you are still not sure about the problem or instruction, now is a good time to ask for a few test cases.

Step 3: Ask about Constraints

To cover all the bases, you can also brainstorm some invalid inputs, and ask the interviewers if those inputs should be taken into considerations.

Another follow-up question you can ask is time/space complexity, even if your initial approach will likely be brute-force.

Don't be afraid to ask questions. There were instances where, after my clarifying questions, the interviewer realized some key portions s/he neglected to mention and modified accordingly.

Step 4: Pseudocode Your Idea

Now that you've confirmed everything you can think of, it's time to start coding!

As part of my coding habits, I often start by pseudocoding or writing out my approach as comments (e.g. I will store these values as variables, this is where I will iterate over the array, and I will return the value here).

Step 5: Code, Talk, Optimize

Once you start pseudocoding, you will formulate a more concrete idea on your approach, which gives you the confidence to code out your solution.

This is where you can talk as you code, reading out loud the code you are typing. After finishing a code block, you can pause and ask the interviewer for feedback.

More often than not, after you have arrived at the right solution, the interviewer will ask if you can optimize your approach.

In case you can't think of any further optimization on the spot, it might be helpful to just start with a brute-force approach instead of rushing to the optimized solution in the beginning.

The strategy and the template above recently led to the best coding interview I have performed. I hope they will also help you construct your own way of acing your next coding interview.

Do you have any additional tips? What were the best and worst coding interviews you have experienced? Let me know in the comments!