Every technical interview is really two interviews running at the same time. The first is the obvious one — can you solve the problem in front of you. The second is quieter, and it's the one that decides most offers: can the interviewer see how you think, and do they want to think alongside you every day for the next several years.
Candidates who focus only on the first interview get stuck when the problem stretches beyond what they memorised. Candidates who make the second interview visible — narrating their approach, stating their assumptions, sketching before coding — tend to do well even when they don't fully finish. This guide is built around making that second interview show up.
Before the interview: build a small, honest problem library
Most people prepare by grinding through hundreds of problems and hoping something sticks. A better approach is to build a smaller, curated library of maybe 30–40 problems that together cover the shapes you'll actually see: arrays, hash maps, two pointers, sliding windows, trees, graphs, dynamic programming, and one or two design questions.
Then, and this is the part most people skip, re-solve each problem after a week without looking at your notes. If you can explain the solution out loud in one paragraph while pacing around the room, you've internalised it. If you have to look at your notes, it's not yours yet.
During the interview: narrate the state of your own head
The single biggest predictor of a strong signal in an interview is whether the interviewer knows what you're thinking. Silence is expensive. It doesn't matter how brilliant your internal reasoning is — if it stays internal, you get no credit for it and the interviewer starts to worry.
- Restate the problem in your own words before you touch the keyboard. This catches misunderstandings that would otherwise cost you 20 minutes.
- Ask about input sizes. If N is small, an O(N²) solution might be fine and you save yourself a lot of complexity.
- Propose a naive solution out loud even if you already see the optimised one. It shows range and gives the interviewer a hook to talk to you about trade-offs.
- When you get stuck, say what you're stuck on. 'I know how to iterate but I'm not sure how to avoid the duplicate case' is a useful sentence; staring at the screen is not.
After you finish: test with the ugly cases first
Once you have code that compiles, don't run your happy-path example. Run the empty input, the single-element input, the input with all duplicates, and the largest reasonable input. This is where senior candidates separate themselves from mid-level ones — not by writing the algorithm faster, but by testing it more skeptically.
One-line summary
Show the interviewer your thinking out loud, propose the ugly solution before the elegant one, and stress-test with the ugliest inputs before you declare victory.
When the interview goes badly
Some interviews will not go well. You'll blank on a problem you've solved twice at home; the interviewer will ask about a data structure you last touched in college. When it happens, the recovery move is the same: name the state you're in, ask for a hint, and keep moving. Interviewers don't expect perfection — they expect that a bad hour still ends with you making progress. That's the second interview, and it can save the first one.
Filed under Interviews. Written by the Stellenzu editorial team.