You are designing a mobile app for travelers who have free time during an airport **layover**. The app should recommend useful activities the traveler can do before their next flight — eating, shopping, resting, working, walking around, or visiting nearby attractions if time permits. The interviewer **intentionally provides very few requirements**: no explicit latency target, scale target, accuracy target, feature scope, or business model. This is deliberate — the question is as much about *product sense* and *handling ambiguity* as it is about architecture. (Context: this round paired an engineering candidate with a PM interviewer, so the bar is "can you go from $0 \to 1$ on an underspecified product, prioritize, and iterate," not "draw the most boxes.") Walk through how you would approach the design end to end, from product framing to system components to how you would evolve it. Treat the core constraint that makes this product hard — **a recommendation that causes someone to miss their flight is a catastrophic failure** — as the thing your design must protect against. ```hint Where to start The interviewer left it open on purpose. Before drawing any boxes, decide what to do about the missing requirements — there's a better move than guessing silently. ``` ```hint The core abstraction Reframe the user's real question: it's not "what's at this airport?" but something constrained by their flight. What single quantity, derived from the itinerary, should every candidate activity be checked against — and is it really time-to-*departure*? ``` ```hint Recommendation engine You don't need ML to ship something good and trustworthy here. Think about what makes a recommendation *trusted* on a layover, and whether "could this cause a missed flight?" belongs in the ranking score or somewhere stricter. ``` ```hint Pitfalls to call out When data is missing or money enters the ranking, which direction should the system err? Name a couple of trust traps and a coverage decision you'd defend. ``` ### Constraints & Assumptions State your own explicitly — that is part of the answer. Reasonable defaults to anchor on: - **User context the app can know:** arrival airport/time, connecting departure time, boarding time (when available), current terminal/gate, departure terminal/gate, whether security/immigration must be re-cleared. - **Scope for v1:** a handful of large airports with good data; in-airport recommendations only; leaving-the-airport options gated behind a long-layover threshold. - **Failure asymmetry:** a missed flight is far costlier than a missed recommendation — the system should bias conservative. - **No hard NFR targets are given** — you are expected to *propose* sensible ones (e.g. recommendation request P95 in the low hundreds of ms; flight-status freshness on the order of a minute) and justify them, not invent precise SLAs from the company. ### Clarifying Questions to Ask - Who is the target user — leisure, business, families, premium/lounge travelers, international connections, or all of them? - Is the app strictly in-airport, or can it recommend activities outside security/the terminal during long layovers? - Does the app ingest the user's itinerary automatically (airline integration, boarding-pass scan, calendar) or is it manual entry? - Which airports must v1 cover, and how good is the underlying map / merchant / hours data for them? - What is the business goal — engagement, affiliate/ordering revenue, lounge bookings, airport partnerships, or pure traveler experience? - Should recommendations be informational only, or transactional (book / order / reserve / navigate)? ### What a Strong Answer Covers - **Ambiguity handling:** explicitly names the open requirements, asks scoping questions, then commits to stated assumptions rather than silently guessing. - **Product framing:** a crisp problem statement, primary goal, and explicit *non-goals* for v1; demonstrates prioritization, not feature-listing. - **The layover model:** treats remaining time-to-boarding as a budget; accounts for walking time, wait/queue time, business hours, security/immigration re-entry, and gate-change/delay risk. - **Recommendation pipeline:** candidate generation → hard feasibility filter → ranking, with the feasibility math and the ranking signals made explicit; justifies rules-before-ML. - **System decomposition:** client, backend/API, flight-status integration, airport-content store, recommendation service, map/routing, notifications, plus the data-store choices and why. - **Safety & trust as first-class:** conservative defaults under missing data, explainable "why this is safe" output, time-to-leave alerts, and a graceful "stay near your gate" fallback. - **Metrics across dimensions:** product/engagement, safety (near-misses, buffer adequacy, estimate accuracy), business, and system health. - **Evolution:** a phased roadmap from rules-based MVP → real-time context → personalization → transactions/partnerships, with the tradeoffs at each step. ### Follow-up Questions - The user's flight is delayed by 90 minutes *while they're mid-activity*. How does the system detect this and re-plan the recommendation in real time? - Your walking-time estimates are systematically optimistic and a cluster of users report nearly missing flights. How do you detect this from telemetry, and what do you change in the feasibility model? - A merchant pays for placement. Design the ranking so business priority can influence results *without* ever surfacing an unsafe or irrelevant option — and describe how you'd prove to the business it isn't tanking trust. - A long international layover requires re-clearing immigration and security to leave the terminal. How does your feasibility model and your "leave the airport?" decision change versus a short domestic connection?