虎头锤
← All writing

Interviews

The Truth About Algorithm Interviews: You Didn't Write It Wrong, You Just Didn't Say It Right

5 MIN READPortrait of Hutouchui虎头锤 (Hutouchui) · Staff Engineer

Translated from the original Chinese essay · Read the Chinese original →

After a mock interview, my friend's face was stiff.

He said he had clearly written the correct code and even finished the problem early, so why did the interviewer just nod expressionlessly and say, "OK, move on."

I asked if he had explained his thought process. He said no. He thought that since the code was written, why would he need to explain it?

I asked again: "Before you wrote it, did you say how you were going to do it?" He said no. He thought the interviewer could understand the code.

"Why did you write it this way in the middle? Did you consider other approaches?" — "I thought about it myself, but I didn't say it out loud."

This back-and-forth is the real reason many people fail algorithm interviews, including myself.

We think algorithm interviews are about solving problems. But in fact, they are not testing whether you can produce an answer, but whether you are the kind of person who can steadily push a problem forward.

Interviewers Are Not Judge Systems, They Are More Like Future Colleagues

Writing correct code is a basic skill; being able to make the other person believe you can independently solve unknown problems is what sets you apart.

Algorithm problems are just a vehicle. What is really being evaluated is: How do you understand the requirements? How do you derive a solution? Do you clarify boundary conditions? When things don't go as expected, can you self-correct?

The person sitting there is not calculating your score, but deciding one thing: "If a problem comes up in a project later, can I trust you to be pulled in to figure it out together?"

The Most Important Expression Is Not "I Did It", But "How I Thought About It"

Take a classic problem: "Find the longest substring without repeating characters in a string."

Many people jump right in: two pointers, a hash table, O(n) time complexity, all in one go.

But if you say nothing, the interviewer only sees a piece of code that runs.

If you take a different approach:

"Let me confirm first: this problem asks for the length of the longest contiguous substring without duplicate characters, right? I plan to use a sliding window. Each time I add a character on the right, if a duplicate appears, I move the left pointer until that character is removed. I'll use a HashSet to record the characters in the window, and the time complexity is O(n). Let me start writing."

Even if you later make a few boundary errors, the interviewer will know: you are thinking, you have a methodology, and you are not writing by feel.

That is completely different from just "getting it right."

Think Out Loud Is Not "Showing Off", It's "Communication Skills"

Thinking out loud is the first principle of algorithm interviews.

But many people misunderstand this principle.

It doesn't mean narrating every line of code as you write it, but letting the other person know what is going on in your head.

You don't need to appear smart in an interview, but you need to let others see that you are thinking.

Especially when you get stuck on a hard problem, simply saying: "I'll start with a brute force approach to make sure I understand it correctly, then try to optimize." That sentence itself is engineering thinking.

You can make mistakes, but you cannot stay silent the whole time.

You can leave the problem unfinished, but you cannot leave people completely unable to understand your judgment logic.

Explaining the reasoning process clearly in an algorithm interview

Being Able to Write Code Doesn't Mean Being Reliable; Being Reliable Means Being Able to Explain What You Are Doing

I have seen candidates whose code was fine and whose thinking was correct, but they ended up with a Weak No Hire.

The reason was not technical ability, but either they didn't clarify the problem in advance, or they didn't explain the reasons behind their choices, or they didn't signal that they could identify risks and judge tradeoffs.

Saying: "I also considered this approach, but I felt the space complexity was a bit high, so I switched to this structure" carries far more weight than quietly changing a line of code.

Writing it out shows you have the ability; explaining it shows others dare to work with you.

AI Tools Are Not for Writing Answers, But for Helping Us Practice How to Speak

Now when I use AI to practice algorithm problems, it's no longer to come up with new solutions, but to practice how to explain and reason.

I throw my written code to AI and ask it to challenge me from an interviewer's perspective:

  • Have you considered other approaches for this method?

  • Are there performance bottlenecks? How do you judge?

  • If there's a bug, where would you start debugging?

At this point, AI becomes my sparring partner for practicing "speaking."

Not everything is useful, but these processes make me realize:

What I say is not a template, not a trick, but "something I have truly understood myself."

An Interview Is Not a Process of Defeating the Problem, But a Process of Making Others Believe You Can Face the Problem

Many people think algorithm interviews are too mechanical and rigid, but in fact, they test an ability we truly use in daily work:

  • Do you have a clear thinking path?

  • Can you advance a plan under uncertainty?

  • Can you explain complex judgments clearly and bring people along?

So, stop asking me whether I am not good at algorithms.

Ask yourself:

"Have I let others see how I think step by step?"

Finally, a Set of Practice Suggestions for You

  1. Every time you finish a problem, don't stop at "AC". Write out a solution process and explain it out loud.
  2. Let AI simulate an interviewer and challenge you with "boundary judgment", "complexity explanation", and "tradeoff analysis".
  3. Try to answer these questions:

  • If your code is wrong, can you find the bug yourself within 5 minutes?

  • When the interviewer doesn't ask questions, can you proactively explain your thinking path?

  • Have you tried to articulate the tradeoffs and the reasons for choosing your approach?

If you can't answer these three questions, it's not that you can't solve problems, but that you are not yet ready to express yourself.

But as long as you are willing to practice, every time you explain clearly, you get one step closer to being trusted.

Building interview trust by practising how to articulate your reasoning