The first technical interview I failed, I solved the problem.
Not quickly, and not elegantly, but I got there. I also spent eleven minutes staring at the screen in complete silence before writing anything. From the interviewer's side, that was eleven minutes of no information whatsoever.
He could not tell whether I was reasoning carefully or entirely lost. Given no evidence, he assumed the second.
The thing being evaluated
A technical interviewer is not primarily checking whether you produce a correct solution. They are checking:
- How you decompose an unfamiliar problem
- Whether you ask before assuming
- Whether you can evaluate your own approach
- What you are like to work with when something is hard Every one of those is invisible when you think silently. Your reasoning is the deliverable. The code is evidence.
This is also why "I've seen this one, here's the optimal solution" delivered instantly is not the strong move people think it is. It demonstrates recall, not process.
The loop I run
Six steps, in order, out loud.
1. Restate the problem
"So I need to find the longest substring with no repeating characters, and return its length — not the substring itself. Right?"
Thirty seconds, and it catches misunderstandings before they cost you twenty minutes. It also buys thinking time that does not look like stalling.
2. Ask about the edges
Real questions with real consequences:
- What is the input size? Ten elements or ten million?
- Can it be empty? Can it be null?
- Are there duplicates? Is it sorted?
- Is it ASCII or Unicode? Interviewers often deliberately leave these out. Asking is part of the test — a candidate who assumes the happy path is a candidate who ships bugs.
3. Work one example by hand
Pick a small input and trace through what the answer should be. Out loud, on paper or in the shared editor.
This does more work than it looks like. Half the time, the pattern that becomes the solution surfaces while walking through a concrete case.
4. State the brute force, then say why it is not enough
"The obvious approach is to check every substring — that's O(n²) or worse. It's correct, but it won't hold at scale. Let me see if there's something better."
Never skip this. It establishes that you have a working solution, which means the conversation is now about optimisation rather than about whether you can solve it at all. That is a much better position, and if you run out of time you have something rather than nothing.
5. Optimise, narrating the search
"I'm scanning the same characters repeatedly. That usually means either a hash map to remember what I've seen, or two pointers. Let me try the sliding window — I think I can keep a set of what's in the current window and shrink from the left when I hit a duplicate."
Notice this narrates the reasoning, not just the conclusion. "I'll use a sliding window" tells the interviewer what. "I'm scanning the same characters repeatedly, so I want to remember what I've seen" tells them why — and why is what is being graded.
6. Test out loud before declaring done
Walk your own code against the empty input, the single element, the all-duplicates case. Find your own bugs before they are pointed out to you.
Then state the complexity, in both time and space, without being asked.
What to say when you are stuck
Being stuck is not a failure state. Being stuck silently is.
Useful things to say:
- "Let me think for thirty seconds." Explicit, bounded, does not read as freezing.
- "I'm considering two approaches — a hash map or sorting first. The hash map is O(n) but uses extra space. Let me start there." Narrating a choice is progress.
- "I know there's a better approach here but I'm not seeing it. Let me get the working version down first." Honest, and it produces something.
- "Am I on a reasonable track?" Asking for a hint costs less than most candidates think. Interviewers are usually allowed and often willing to give one. Twenty silent minutes cost far more. What does not work: pretending to type, guessing at syntax you do not know, or going quiet and hoping.
Narration in a system design round
Same loop, different scale. The failure mode is jumping straight to a diagram full of boxes.
Better sequence:
- Clarify scope — how many users, read-heavy or write-heavy, what has to be consistent
- Estimate roughly — order of magnitude only; nobody needs exact arithmetic
- Sketch the simple version — the design that works for a thousand users
- Break it deliberately — "at ten million this database becomes the bottleneck, so…"
- Name the tradeoffs — every choice costs something, and saying so is the point Step four is where senior candidates separate. Anyone can draw a system. Explaining where your own design fails, and what you would do about it, is the actual signal.
The habit underneath
Narration is uncomfortable at first because it exposes half-formed thinking. That exposure is the whole value — it is the only way an interviewer can see how you work.
The good news is that it is trainable in a way that talent is not. Solve practice problems out loud, alone, talking to an empty room. It feels ridiculous for about two sessions and then becomes automatic.
The same principle — making your reasoning visible instead of presenting only conclusions — runs through the non-technical rounds too. That is the speaking side of it, and for behavioural rounds specifically, the story structure that works.