What to Do When You're Stuck in a Coding Interview (The Hint Economy)

Jordan Beland9 min read
interview-prep
coding

Every well calibrated coding interview problem has a wall built into it somewhere, and that's deliberate. After years of running these rounds and then arguing about them in debriefs, I can tell you that watching a candidate work through the wall is most of what the round exists to measure, so getting stuck is not the failure state candidates think it is. What separates the writeups, in my experience, is rarely whether someone got stuck and almost always what the stuck looked like from my side of the table.

Candidates tend to walk in with a mental price list for hints (one hint costs points, two means trouble, three means rejection) that has very little to do with how hints actually get discussed afterward. This article is about that gap: what a hint really costs, what taking one well signals, and the specific moves that turn a wall into gradeable material.

What a Hint Actually Costs

The fear is that hints draw down a fixed budget, so people treat accepting one like an admission of defeat and spend enormous amounts of clock trying to dodge it. Realistically, the accounting is softer than that. A note like "needed a nudge on the window invariant, incorporated it immediately, finished clean" reads fine in a debrief, and in plenty of the debriefs I've sat in, a hint like that barely surfaced, because the discussion centered on the recovery and the recovery was strong.

I'll hedge this honestly, because practices vary. Some companies track hints more formally than others, and a phone screen with one grader is less forgiving than an onsite where a committee argues your case. Even in the stricter setups, though, the cost of a hint was consistently smaller than the cost candidates imagined, and a good recovery usually outweighed it entirely.

The rounds that actually generated bad writeups looked different. Long silent thrashing, where there is simply nothing to grade (the same mechanic I wrote about in talking while you code, which is really the sibling of this piece). The full restart at minute 30, which is almost never recoverable in the time left and throws away partial credit that was already banked. The candidate who waves off a hint with "no, I've got it" and then spends ten more minutes demonstrating otherwise. And the same hint needed twice, which suggests the first one never actually landed.

A Hint Taken Well Is a Positive Signal

This is the part I wish more candidates internalized. The job you are interviewing for involves absorbing code review comments, getting redirected partway through design discussions, and hearing "have you considered X" from a tech lead on a regular basis. A candidate who takes a steer, connects it out loud to what they already had, and visibly runs with it is showing the interviewer a preview of what working together will be like. Coachability appears on more rubrics than people realize (sometimes filed under collaboration, sometimes under responding to feedback), and I have argued for candidates in debriefs partly on the strength of how they used a nudge.

It helps to know that interviewers generally want to give the hint. A candidate in motion produces signal, and a candidate frozen at the wall produces almost none, so offering a steer is the interviewer buying back gradeable minutes on your behalf. When one comes, it is sincere.

Want to practice this on a real question, with feedback attached?

Productive Stuck vs. Fatal Stuck

There's a rule I learned in the backcountry (where a good chunk of my non-work time goes) for the moment you realize you've lost the trail: stop moving immediately. You breathe, you pull out the map, and you reorient from the things you know for certain (the ridge you've been following, the creek you crossed a while back, the last marker you're sure you saw) before you pick any direction at all. Pushing faster along the line you were already walking feels productive, and it is precisely how a small miss becomes a long night. An interview rewards the same discipline, because most of the damage I've watched candidates do to their own rounds happened after the wall, when they kept moving quickly in a random direction rather than stopping to reorient.

Productive stuck is gradeable: you narrate the wall, you test your assumptions out loud, you shrink the problem down to something you can trace by hand. The interviewer gets to watch you debug your own thinking, which is about as close as an interview ever gets to the actual job, and it's genuinely valuable material for your writeup. Fatal stuck is the opposite: silence, random mutations of the code in the hope that a test goes green, or deleting everything to start over.

Four Moves for When You Hit the Wall

  1. Announce the wall. "I'm stuck on how duplicates break this, let me reason through it out loud." This converts dead air into gradeable thinking, and it tends to invite a hint at exactly the moment a hint is cheapest.
  2. Restate what you know for certain. The constraints, the part that already works, and precisely where it fails. This is the map-and-landmarks move, and stating the failure point out loud dissolves it surprisingly often ("it breaks when the window shrinks past... oh, I need a max there").
  3. Shrink the problem. Trace n=3 by hand, or solve the version without the hard wrinkle first (no duplicates, no negatives) and then reintroduce it. Patterns that hide at full generality tend to fall out of small concrete cases, and a narrated hand trace stays gradeable the entire time.
  4. Ask a calibrated question. A vague "what should I do here?" hands over the steering wheel and grades accordingly. A precise one ("I'm weighing a heap against sorting upfront, will the follow-up care about repeated queries?") shows exactly where your uncertainty lives, and that precision is strong signal on its own.

When the Hint Comes

Take it seriously, and connect it aloud to what you had ("so if I track the last seen index instead of a boolean, the shrink step becomes a jump"). The weakest response is the polite nod followed by an unchanged plan, which usually reads worse than the stuck did. Asking for a hint outright is also fine. "I'm going back and forth between two approaches, can I get a sanity check before I commit?" lands well, and late in a round it beats running out the clock with nothing on the board.

Don't be too hard on yourself about needing one at all. In the loops I've run, plenty of candidates who got offers took a hint somewhere along the way, and the perfectly clean no-hint round is rarer than most preppers assume.

Practicing the Wall

Recovery is a rehearsable skill, but only if your practice includes real stuck, which means timed problems slightly above your comfort level, worked out loud. A friend playing interviewer while your phone records covers a lot of this for free. Peer mocks on Pramp (now hosted on Exponent, with 5 free credits a month) add a stranger, which is usefully scarier. interviewing.io offers paid mocks with practicing senior interviewers, and AI mocks let you hit walls and rehearse asking for help on your own schedule. If you're fitting this into a broader schedule, the four-week prep plan covers where mock reps belong week by week.

Handling the wall gracefully is a habit, and habits come from reps where the wall actually shows up. If you want practice that will let you get properly stuck and then offer a hint when you ask for one, that is exactly what we built Preppable to do. And if a patient friend and a phone recording are more your speed, that honestly covers most of it. Either way, make sure some of your practice includes a real wall, because those are the sessions that teach recovery.

Practice this for real

Put this into practice on a real coding question

Preppable runs the question end to end, watches how you work through it, and tells you what an interviewer would have written down. Free to start, no credit card.

Not ready yet? Get new posts by email. We usually publish a couple times a week.

Unsubscribe any time. See our Privacy Policy.

About the author

Jordan Beland avatar

Jordan Beland

Co-founder & CTO, Preppable

Principal architect with 10+ years designing and scaling production-grade Azure systems, with deep expertise in distributed systems and developer platforms. Has run countless interview loops from the interviewer side across coding, system design, and behavioral rounds, and sat in the debriefs afterward.

Connect on LinkedIn