Technical design of a Google app that alerts shoppers to deals at nearby stores

This is a technical case for a product manager at Google. Google wants to build **Google Local Offers**, which the interviewer describes as a phone app that sends the user a push notification about a store's discount when the user is near that store. Explain how you would build it technically, working through the parts below. ### Clarifying Questions - Is only the shopper's app in scope, or also the tools merchants use to create offers and check redemptions? - How close should a shopper be before an alert fires: within walking distance on the same street, right outside the entrance, or inside the store? - Does "interfaces" mean the screens people see, the APIs between the app and Google's servers, or both? - How is a discount redeemed: by showing a code at the register, through a payment card linked to the offer, or some other way? ### Part 1 — Technical components and workflow List the components the product needs, both on the phone and on the server side, and walk through the workflow from a store publishing a discount to a nearby shopper receiving and using it. ```hint Follow one offer end to end Trace a single discount from the moment a merchant creates it to the moment a shopper standing outside the store sees it on their lock screen. Each point where data moves or a decision gets made is a candidate component. ``` #### What This Part Should Cover - Which work happens on the phone and which on the server, with a reason for each split. - How the system detects that a shopper is near a store and decides to alert them. - How offers are created, kept current and redeemed. ### Part 2 — What to store on the phone Decide what the app keeps in the phone's local storage, and what it should deliberately not keep there. ```hint Think about the moment of the alert The app often has to act while running in the background with a weak connection. Ask what it must already know at that moment, and which data would hurt the user if the phone were lost or the data leaked. ``` #### What This Part Should Cover - Each locally stored item, justified by speed, offline use, battery or privacy. - How cached data is bounded in size, refreshed and expired. - How sensitive data, especially location, is minimized and protected. ### Part 3 — Interfaces Identify the interfaces the product needs and describe what each one looks like and contains. ```hint Count everyone who touches the system The notification is the most visible surface, but list every person and system that has to interact with Local Offers, and what each needs to see, send or receive. ``` #### What This Part Should Cover - The shopper-facing surfaces, starting with the notification, and the information and actions on each. - Controls that let shoppers manage permissions, alert volume and their data. - The merchant-facing or service interfaces, with their main inputs and outputs. ### Part 4 — Risks What risks would the product run into, and how would you reduce each one? ```hint Look beyond the code Some risks are technical, such as battery use and location accuracy. Others come from shoppers' trust, from merchants, and from the operating systems that control background location access. ``` #### What This Part Should Cover - Technical risks, each with a concrete mitigation. - Risks to user trust, such as privacy and notification fatigue. - Merchant, fraud and business risks. ### What a Strong Answer Covers - A stated scope and a definition of success that the technical choices serve. - Consistent handling of the tension between battery life, location accuracy and privacy across all four parts. - Explicit trade-offs between doing work on the phone and doing it on the server. - A sense of what belongs in a first version and how the live system would be measured. ### Follow-up Questions - Phone operating systems cap how many geofences one app can monitor at once. How would you choose which stores to watch for a shopper on a crowded shopping street? - How would you show merchants that an alert caused a sale, rather than reaching someone who was walking into the store anyway? - A store's discount runs out minutes after a shopper was alerted. How should the system and the shopper's experience handle it?