Many candidates don’t get offers even when they know the optimal solution. The problem is rarely the solution itself. It’s how they communicate.

In an interview, your thinking matters just as much as your code. If you work through the problem silently and only present the final answer, the process behind it is lost. The interviewer misses how you approached the problem, how you handled trade-offs, and how you would work with others in a real setting.

The good news is that this is a skill you can build. You don’t need to be naturally talkative or polished. You just need a simple, consistent way to walk through your thought process so it becomes easy for someone else to follow along.

Imagine two candidates working through the same problem.

Candidate A reads the question, stays quiet for a few minutes, and then writes a correct O(n) solution. When asked, “why did you use a hash map?”, they reply, “because it’s faster.”

Candidate B takes a different approach. They start by saying, “we’re looking for pairs that sum to a target, so this feels like a complement problem.” They clarify a few edge cases, briefly walk through a brute-force idea, explain why it’s O(n²), and then naturally move to a hash map solution, explaining how it improves the time complexity to O(n).

Both candidates arrive at the same answer.

The difference is that Candidate B makes their thinking visible. You can follow their reasoning, see how they break down the problem, and understand why they made each decision. It feels less like watching someone type code and more like working through a problem with a teammate.

When you first hear the problem, it’s tempting to jump straight into coding. Pause for a moment.

Spend a minute or two asking a few thoughtful questions. It helps you avoid unnecessary mistakes, clears up ambiguity early, and gives you a clean starting point before you begin solving.

What to Ask

Example: Two Sum

Here’s how a strong candidate might begin:

In just a few sentences, they’ve clarified the problem, removed ambiguity, and set themselves up for a smoother solution. This usually takes under a minute.

Questions to Avoid

Avoid asking things that are already clearly mentioned in the problem. It makes it seem like you didn’t read it carefully.

Also avoid open-ended questions like “any hints?” before you’ve even tried to think through the problem. It’s better to take a moment, gather your thoughts, and then ask more focused questions if you get stuck.

This is one of the most important moments in the interview.

Before you write any code, take a few seconds to explain what you’re planning to do and why. It helps you organize your thoughts and makes the rest of the interview feel much smoother.

A Simple Structure That Works

A good approach explanation follows this pattern:

Example: Approach Explanation

That’s it. About 20 seconds.

In that short explanation, you’ve shown how you think, how you move from a basic idea to a better one, and that you have a clear plan before coding.

When the Interviewer Pushes Back

Sometimes the interviewer will say "can you think of another approach?" or "what about the space complexity?"

Don’t treat this as a signal that you’re wrong. It’s just the conversation going deeper.

Once you start coding, try not to go completely silent.

It’s natural to focus and get lost in the code, but long stretches of silence make it hard for someone else to follow what’s happening. A little bit of narration goes a long way in making your thinking visible.

The goal isn’t to explain every line. Just give enough context so that someone watching you can follow your decisions.

What to Narrate

What Not to Narrate

Don’t read your code line by line. “Now I’m declaring i, incrementing i…” doesn’t add value.

Also avoid filling every pause with “let me think…” repeatedly. Taking a short pause is completely fine. Over-explaining every second is not.

Finding the Right Balance

Think of it like this: mostly coding, with small bursts of explanation.

You write a few lines, then briefly explain what you just did or what you’re about to do next. It should feel natural, like you’re walking someone through your thinking, not giving a lecture.

You don’t need to talk constantly. But try not to disappear into silence for too long either.

Once your solution is working, the conversation usually doesn’t end there. This is where you can go a level deeper and show how you think beyond just “getting it to work.”

A common direction is to talk about trade-offs. Not as a formality, but as a way to explore how your solution behaves under different constraints.

Trade-Off Categories

How to Bring Up Trade-Offs Naturally

You don’t need to wait for someone to ask. Once you’ve confirmed your solution works, you can add:

This kind of reflection shows that you’re not just solving the problem, you’re thinking about how the solution behaves in different situations.

Getting stuck in an interview is completely normal. What matters is how you handle that moment.

The Wrong Way: Going Silent

When people get stuck, they often go quiet and try to figure everything out internally.

The problem is, from the outside, it’s hard to tell what’s going on. Are you close to the solution? Are you going in the wrong direction? Are you completely blocked?

After a minute or two of silence, it just feels like the conversation has stalled.

A Better Approach: Think Out Loud

When you hit a wall, just say what’s going through your mind.

For Example:

That alone makes a big difference. It shows the direction you’re thinking in, highlights exactly where you’re stuck, and keeps the conversation going.

Asking for Hints the Right Way

There’s a big difference between:

“I’m stuck, can you give me a hint?”

and

“I’m considering using a priority queue here, but since all edges have equal weight, I’m wondering if a regular queue would work just as well. Does that make sense?”

The second one shows you’ve already thought through the problem and just need a small nudge.

If this feels like a lot to keep in mind, don’t worry. You don’t need to remember everything. Just practice a simple flow like this until it becomes natural.