How to Stay Calm When You Get Stuck in a Coding Interview

When you hit a wall in a coding interview, stop trying to find the optimal solution immediately and start talking through a brute force approach. Silence is your enemy, but a slow, logical explanation of a naive solution is a bridge to the answer. You do not need to be a genius; you just need to be a communicator who can break down a problem.

Talk through the brute force

The interviewer wants to see how you think, not just if you can recall a specific algorithm. If you are stuck on a problem like finding the longest palindromic substring, do not stare at the screen in silence. Start by explaining the simplest way to solve it. Say, "I could check every possible substring, which would take O(n^3) time." Even if the optimal solution is O(n), the interviewer now knows you understand the constraints and the basic logic. They might even nudge you toward the O(n^2) approach once they see you have a working, albeit slow, baseline.

Use a smaller example

When the logic feels abstract, pull it down to earth with a concrete input. If you are working on a problem involving a large array, write out an array with only three or four elements on your scratchpad. Take the input [1, 3, 2, 5] and trace your logic step by step. If you are trying to find the maximum sum subarray, manually calculate the sum for [1], then [1, 3], then [3, 2]. Seeing the numbers change as you iterate helps you spot the pattern that leads to the Kadane's algorithm logic. Small inputs remove the complexity of the data and leave only the mechanics of the problem.

Ask for a hint the right way

Asking for a hint does not mean you failed. It means you are treating the interview as a collaboration. Frame your request by showing what you have already ruled out. Instead of saying "I don't know," say, "I have considered using a hash map to store the frequencies, but I am struggling to handle the edge case where the count is zero. Is there a specific property of the input I should be focusing on?" This shows you have done the heavy lifting and are now stuck on a specific technical hurdle. It keeps the momentum moving forward.

Keep your cool

Panic happens when you try to solve the entire problem in your head before writing a single line of code. Break the problem into three distinct phases: the brute force, the optimization, and the edge cases. If you get stuck, go back to the previous phase. If you cannot optimize, write the brute force code first. It is better to have a working O(n^2) solution than a broken O(n) attempt.

The stuck-in-interview checklist

• State the brute force approach out loud immediately.
• Trace a small input like [1, 2, 3] on paper to find the pattern.
• Identify exactly which part of the logic is blocking you.
• Ask a specific question about that block, not a general request for help.
• Write the brute force code first to secure a baseline.

Practice these steps on DSA Tracker to build the habit of talking through your logic before you start coding. Pick one problem you find difficult today and force yourself to write out the brute force logic on paper before you even open your IDE.

Keep going with practice problems and the online compiler.

Further reading: Binary search trees on Wikipedia.