The recovery process — four steps:
Step 1: Buy 90 seconds with clarifying questions.
You don’t need to know the answer before you ask the questions. “Let me make sure I understand the scope — are we designing for real-time delivery or batch? How many users at peak?” You’re not stalling — you’re genuinely narrowing the problem while your brain maps the question to the nearest archetype.
Step 2: Name the archetype out loud.
“This sounds like it has the same core tension as a feed fanout system — lots of writes amplifying into lots of reads, with a latency constraint.” If you’re right, the interviewer will nod. If you’re wrong, they’ll redirect. Either way, you’ve signaled you have a framework.
Step 3: Run the 6-step framework on the archetype, not the specific question.
If you’ve identified it as a “real-time messaging” problem, run the messaging framework — WebSocket, delivery semantics, offline handling — and adapt the names to fit the new question.
Step 4: Go deep on the hard part, not the familiar parts.
If you’ve never seen the question before, the interviewer knows it. They’re not expecting a polished answer. They’re watching whether you can reason under uncertainty. Go to the hardest distributed systems problem in the question and show that you can think through it, even imperfectly.
What not to do: Don’t say “I haven’t seen this question before.” It signals that you were expecting to pattern-match, not think. Even if the question is new, treat it as a normal design round and work through it.
CTA: The cohort curriculum is built around recovering when the question is unfamiliar — clarifying the scope, identifying the right system archetype, applying a proven framework, and going deep on the hardest distributed-systems trade-off instead of relying on pattern-matching.
Subscription link
https://systemdr.systemdrd.com/subscribe
Want the full picture?
The premium lessons include advanced insights, practical exercises, and comprehensive walkthroughs.