The exercise: design a notification service
This original practice scenario asks you to design a service that sends order-status notifications by email and push. Users can change channel preferences. Delivery providers can fail, and duplicate notifications are undesirable. Begin without a fixed traffic estimate: your first job is to ask what scale and guarantees the interviewer expects.
This is deliberately narrower than “design a social network.” It gives you room to explain requirements, data flow, failure handling, and tradeoffs within one session. No particular database or queue is required to pass the practice exercise.
Use this AI interviewer prompt
Act as a system design interviewer for a mid-level backend role. Ask me to design an order-status notification service. Ask one question at a time and wait for my answer. Do not propose an architecture before I do. When I make an assumption, ask why it matters. Introduce a provider outage and a duplicate event later. After the exercise, assess my reasoning using requirements, data flow, failure handling, tradeoffs, and communication. Identify unsupported claims. Do not invent company-specific interview standards.
Change the level to match your target role. If the assistant starts giving a full solution, interrupt and ask it to return to questions. The exercise loses much of its value when you only agree with an architecture someone else supplied.
A 45-minute agenda
| Time | Your objective | Evidence to produce |
|---|---|---|
| 0–5 minutes | Clarify requirements | Channels, scale assumptions, delivery expectations |
| 5–12 minutes | Define interfaces and data | Event shape, preferences, delivery record |
| 12–25 minutes | Explain the main flow | Accepted event through delivery attempt |
| 25–35 minutes | Handle failures | Retry, duplicate, and outage reasoning |
| 35–40 minutes | Defend tradeoffs | One rejected alternative and why |
| 40–45 minutes | Debrief | Two specific improvements for next time |
Follow-ups that expose shallow reasoning
Ask what happens if a provider accepts a message but the worker times out before recording success. Where would you track an attempt? What information could make a retry safer? Avoid claiming that simply adding a queue automatically guarantees exactly-once delivery.
Then change a requirement: a user disables push notifications after the event arrives but before delivery. Should the system use preferences from event time or delivery time? Either policy needs a clear product decision. Explain how your data model and processing flow support the chosen rule.
Finally introduce a long provider outage. Discuss how you would bound retries, identify stale messages, and let operators understand the backlog. State what you would monitor and what action each signal should trigger.
Score decisions, not the number of components
Give yourself zero, one, or two points in five areas: requirements, coherent data flow, failure handling, explicit tradeoffs, and clear communication. Zero means omitted, one means named but not explained, and two means justified with a concrete example. This is a practice rubric, not an employer’s hiring threshold.
Write the weakest answer again without adding new infrastructure. Often the improvement is a clearer assumption or failure sequence. Repeat a smaller follow-up the next day. You can use typed prompts in Cluegent for this question-and-answer routine; the timed agenda here is a manual practice method, not a claim of an automated Cluegent scoring feature.
Where Cluegent helps
Cluegent supports permitted live workflows with transcript context, typed prompts, screenshot-aware answers, resume context, custom response behavior, quick action buttons, and a private desktop overlay. It is most useful when you already understand the subject and need help staying structured under pressure.
Frequently asked questions
Should AI generate the system design first?
Not for this exercise. Propose your own design, then ask the assistant to challenge assumptions and failure cases. Compare alternatives after you have explained your reasoning.
How do I know whether the AI feedback is correct?
Treat feedback as a hypothesis. Check technical claims against authoritative documentation and work through concrete event sequences yourself.