Interviewing next week
Pre-interview sharpening for engineers who already know the concepts — this is the crash course that plugs the most common gaps that lose rounds.
For: Mid-senior engineers 7–14 days before a round
After this path
Walk into the round with the five most-tested patterns and the failure-mode framework rehearsed.
- 1Pattern
Read-heavy
Reads dominate writes by 10:1 or more. Every layer exists to keep the primary out of the hot path.
Why this, here: Re-read the scaling path — v1→v2→v3 — until you can narrate it on a whiteboard cold.
- 2Pattern
Write-heavy
Writes arrive faster than any single node can persist them synchronously. The design is about absorbing, spreading, and deferring them.
Why this, here: The other half of the question. Know when to cite it and what the skeleton looks like.
- 3Pattern
Fan-out: on write vs on read
Where does the work live — at write time (push to every follower's inbox) or at read time (gather from each followed user)? Both break at the extremes; hybrids win.
Why this, here: The Twitter / feed question in distilled form. Hybrid is the senior answer.
Checkpoint
Halfway check: given a prompt for an Instagram-scale feed, would you choose push, pull, or hybrid — and what tips the decision? If your answer is just “hybrid”, you don’t have the threshold yet.
- 4Pattern
Long-running tasks
Accept work with 202 + job_id, process asynchronously, and let clients track progress via poll, push, or webhook.
Why this, here: Async job pattern is tested in ~1 in 3 rounds. Four pieces, always: job store, queue, worker pool, status channel.
- 5Skill
Failure mode analysis
Systems don't fail because you didn't think they could. They fail the way you failed to think about. Failure-mode analysis is structured paranoia — and interviewers grade on whether you can produce it on demand.
Why this, here: Your design will be pressure-tested on "what fails". Have the per-component breakdown ready.
Checkpoint
Rehearse aloud: for a read-heavy system with cache + DB + replica, name one failure mode per component and one mitigation. Time yourself — staff rounds want this in under a minute.
- 6Skill
Consistency trade-offs
CAP is not a trivia question. It's the trade-off that every distributed system lives under, and getting it wrong is how you end up with "strong consistency" backed by a single node — or "eventual consistency" on data that absolutely cannot be eventually wrong.
Why this, here: PACELC per data class, not per system. Most candidates fumble this.