Katkat
Back

Schedule Welcome and Expiration Emails from Subscription Records

StripeSoftware Engineer · Technical Screen
MediumSoftware EngineerTechnical ScreenSoftware Engineering Fundamentals

Last updated

A programming exercise that turns customers' subscription records into a chronological schedule of lifecycle emails, such as a welcome email at the start and an expiration email at the end. It tests date arithmetic, deterministic ordering of same-day emails, and a rule design that makes new email types easy to add.

A subscription service sends automated emails at set points in each customer's subscription, such as a welcome email when the subscription starts and an expiration email when it expires. Write a program that takes the customers' subscription records and produces every email that must be sent, in the order the emails will go out.

Assume each record gives a customer name, the subscription start date, and the subscription length in days. The interviewer supplies the real input format. The output is a list of (send date, email type, customer) entries sorted by send date.

For example (illustrative values), a customer whose 30-day subscription starts on March 1 gets a welcome email on March 1 and an expiration email on March 31.

Constraints and Clarifications

  • Assume a subscription expires on its start date plus its length in days.
  • Dates are calendar dates. Use a date library for the arithmetic rather than hand-rolled day counting.

Clarifying Questions

  • Which email types exist besides welcome and expiration, and when is each one sent relative to the start or the end? For example, is there a reminder before expiry?
  • How should emails with the same send date be ordered: by email type, by customer, or by input order?
  • Can a subscription change (renew, upgrade, cancel) after it starts? If so, how is that change given to the program?
  • Should the program print the schedule, return it, or actually send each email at the right time?

Hints

Hint 1

Turn records into dated events: Think of each subscription as producing a small set of dated events, and ask what single ordering over all customers' events gives the required output.

Hint 2

Keep the email rules out of the loop: More email types are likely to be added once the first version works. Consider how to describe "which email, relative to which moment" so that adding a new type is a data change rather than new control flow.

Follow-up questions

  • Add a reminder email a configurable number of days before expiration. What changes, and what should happen when the subscription is shorter than that notice period?
  • Customers can now change plans or renew partway through. How do you cancel or reschedule emails that were already planned?
  • Subscription events now arrive over time instead of as a batch, and each email must go out at its send time. How would you structure the scheduler, and how would you avoid sending an email twice after a crash?