How the interviewer opens it
“Design an on-call escalation system like PagerDuty. It receives alerts, pages the right on-call engineer, and escalates to the next person if nobody acknowledges in time.”
The prompt is vague on purpose. The first few minutes are yours: narrow it to the core features and agree on the numbers before you draw anything.
What to clarify first
- scale and read:write mix
- alert identity and lifecycle
- escalation policy
- on-call schedules
- acknowledgement and consistency
- latency and availability
- durability and deployment
- notification providers
- payload size and retention
- scope boundaries
The answers stay with the interviewer. In a SysRound round, Alex answers them as an interviewer would.
Scope of a strong answer
Core requirements
- Receive alerts and group repeated triggers into an active incident
- Choose responders using on-call schedules and an escalation policy
- Send pages and escalate when acknowledgement deadlines pass
- Acknowledge or resolve incidents and retain their history
Usually out of scope
- Detecting failures or building monitoring agents
- Automatic incident remediation
- Building SMS, voice, or push delivery networks
- Billing and workforce-management features
- Automatic resolution from monitoring recovery events
What interviewers probe
- Alert replay versus incident grouping
- A transport retry must do nothing new, while a different alert can legitimately join an incident or open another one after resolution. Confusing these identities either loses incidents or pages repeatedly during an outage.
- Durable deadlines and acknowledgement races
- Escalation is delayed state-changing work. Workers can restart, deadlines can be processed twice, and an acknowledgement can arrive while a timeout is being handled.
- Choosing the right responder at schedule boundaries
- The target is a function of time, local calendar rules, overrides, and escalation progress. Routing errors can look like successful delivery while paging the wrong person.
- Delivery uncertainty without losing escalation
- An SMS timeout cannot distinguish a rejected message from an accepted message with a lost response. Blind retries can harass responders, but waiting indefinitely can miss the incident.
Common mistakes
- Treating a page as a fire-and-forget queue message rather than part of an incident state machine.
- Keeping escalation deadlines only in worker memory or relying solely on TTL-expiration notifications.
- Confusing event deduplication, active-incident grouping, and notification retry identity.
- Ignoring the race between acknowledgement and timeout advancement.
- Treating provider acceptance or delivery as human acknowledgement.
- Spending the interview on generic microservices or sharding while leaving schedule boundaries and provider failures undefined.
The bar by level
- Senior (L5/E5)
- Defines lifecycle semantics before drawing components. Handles event replay separately from incident grouping, makes state changes and notification work atomic, serializes acknowledgement against timeout processing, and explains provider ambiguity, schedule handoffs, and bounded retries. Uses the given scale to justify a straightforward durable database-backed design.
- Staff (L6+/E6+)
- Establishes precise guarantees at intake, state transition, dispatch, and provider boundaries without claiming exactly-once human notification. Quantifies outage catch-up and provider capacity, protects tenants from alert storms, and reasons about regional ownership and fencing during failover. Makes explicit decisions about overdue work, emergency policy changes, schedule gaps, and the operational evidence needed to prove why someone was or was not paged.