Machine coding round
Notification System Coding Interview Problem
What this interview round tests
Design a notification system is one of the most asked backend interview questions anywhere, because every product has one and almost every implementation has shipped the same three bugs: a user notified on a channel they muted, a promotion delivered at 2 a.m., and the same message sent twice because a retry fired. This problem is those three bugs, handed to you as failing tests.
The domain layers three decisions in front of every send. Preferences: does this user accept this notification type on this channel? Quiet hours: is the user inside a do-not-disturb window, and is this message urgent enough to pierce it? Idempotency: has this event already produced this notification once? Interviewers use the problem because each decision is a policy that must live in one place — candidates who scatter the checks across call sites produce exactly the duplicate-send and midnight-promo bugs the tests encode.
The scenario
You are handed the notification service of a consumer backend: events come in, user preferences and quiet hours are consulted, and notifications go out on email, SMS, or push. Everything is wired — and the test suite documents how much of it misbehaves.
Muted channels still receive sends, quiet hours suppress critical alerts and let promotions through, redelivered events notify users twice, and suppressed notifications vanish without a trace instead of being recorded. Your job is to make every delivery decision honour preferences, time windows, and replay safety.
What you’ll practice
- Preference evaluation: per-user, per-type, per-channel opt-ins in one policy point
- Quiet hours: time-window suppression, including windows that cross midnight
- Priority overrides: critical notifications that legitimately pierce quiet hours
- Idempotent delivery: one notification per (user, event), retries included
- Suppression as an outcome: recording why a notification did not go out
- Deterministic multi-channel fan-out for a single event
How to approach it
Funnel every send through one decision pipeline: dedupe first (has this user–event pair been handled?), then preferences, then quiet hours with the priority exception. The order matters — deduping last means a retried event re-runs the policy and can double-send; preferences after quiet hours means recording the wrong suppression reason. Fix the order once, in one place.
The quiet-hours check deserves respect: windows like 22:00–07:00 wrap midnight, so a naive start < now < end comparison silently never matches. Normalise the comparison, inject the clock so tests control time, and record every suppression with its reason — a notification system that cannot explain why it stayed silent is as broken as one that spams.
The starter repository ships with a failing test suite and a bundled verify.sh. Reviewed reference solutions are part of Gronex Pro — this page stays spoiler-free on purpose.
FAQ
Why is a notification system a common interview question?
Because it looks like plumbing and grades like design. Preferences, quiet hours, and dedupe are three separate policies that must compose in a fixed order for every send — which tests exactly the skill backend interviews target: putting rules in one enforceable place instead of sprinkling ifs at call sites.
What is the classic quiet-hours bug?
Windows that cross midnight. A 22:00–07:00 window fails a naive range check because the start is "after" the end, so the do-not-disturb feature silently never activates — or worse, activates for the wrong half of the day. The tests include exactly this window.
Is this problem really free?
Yes. It is one of the free Gronex challenges: open the full brief with no signup, solve it in the browser workspace, or download the starter repo and run the bundled verify script locally in Java, Python, or C++.