Why the process beats the answer
The interviewer can't see inside your head. If you write code silently for 20 minutes, they have no idea how you reason, test hypotheses, or catch bugs. Talking through your thinking isn't "chatter" — it's how you show engineering judgment. Often a sound approach with stated trade-offs scores higher than a perfect answer from nowhere.
A structure for live-coding
- Clarify the problem. Restate it in your own words, ask about edge cases and data sizes. This alone signals maturity.
- State the approach before code. "I'd use a hash map — O(n) time, O(n) space. There's an in-place variant but it's slower, so I'll start simple."
- Write and narrate. Explain what you're doing and why as you go.
- Test on examples. Walk through normal and edge inputs out loud.
A structure for system design
- Clarify requirements and load (users, RPS, data volume).
- Sketch a high-level diagram: clients, API, storage, cache.
- Go deep where the interviewer steers; name trade-offs (consistency vs availability, cost vs speed).
- Call out bottlenecks and how you'd scale them.
What to avoid
- Long silences — if you're thinking, say "give me a second to think about the data structure."
- Jumping into code without clarifying.
- Defending your first solution when the interviewer hints at a problem — better to say "fair point, let's revisit."
Checklist
- I clarify the prompt before solving
- I state the approach and complexity before coding
- I narrate as I go
- I test edge cases out loud