Part 14 of 14 · ~2 min
Common Mistakes, and a Better Way to Structure the Answer
Weak answers rarely come from a missing fact. They come from one of a small handful of process failures, repeated — and every single one below is something Fanline's own team actually did at some point in the story above.
- Drawing boxes before anyone's clarified anything. A sharded, multi-region database for a system that, it turns out, sells tickets to one 300-seat room is a design answering a question nobody asked. Interviewers notice immediately, because skipping straight to a solution is exactly the habit that separates someone reciting a template from someone actually reasoning through the problem in front of them.
- Building for load that was never estimated. Reaching for sharding on day one, when the honest math from step two comes out to a couple of requests per second, doesn't read as ambition — it reads as a design that ignored its own numbers. Fanline stuck with a single, vertically-scaled server for months, and that patience was the correct call, because nothing in the estimate justified more than that yet.
- Pretending the design has no soft spots. Every real one does — a coordination cost paid on the reserve path, a staleness window on the browse badge, a scrambling step added to a confirmation code. Volunteering yours before someone has to dig for it is what an actual design review looks like; a diagram presented as flawless is the thing that should worry an interviewer, not reassure them.
- Spending the whole clock on the diagram and never reaching the interesting part. A candidate who's still drawing boxes forty minutes in never gets to show the thing that actually separates a strong answer — the specific race condition, the specific algorithm, the specific place it breaks under load. A workable split: a handful of minutes each on clarifying and estimating, roughly a third of what's left on the high-level shape, the largest slice reserved for actually going deep on a component or two, and whatever remains spent naming what you didn't solve.
- Dropping a technology's name instead of a reason. "I'd reach for a queue here" tells an interviewer nothing on its own. What they're actually listening for is the chain from requirement to decision — the technology's name is nearly the least important part of the sentence.
None of this is a script to memorize — it's a habit to practice. Run the same five steps against a handful of genuinely different problems in the code lab, honestly enough each time, and the framework stops being something you're reciting and starts being something you just do.