What to Do When You're Stuck

The plain-language idea

Picture standing in front of a locked door with a ring of unlabeled keys. You don't just freeze. You try a key, notice it doesn't fit, try another. You keep moving, even without knowing which key works yet.

Getting stuck in a DSA interview feels like that door, except your brain says freezing is safer than trying a key that might be wrong. It isn't. Every engineer — junior, senior, even the person interviewing you — gets stuck regularly. What separates people is having a small set of moves for what to do next, instead of going silent. Here are four:

• Shrink the example. If the problem feels too big to hold in your head, make it smaller — a 2 or 3-element version is often enough to see the pattern by hand.
• Say what you'd try, even unsure it'll work. "I'm not certain this is right, but let me try sorting first" is a completely legitimate thing to say.
• Ask a clarifying question. "Can the array have duplicates?" isn't an admission of weakness — it's what a careful engineer does before committing to an approach.
• Name the brute force, even knowing it's not optimal. It gives you and the interviewer something concrete to improve from, instead of nothing.

None of these require already knowing the answer. All four are things you can do the moment your mind goes blank.

See it in a real thing: narrating your way out of stuck

// You're asked: "find the length of the longest strictly increasing
// run of numbers in an array." You freeze for a second. Here's what
// getting unstuck sounds like, turned into comments:

// "Let me shrink this. With [1, 2, 1, 3, 4], what's the answer by
//  hand? 1,2 is increasing (length 2). Then it drops. 1,3,4 is
//  increasing (length 3). So the answer here is 3."

// "I don't see the fast way yet, so let me name the brute force:
//  check every starting point, walk forward while it keeps
//  increasing, track the longest run I find."

function longestIncreasingRun(nums) {
  let longest = 1;
  let current = 1;
  for (let i = 1; i < nums.length; i++) {
    if (nums[i] > nums[i - 1]) {
      current++;                       // run continues, keep growing it
    } else {
      current = 1;                     // run broke, restart at this number
    }
    longest = Math.max(longest, current);
  }
  return longest;
}

// "Actually — walking through it out loud, I realize I don't need to
//  restart from every point. One pass, tracking the current run,
//  already gets me the answer." That realization only showed up
// because the small example and the brute-force framing came first.

What people usually miss

Watch out

• Believing getting stuck means you're not senior enough. Senior engineers get stuck on unfamiliar problems constantly — the difference is having practiced moves for it.
• Waiting in silence until the "right" idea arrives. The four moves above are meant to be used before you have the right idea — they're how you find it.
• Treating a clarifying question as admitting confusion. Strong candidates ask them on problems they understand well — it's a habit, not a red flag.

The genealogy: this is the framework's safety net

When step 3 or step 4 of the problem-solving framework stalls out, these four moves are what get you moving again — shrinking the example is literally step 2 of that framework, reused as a rescue tool.