An interviewer offers a hint mid-solve — how do you take it, and what does resisting it signal?
answer
- who benefits from you finishing?
- hands off the keyboard first
- say it back before you use it
- name what it buys and what it costs
- and say aloud what you are abandoning
basics
~20 sTreat a hint as new data, not a verdict. Say it back in your own words, state what it changes about your plan and what it costs, then adjust visibly. Resisting one signals you will argue with review feedback.
solid answer
~50 sA hint is an interviewer investing in you, not writing you off — they hand hints to candidates they want to see finish. The recovery move has three parts. First, receive it: pause the keyboard and repeat it back in your own words, so both of you know you heard the same thing. Second, price it out loud: "processing the bookings in start order means an ordering step up front, and in exchange I think I can stop re-scanning — let me check that against the small example." Third, act on it visibly, and say what you are abandoning. What gets scored badly is not needing the hint; it is arguing with it, absorbing it silently and pretending it was your idea, or nodding and continuing down the stalled path anyway. All three read the same way to an interviewer: this person will not take feedback in a code review.
go deeper
Recall the receive-restate-use sequence and practise it until it is reflex. Take your hands off the keyboard, repeat the hint back in your own words, then say what you are changing because of it. Needing a hint is normal.
Explain the mechanics of the hint, not just its content: what it buys, what it costs, and which part of your existing plan it invalidates. Retiring the old plan aloud is what prevents the half-old half-new hybrid that sinks most post-hint attempts.
Demonstrate composure and negotiation. If you believe you are close, propose a bounded window rather than defending; if the hint lands, name the sunk work you are dropping and move without visible frustration. This is read as a sample of how you take review feedback.
Own the meta-signal. Be able to say what a hint is diagnosing and how you would weigh hint usage when evaluating someone else — distinguishing a candidate who lacked one insight from one who cannot integrate input, which is the distinction that actually predicts collaboration.
## What a hint actually means The most damaging belief in this whole area is that a hint is a failure marker — that the round was fine until the interviewer spoke, and now it is over. In practice the opposite is closer to true. Interviewers hint because they want a signal they cannot get from a stuck candidate: they already know you are stalled, and watching you stay stalled teaches them nothing further. Handing you a lever converts dead time into observable behaviour. Many loops are explicitly calibrated with the expectation that hints will be given, and the rubric asks how the candidate *used* them, not whether they were needed. So the question a hint really asks is: how do you behave when someone with more context tells you something you did not have? That is a question about working with a colleague, and it is scored as such. ## The three-part recovery **Receive it.** Stop typing. Fingers still on the keyboard while someone explains something is the physical form of not listening. Then say it back in your own words: "So — consider the bookings in order of start time rather than in the order they arrive." This costs five seconds and does two jobs. It proves you heard the hint rather than a hint-shaped noise, and it lets the interviewer correct you immediately if you heard it wrong. Candidates lose real time acting confidently on a misheard hint. **Price it out loud.** A hint is not an instruction; it is a direction with consequences. Say what you think it buys and what it costs: "That adds an ordering step before I start, so I pay for that up front. What I think I get back is that I stop re-examining entries I have already dealt with. Let me run that on the three-booking example and see whether it holds." This is the beat that separates a candidate who *understood* the hint from one who is merely obeying it. Obedience is a weak signal; understanding is the thing being tested. **Act visibly, and name what you are abandoning.** "I'm dropping the pairwise comparison I started — it does not survive this change — and restructuring around the ordered pass." Explicitly retiring the old plan matters, because otherwise you end up with a hybrid: half the code assuming the old shape and half the new. That hybrid is where most post-hint solutions actually die, and the interviewer can see it coming long before you can. ## The four ways candidates mishandle hints **Defending the stalled approach.** "I think mine works, I just need to handle one more case…" said for the third time. Sometimes it is even true, and it is still the wrong move: you are spending the interviewer's offered help on an argument. If you genuinely believe your path is close, the way to say it is a bounded proposal, not a defence: "I think I'm two minutes from correct — can I finish this case, and if it doesn't fall out I'll take the reordering?" That is negotiating with a plan, and interviewers accept it. **Silent absorption.** Nodding, going quiet, then producing the hinted solution as though it were yours. It looks like concealment, and it destroys the only thing the hint was supposed to reveal: how you reason with new input. **Nod-and-continue.** "Right, yes, good idea" — and then the next line of code is from the old plan. This is the most common failure, and it usually is not defiance; it is that the candidate has not actually re-planned and their hands keep going. It is exactly what the restate-and-price beats prevent. **Over-collapse.** Treating one hint as proof that everything you did was wrong, discarding correct work, and losing composure. A hint is usually local: it fixes one step, not your whole approach. Ask which part it touches. ## Asking for a hint yourself Asking is legitimate, and how you ask is itself a signal. A bad ask is "I'm stuck, can you help?" — it transfers the whole problem. A good ask localises: "I've got the structure I want, but I can't find a way to avoid re-examining entries I already handled. Am I missing something there, or is that inherent?" That tells the interviewer exactly where to aim, proves you have a model of your own blockage, and often gets a smaller, cheaper hint than the one you would otherwise have been given. Do it after you have visibly tried something, not as a first move. ## The underlying signal Every one of these behaviours is a proxy for a working relationship: what happens when a reviewer leaves a comment on your change, when a design gets challenged, when someone senior says "have you considered ordering these differently?" Interviewers know they cannot observe a year of collaboration in forty minutes, so they read the two minutes after the hint as a sample of it. Take the data, restate it, price it, use it, and say what it cost you. That sequence is the whole answer.
- You are fairly sure your stalled approach is two minutes from working. Do you take the hint anyway?Do not argue — negotiate with a bound. "I think I'm close: one more case and this is correct. Can I take two minutes, and if it doesn't fall out I'll switch to the ordering you suggested?" That states a position, prices it, and gives the interviewer a decision they can make. If they say switch now, switch now without relitigating; the round is theirs to steer, and a second defence costs far more than the two minutes ever would.
- How do you ask for a hint without it reading as giving up?Localise the blockage instead of surrendering the problem. "The structure I want is clear, but I can't see how to avoid re-examining entries I already handled — is that inherent, or am I missing an angle?" This shows a model of your own sticking point, aims the interviewer at the smallest useful nudge, and typically earns a narrower hint than a broad "I'm stuck" would. Ask after visible effort, not as an opening move.
- The hint pushes you toward an approach you do not fully understand yet. What is the honest move?Say exactly that, then reason forward in the open rather than bluffing. "I can see that ordering them changes what I have to compare, but I don't yet see why it removes the repeated work — let me trace three entries by hand and find out." Working the example aloud is a strong signal. Silently implementing something you cannot explain is the version that collapses under the first follow-up question.
A hint is a review comment on a pull request, not a rejection of the change. The reviewer wants it merged; they are telling you what stands between here and there.
saying these in an interview costs you the question
- Treats a hint as proof the round is already lost
- Keeps defending the stalled approach after the second nudge
- Nods, says 'good idea', then continues the old plan
- Absorbs the hint silently and presents it as their own
- Discards all prior correct work over one local nudge
- Asks 'what should I do?' instead of naming where they are stuck