How to Talk During the Coding Interview: A Step-by-Step Guide

During the technical coding interview, you’ve probably been told to “talk through your code” or to “think out loud”.

Talking gives you many advantages, namely:

It helps your interviewer understand your approach and your code
It allows your interviewer to correct your thought process
It demonstrates your communication skills

While I completely agree with this advice and its advantages, it’s sometimes difficult to know exactly what to say and how to say it.

In this article, I’ll go through, step-by-step, how you can approach the communication portion of the coding interview.

Disclaimer: this article is geared towards data structures interview questions.

Naturally, we’ll start at the beginning of the interview.

1. What to say after you read the question

I’ve seen many candidates rush to coding as soon as they read the problem.

There are a few issues with this.

Even if those candidates end up with the most optimal solution, the interviewer will think those candidates are hasty and lack communication skills, which are qualities that no engineer wants for his or her teammates.

After hearing the problem, take a deep breath.

Before even starting to figure out how to solve the problem, the first thing to do is to clarify the problem.

1. Clarify the Problem

This is a very important first step even if the problem seems simple enough.

You want to show the interviewer that you understand the task at hand.

You don’t know what you don’t know. You might even discover that you missed something in the problem statement.

A typical coding interview will involve completing a function (e.g. given some input, write a function that returns some output based on the input).

Without thinking about implementation, clarify with the interviewer what this function should do with real examples.

To clarify, suppose we’re given a datatype of value simple_input. We would want to return correct_answer. Is that correct?

A confirmation from the interviewer will let you know that you fully understand the intent and purpose of this function.

2. Identify the Scope of Data Types

Next, it helps to understand the scope of the inputs. You want to capture all possible inputs.

First, we’ll look at data types.

Are you dealing with arrays, integers, floating-point numbers, or all of the above?

The next thing you say doesn’t have to be a question per se, but rather a validation for yourself and the interviewer.

Sometimes the input data types are ambiguous. They usually aren’t, but it can be helpful to know what not to worry about.

If the function inputs a number or array of numbers, talk through how the implementation would change if the input were any of the following data types: int, float, string, boolean, anything else you can think of

If your function explicitly states that the inputs are integers, then you don’t need to worry about different data types.

This function will input only datatype, so I won’t need to account for any other data types.

3. Identify the Scope of Input Values

You may not always have to worry about data types, but you will always have to worry about your input values.

Negative inputs
Empty inputs (arrays with no numbers)
Duplicate inputs (repeated numbers in arrays)
Extreme inputs (very high or lower numbers)

These are what we call corner cases.

When you first see the problem, you won’t need to worry about the corner cases since you haven’t implemented anything yet.

But it is very helpful to let the interviewer know early on that you are thinking about this.

If you find that there are conditions you need to account for with these corner cases, then mention those in your next sentence.

It seems like I will have to account for empty and extreme inputs, but I’ll work on those corner cases after I implement this function.

It seems like I won’t have to account for empty and extreme inputs when I implement this function, which simplifies the problem quite a bit.

After you have clarified the purpose of the problem and defined the scope of the inputs, then you can start implementing the solution.

2. What to say before you start coding

The first step to implementation is not to write code, but rather to explain your high-level approach to your interviewer.

You could be thinking three things in this moment:

I know the most optimal solution
I can only think of a brute-force solution
I have no idea what’s going on

1. You have an optimal or naive solution

You may know the most optimal solution right off the bat. You might have the fastest possible way to solve this problem.

But you never know what you might be missing, so try not to skip this step.

In some cases, the brute-force solution (the naive solution) is the only solution you can think of. You want the interviewer to understand that you know this isn’t the most optimal solution.

In either case (optimal or brute force), start by saying:

My first instinct would be to high_level_solution.

If you have the optimal solution, the interviewer will be impressed that this is your first instinct.

If you have the brute-force solution or anything else, the interviewer will understand that you will keep improving on this implementation.

After describing the solution, be sure to explain the time and space complexity of your solution.

This would give me an O(f(n)) time complexity because reason. It would also give me an O(g(n)) space complexity because reason.

In the case of a brute-force solution, explain why this is a poor solution and what part of the problem can be improved. Sometimes your interviewer might drop hints and lead you toward the right path.

Try to end with:

But I know we can do better because reason.

2. You have no full solution

This is very common. The first thing to do here is not to worry. Your life does not depend on this interview. Everything will work out in the end, whether it means you get this job or find another one that you love.

Once all those thoughts are hammered into your head, I want you to start the same way as if you had a solution:

My first instinct would be to high_level_solution.

At some point, you’ll get stuck. You’ll keep explaining and won’t be able to explain anymore.

You’ll want to say:

I’m not entirely sure how to get from here to desired_solution.

Now if you have a good interviewer, they’ll drop some hints and guide you in the right direction.

If not, you’ll have to tough it out and keep thinking.

This is difficult. This is usually the hardest part of the interview. In general, look for repeated work and try to optimize them by potentially caching the calculated result somewhere. Reference it later, rather than computing it all over again. I provide some tips on tackling topic-specific questions in detail below.

Only start coding after you and your interviewer have agreed on an approach and you have been given the green light.

3. What to say after you start coding

At this point, you’ve defined the intention and purpose of this problem, defined the scope of the inputs, and briefly explained your high-level solution.

Even if you don’t have a full solution in your head, you should have some starting point by now.

I usually follow two rules of thumb when it comes to coding during technical interviews.

Rule 1: Talk or Code

My first rule of thumb is that, during the interview, you should always be either writing code or speaking.

Writing code in silence is okay and completely normal on the job, so it’s perfectly fine during the interview.

In fact, if you want to talk while you write (if it helps), then go right ahead.

But if you are not writing code, try to let the interviewer know what you’re thinking so you aren’t just staring at the whiteboard.

It will give the interviewer an opportunity to guide you in the right direction.

Don’t be afraid to let the interviewer provide hints. They don’t expect you to be perfect. They just want to understand how you process information.

Rule 2: Don’t Explain Everything

My second rule of thumb is that you don’t have to explain everything.

You don’t need to explain every single line of code you write in great detail.

It could actually hurt your interview especially if it slows down the entire interview process.

Learn to summarize your code.

First, explain the purpose of what you’re about to write in very general terms.

Then, describe how you’ll implement it.

Finally, write your code.

You can even summarize it once more afterward to remind the interviewer.

It’s important to remember that the interviewer knows the problem very well. The interviewer also probably knows the programming language very well, so describing everything in great detail may be excessive.

Conclusion

I hope you have a better idea of what you can say during the coding interview.

I don’t repeat the statements verbatim, but I do follow the general gist of this article. It’s become ingrained in my head at this point.

Good luck on your interviews, everyone! I wish you all the best of luck 🙂