How the interviewer opens it
“Design a calendar app like Google Calendar. Users should be able to create events, invite others, check free/busy times, and get reminders. Include recurring events and time zones.”
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 stored data
- traffic and read:write mix
- events and invitations
- recurrence and time zones
- query density and work limits
- free/busy, privacy, and result size
- latency and overload behavior
- consistency, durability, and deployment
- reminders
- 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
- Create, edit, and cancel one-time and recurring events, including single-occurrence exceptions
- Invite users and record their RSVP responses
- List calendar events and query authorized users' free/busy intervals
- Deliver reminders that account for rescheduling, cancellations, and time zones
Usually out of scope
- External calendar federation and email invitation interoperability
- Shared-calendar editing and room or resource reservations
- Building push notification infrastructure
- Authentication implementation, attachments, and full-text search
- Multi-region writes and regional ownership transfer
What interviewers probe
- Recurring event identity and time-zone semantics
- A recurring event is a local-time rule, not an infinite list of UTC timestamps. Moving one occurrence must not lose its identity, leave the original behind, or make it invisible to queries of its new date.
- Correct and bounded free/busy queries
- One request can span 20 calendars, 90 days, recurring rules, and moved exceptions. Both computation and response size need bounds; returning a fast but incomplete empty result can cause users to schedule over existing meetings.
- Reminders under edits, retries, and outages
- Reminder times come from mutable schedules and potentially infinite series. Sending is an external side effect that cannot generally be committed atomically with calendar state.
- Invitation state and concurrent changes
- Organizer edits and attendee responses change different state. Asynchronous fanout must not let an old RSVP or delayed update restore a cancelled event or a removed invitation.
Common mistakes
- Treating recurring events as fixed UTC timestamps separated by a constant number of seconds.
- Materializing unbounded series or using only a rolling horizon with no far-future query path.
- Ignoring moved exceptions, all-day date semantics, or intervals that begin before the query window.
- Promising the read latency target without bounding recurrence work, output size, and cross-calendar fanout.
- Treating free/busy as a reservation guarantee or interpreting partial and failed results as availability.
- Publishing invitations or reminders separately from database commits without recovery, or claiming exactly-once external notifications.
The bar by level
- Senior (L5/E5)
- Establishes canonical event ownership, separate attendee state, durable mutation-to-worker delivery, permission checks, and authoritative versus projected reads. Handles stable occurrence identity and bounded recurrence expansion. In the selected free/busy dive, quantifies density, overlap, pagination, and cold-query work; in the selected reminder dive, handles stale jobs, retries, burst capacity, and external-delivery limits. Assess the selected dives deeply rather than requiring every probe from all four.
- Staff (L6+/E6+)
- Defines invariants and product policies before mechanisms, separates schedule, RSVP, and permission consistency, and identifies where stale or partial data would be unsafe. Connects the workload bounds to a credible latency and capacity plan, including far-future computation, admission limits, and recovery of derived state. For 45 minutes, use roughly 5 minutes for scoping and estimates, 10 for APIs/model/architecture, 10 for recurrence, 10 for either free/busy or reminders, 5 for an invitation failure or one follow-up, and 5 for synthesis. Do not require all four full deep dives. Series splitting, time-zone-rule migration, and regional ownership transfer are evaluated only when their corresponding follow-up is explicitly asked; none is a baseline pass requirement.