Design and Test a Personalized Push Notification System for a News App

You are responsible for recommending notifications in a news app that already has an established audience. Walk the interviewer through the product, the technology behind it, how it decides which notifications to send, and how you would test it. ### Clarifying Questions - Does the app aggregate stories from many publishers, or is it one newsroom's app with its own editors? - Is there an existing notification channel, such as editor-picked breaking-news alerts, that personalized recommendations would extend? - Which channels are in scope: mobile push on iOS and Android only, or also web push and email? - Should notifications mainly bring people back into the app, or is keeping them informed valuable even when they never tap? ### Part 1 — How the product works Describe the notification experience from the user's side: what kinds of notifications the app sends, what they look like, and what control users have over them. ```hint Start from the lock screen List the different reasons a news app has to interrupt someone, then ask what would make that person switch notifications off. ``` #### What This Part Should Cover - Distinct notification types and the user need each one serves - The permission request and the settings that let users shape what they receive - What happens after a tap, and how a missed notification can still be found ### Part 2 — The technology behind it Sketch the main systems and data flows that turn newly published articles and user behavior into a notification on someone's phone. ```hint Follow one story Trace a single article from the moment it is published until it reaches a device, and name each system it passes through. ``` #### What This Part Should Cover - How articles are ingested and understood, and how user activity is collected - Which parts must run in near real time and which can run in batches - How notifications are scheduled and delivered reliably to devices ### Part 3 — How the system decides what to send Explain how the system chooses, for each user, whether to send anything, which story to send, and when. ```hint Sending has a cost Every notification spends some of the user's patience. Consider what the system should weigh besides the chance of a tap. ``` #### What This Part Should Cover - Hard rules that make a candidate ineligible before any scoring - How candidates are scored and what the score trades off - Frequency limits, timing, and the handling of new users with no history ### Part 4 — Testing How would you test the system before launch and after it, and how would you decide it is a success? ```hint Taps can mislead A tapped notification may only replace a visit the user would have made anyway. Think about what each group in a test is compared against. ``` #### What This Part Should Cover - Offline evaluation and functional checks before any user sees a change - The design of the online experiment and its primary metric - Guardrail metrics and how long-term effects are measured ### What a Strong Answer Covers - A clear goal for notifications that balances user value against interruption - A coherent end-to-end design in which product choices, systems and decision logic fit together - Decision logic that accounts for fatigue, relevance, timeliness and story importance - Testing that measures incremental, long-term impact with guardrails - Failure modes such as wrong or retracted stories, duplicate sends and delivery delays ### Follow-up Questions - Suppose open rate improves in the experiment while notification opt-outs creep up over two months. How would you decide whether to keep the new system? - How would you handle a breaking story that is still unconfirmed? - Should a major story on a topic the user never reads ever override their personalization?