Twenty minutes into the interview, you're still staring at the problem. You've said a few things. You've drawn a diagram. But you have no idea how to solve this.
Your heart races. You're sweating. The silence is deafening. The interviewer is waiting.
This is the moment that separates candidates who fail from candidates who recover.
Being stuck isn't the end of the interview. How you handle being stuck might be the most important signal you send. Strong candidates get stuck too—but they know how to unstuck themselves, communicate through uncertainty, and show collaborative problem-solving skills even when they don't have the answer.
This guide will teach you exactly what to do, what to say, and how to think when you're completely stuck in a live coding interview.
Here's what most candidates don't realize: interviewers expect you to get stuck.
They're not looking for people who instantly know the answer. They're looking for people who can:
If you knew every answer immediately, the interview would be meaningless. The interesting part—for the interviewer—is watching you think when you don't know.
When you're stuck, interviewers are observing:
Do you:
Or do you:
The first set of behaviors shows engineering maturity. The second shows interview inexperience.
When you hit a wall, follow this exact sequence.
The worst thing you can do is go silent and hope inspiration strikes.
Don't:
Do:
Say this exactly:
"I'm stuck on [specific part]. Let me verbalize where I am so far."
Then summarize:
"I understand we need to [restate problem]. I think the brute force approach would be [explain]. But I'm not sure how to optimize this part: [name the bottleneck]."
Why this works: You're showing self-awareness and structured thinking. You're stuck on a specific part, not lost completely.
If you have no optimized approach, start with the obvious one.
Say:
"I don't see the optimal solution yet, but I can solve this with [brute force approach]. That would be O(n²) [or whatever complexity]. Should I code that first, or would you like me to think more about optimization?"
Example: "Find duplicates in an array"
"I could check every pair of elements. That's two nested loops, O(n²). Not ideal for large inputs, but it would work. Should I start there?"
Why this works:
Many interviewers will say: "Yes, code the brute force, we'll optimize together."
Don't ask:
These signal: "I'm waiting for you to solve this for me."
Do ask:
Clarifying questions:
Debugging questions:
Strategy questions:
Why this works: You're asking for direction, not answers. You're showing strategic thinking.
If the full problem is overwhelming, decompose it.
Say:
"Let me break this down. First, I need to [subtask 1]. Then [subtask 2]. I know how to do subtask 1, so let me start there."
Example: "LRU Cache"
"Okay, an LRU cache needs:
- Fast lookups (O(1)) → suggests hash map
- Ordered by recency → suggests something like a list
- Fast removal of least recent → tricky part
Let me handle the lookup part first with a hash map. Then I'll think about the ordering structure."
Why this works: You're showing decomposition skills. You're making progress even if partial.
If the interviewer offers a hint, treat it like a gift, not a failure.
Don't:
Do:
Acknowledge:
"Oh, interesting. Let me think through that."
Integrate:
"So if I use a [hint], that means I can [consequence]. Let me see if that solves [the part I was stuck on]."
Test:
"With that approach, I think the complexity becomes [X]. Does that sound right?"
Example:
Interviewer: "Have you considered using two pointers?"
Bad response: "Yeah... uh... two pointers... hmm..."
Good response: "Oh! So instead of checking every pair, I could have one pointer at the start and one at the end. If their sum is too small, move the left pointer right. If too large, move the right pointer left. That would be O(n) instead of O(n²). Let me code that."
Why this works: You're showing you can learn in real-time—a critical engineering skill.
Here's a cheat sheet of effective things to say when your mind is blank:
"Let me start with the brute force approach to make sure I understand the problem correctly."
"I'm going to think out loud about what constraints matter here."
"Could I clarify [specific aspect]? That might help me choose an approach."
"I think [approach X] might work for part of this. Let me explore that."
"Here's what I'm considering, but I'm not sure about [specific gap]."
"Let me trace through an example to see where my logic breaks."
"I think my approach fails when [edge case]. Let me reconsider."
"That's a great point. Let me integrate that into my approach."
"So using [hint], I can now handle [the part I was stuck on]."
"Give me 30 seconds to think through this approach."
"Let me sketch this out on the whiteboard to see if it works."
If you're stuck on the optimal solution, write something.
Even if it's O(n³), code it correctly. Demonstrate:
Then say: "This works, but it's slow. Let me think about optimization."
If the full solution is overwhelming, code a piece:
def solve(nums):
# Main solution: stuck here
# But let me write a helper for the part I understand
def is_valid(candidate):
# Logic I know how to implement
pass
# Now I can at least use is_valid in my main logic
for num in nums:
if is_valid(num):
# ...Why this works: Forward progress. You're unstuck on part of it.
If you can't code it yet, write comments:
def solve(nums):
# Step 1: Sort the array (O(n log n))
# Step 2: For each element, use binary search for complement
# (O(n log n))
# Step 3: Handle duplicates somehow (THIS IS WHERE I'M STUCK)
passThen ask: "I have the structure, but I'm stuck on step 3. Can we discuss approaches for that?"
Don't say:
Why it's harmful: You're making the interviewer uncomfortable. They're now managing your emotions instead of evaluating your skills.
Fix: Be matter-of-fact. "I'm stuck on [specific part]. Let me try [approach]."
Symptom: Writing random code, hoping something works.
Why it's harmful: The interviewer can tell you're flailing. It looks worse than admitting you're stuck.
Fix: Stop. Say: "This isn't working. Let me step back and reconsider."
Symptom: Long silence. Waiting for a hint without asking.
Why it's harmful: You look passive. Interviewers want to hire people who drive forward.
Fix: Drive the conversation. Propose ideas. Ask questions. Show agency.
Symptom: Interviewer says "Have you considered X?" You say "Hmm" and keep doing what you were doing.
Why it's harmful: You're not collaborative. You're not adaptable.
Fix: Engage with every hint. "Oh, that's interesting. Let me explore that."
You can train this skill before interviews.
Pick a hard problem. Set a timer for 5 minutes. Try to solve it.
When the timer goes off, pause and verbalize:
This trains you to articulate partial progress.
Get a friend or use a platform. Solve problems out loud.
Critically: When you get stuck, don't go silent. Practice saying:
Tools like mock interview simulator can provide realistic practice environments where you're forced to communicate through uncertainty, preparing you for real interview dynamics.
Pick 3 problems. Don't look at any solutions for 24 hours.
Force yourself to sit with being stuck. Try multiple approaches. Fail. Try again.
This builds tolerance for uncertainty—the key skill when stuck in interviews.
Strategy: After 10 minutes stuck, propose your best partial solution. Say: "I don't have the full solution, but here's my approach for [part I can solve]. If I had more time, I'd focus on optimizing [part I'm stuck on]."
Yes. Say: "I've seen a similar problem before. I remember it involved [general approach], but let me work through the details to make sure I understand it."
Ask directly: "I've been stuck on this for a few minutes. Would it help if I talked through my current thinking, or would you like to give me a hint?"
Ask first. Some companies allow it. Say: "Is it okay if I look up the syntax for [specific standard library function]?" Never look up the solution.
Communicate the solution verbally: "I don't have time to implement fully, but here's the approach: [explain logic]. The complexity would be [X]. Key edge cases are [Y]."
Getting stuck in an interview is uncomfortable. It's stressful. It feels like failure.
But it's not failure—it's the test.
The interview started when you got stuck. Everything before was warm-up.
What separates strong candidates from weak ones isn't never getting stuck—it's what they do when they are.
Strong candidates:
Weak candidates:
The next time you're stuck in an interview, remember: this is your moment to show adaptability, communication, and resilience. Say it out loud: "I'm stuck on [specific part]. Let me propose [approach] and see if that moves us forward."
The interviewer doesn't expect perfection. They expect productive struggle. Give them that, and even when you're stuck, you're succeeding.
LeetCopilot is a free browser extension that enhances your LeetCode practice with AI-powered hints, personalized study notes, and realistic mock interviews — all designed to accelerate your coding interview preparation.
Also compatible with Edge, Brave, and Opera
Add to Chrome for free