Taking a hint in a coding interview usually costs something. The cost depends on the hint’s size. It also depends on what you do in the next two minutes. The Holloway hiring guide describes hints as a ladder. The bottom rung is a nudge about scope. The top rung explains your bug and asks you to fix it. A small nudge, used well, may cost one point on one rubric line. A string of large hints is what sinks a round. Silence is often worse than asking. An interviewer can’t help a candidate whose thinking they can’t see. So the tactic has three parts. Get stuck out loud. When you need help, ask a narrow question, so the help you get stays small. Then use the hint fast and earn the rest of the rubric on your own. Below, one Android engineer’s coding round shows the whole sequence, with a script you can adapt.
Interviewers grade a hint by how far up the ladder they had to go
The Holloway Guide to Technical Recruiting and Hiring lays out hints from lightest to strongest. Its section was last updated in August 2022. Ozzie Osman wrote it with more than 45 contributors. The lightest hint fixes scope, like telling you to ignore storage. Next comes a direction, like pointing at a data structure you mentioned. Then comes general feedback, like “I think you may have a bug.” Then a specific input that breaks your code. The strongest hint explains the flaw and asks how you’d fix it.
The guide tells interviewers to start general and escalate slowly. It also says a specific hint may signal concern about your debugging. So what counts is which rung the interviewer had to reach.
One hint moves one rubric line, so the rest of the round still counts
Rubrics split a coding round into separate dimensions. The Tech Interview Handbook’s coding signals page uses four. They are communication, problem solving, technical competency and testing. Yangshun Tay, a former Meta engineer, wrote it. In its rubric, “did not require any major hints” is a basic problem-solving signal. Both hire ratings require all the basic signals. So on that rubric, one major hint caps problem solving below hire. It doesn’t touch the other three lines.
Ian Douglas, an interviewer on interviewing.io, describes a similar trade. In his post on more than 600 interviews, each candidate starts at 3 of 4 per category. Needing many hints while coding lowers technical proficiency. He would rather deduct a point for a hint and “see you ultimately succeed.” The post shows no publication date. Interviewing.io sells interview practice.
Put together, the two sources point the same way. A hint costs points on the line it touches. A stalled round with no working code costs points on every line.
A silent stall forces the interviewer up the ladder
Take an Android engineer in a 45-minute coding round. The prompt is to merge overlapping app sessions. Each session has a start and an end minute. The output should list merged sessions with no overlaps.
The engineer writes a nested loop that compares every pair. Then they realize merged sessions can create new overlaps. They go quiet for five minutes, rewriting the loop.
The interviewer can’t see the problem from outside. So they guess. A scope nudge won’t help, since the scope is fine. They skip to a direction: “What if the sessions were in order?” That hint is two rungs up. It also carries the key idea. The engineer now looks like someone who needed the solution handed over.
The same moment can go differently. The engineer can say what’s wrong and ask a small question. The interviewer can then answer at the lowest rung that fits.
A script for asking, taking and recovering from a hint
Here is the second version of that moment. The engineer has been stuck for about two minutes.
I’m stuck on one part. Pairwise merging is O(n squared). Worse, a merge can create a new overlap I already passed. I think the order of processing is the problem. Can I assume nothing about input order? Or is sorting the input fair game?
The interviewer answers: “You can sort it.” That’s a scope answer, the lowest rung. The engineer takes it and keeps talking.
Thanks, that helps. If I sort by start time, overlaps can only happen with the last merged session. So I keep one list and compare each session to its tail. Sorting is O(n log n). The pass is O(n). Let me write that, then test a session that sits inside another one.
The engineer writes this in Kotlin.
data class Session(val start: Int, val end: Int)
fun mergeSessions(sessions: List<Session>): List<Session> {
val merged = mutableListOf<Session>()
for (s in sessions.sortedBy { it.start }) {
val last = merged.lastOrNull()
if (last != null && s.start <= last.end) {
merged[merged.lastIndex] = Session(last.start, s.end)
} else {
merged += s
}
}
return merged
}
Then they trace the input they promised to test. The sessions are 1 to 10, 2 to 5 and 12 to 15. The trace gives 1 to 5, then 12 to 15. The nested session cut the outer one short.
That’s wrong. The 2-to-5 session overwrote the end of the 1-to-10 one. The end should be the larger of the two ends. I’ll change it to maxOf of the last end and this end.
With maxOf(last.end, s.end), the same input gives 1 to 10, then 12 to 15. Unsorted input works too. Sessions 9 to 12, 1 to 4 and 3 to 6 merge into two. They are 1 to 6 and 9 to 12.
Why each part of the script works
The opening line says where the engineer is stuck. That lets the interviewer pick the lowest rung that helps. In Holloway’s terms, they can answer with scope instead of a direction.
The question offers two options the engineer already has in mind. Sorting was their own idea. The interviewer only confirmed it was allowed. That reads very differently from “What if the sessions were in order?”
The recovery restates the hint as a plan, with complexity attached. That earns problem-solving signals right after the hint. It also shows the engineer understood the hint.
The planned test belongs to the testing line of the rubric. It also caught the nested-session bug before the interviewer did. Otherwise the next rung, “I think you may have a bug,” would have come from them. Testing out loud saved the engineer a second hint.
How long to stay stuck before you ask for a hint in a coding interview
Holloway’s guide says a candidate stuck for more than a few minutes usually needs a hint. Use that as your own limit. In a 45-minute round, two or three minutes without progress is a good point to speak.
Practice the ask, not just the problems. In mock rounds, tell your partner to use the ladder and to give only what you ask for. Afterward, ask which rung they had to reach. If it’s often the top two, practice saying where you’re stuck sooner. Our post on the algorithm round in Android interviews covers talking through a problem in Kotlin. For rounds where the interviewer steers on purpose, see the Android pairing round.
One more habit helps the written feedback. When the hint lands, say what it changed. “Sorting means I only compare with the tail” tells the interviewer exactly what to write. Their notes then show a small hint and a fast recovery. Those notes are what the later hiring decision is made from.