The Coding Round Without the Panic

The moment the problem appears on the screen, the instinct is to start typing. Resist it. The candidates who do best in coding interviews are the ones who treat the first two minutes as thinking time, not stalling time.

Think out loud, even when it feels dumb

Silence is the biggest self-inflicted wound in a coding interview. An interviewer watching you type wordlessly for ten minutes has no idea if you're brilliantly assembling a solution or completely lost until you either finish or freeze. Either way, they're now guessing, and guessing tends to default pessimistic.

Narrate the boring stuff: "I'm going to start with a brute force approach so I have something working, then see if I can improve it." "This smells like a hash map problem because I need fast lookups." "Let me trace through the example by hand first." None of this needs to be profound. It needs to exist, so the interviewer can follow your reasoning and correct you early if you're heading somewhere unproductive - which is a gift, not a penalty. A wrong turn caught in minute two costs nothing. The same wrong turn discovered in minute twenty costs the whole round.

Ask clarifying questions before you write a line

Real problems are ambiguous on purpose - interviewers want to see if you notice. "Find the duplicate in this array" hides real questions: Can the array be empty? Are we optimizing for time or space? Is the input sorted? Can there be negative numbers? Asking these isn't a stall tactic - it's the same due diligence you'd want from a teammate before they touched production code on an ambiguous ticket.

Two or three sharp questions up front, then start. If you ask a fourth and the interviewer says "good question, let's say no" - that's fine, keep moving. The point isn't to interrogate every possibility, it's to show you question assumptions instead of charging at the first interpretation of a problem.

"I don't remember the exact syntax" is a fine thing to say

Nobody keeps every method name in their head, especially under pressure in a language they don't use daily. Saying "I don't remember if it's .length or .length() here, I'll flag it and keep going" and writing pseudocode-ish syntax around it loses you nothing. What loses you points is stopping cold because one detail slipped your mind, or worse, confidently writing wrong syntax and refusing to flag the uncertainty.

Reasoning through the algorithm is the deliverable. Exact syntax is a formality most interviewers will wave past or gently correct. If you're visibly more worried about a missing semicolon than about whether the logic is right, that reads as backward priorities - because it is.

When you get stuck

Getting stuck is not the failure state. Staying stuck silently is.

• Say it plainly. "I'm stuck - my current approach is O(n²) and I think there's a faster way, but I'm not seeing it yet." This is information, not a confession.
• Go back to the example. Trace through the input by hand again. Stuckness often comes from having drifted from the concrete case into abstract fog.
• State what you know is true. "I know the answer needs to track the running total somehow." Small true statements rebuild momentum better than staring at the screen.
• Take the hint. If the interviewer offers one, take it and keep moving instead of treating it as a loss. Using a hint well is still a good outcome.
• Fall back to brute force. A working, clearly-explained slow solution beats a broken fast one. Say so explicitly: "I know this isn't optimal, but let me get something correct first."

The candidates who recover from a stuck moment calmly, out loud, usually score better than the ones who never got stuck but also never explained anything.

[
  {
    "q": "Why does thinking out loud matter in a coding interview?",
    "choices": ["It fills the silence so the interview doesn't feel awkward", "It lets the interviewer follow your reasoning and correct wrong turns early, before they cost the whole round", "Interviewers grade on word count"],
    "answer": 1
  },
  {
    "q": "What's the best move if you forget the exact syntax for a method?",
    "choices": ["Stop and try to recall it exactly before continuing", "Flag it out loud, write approximate syntax, and keep reasoning through the logic", "Ask the interviewer to look it up for you"],
    "answer": 1
  },
  {
    "q": "You've been stuck for two minutes with no progress. What should you do?",
    "choices": ["Stay silent and keep thinking until you find the answer", "Say out loud that you're stuck and what you've ruled out so far", "Start over from scratch without explaining why"],
    "answer": 1,
    "explain": "Saying it out loud turns a silent stall into information the interviewer can act on - including offering a hint."
  }
]

← Phase 1: What Interviews Are Actually Testing For · Guide overview · Phase 3: System Design and the Human Round →