Explaining How a Product You Worked On Is Built: Components, Data Flow and Trade-offs
Company: Amazon
Role: Product Manager
Category: System Design
Difficulty: medium
Interview Round: Other
Pick a product you have worked on and explain to the interviewer how it is built: its main components, how they connect and how data moves between them.
```hint Follow one action through the system
After sketching the big pieces, take the single most important thing a user does and trace it from the screen through each service and data store it touches.
```
### Clarifying Questions
- Should I use the product I work on now, or any product I know well enough to describe in depth?
- How deep should I go: a component-level overview, or down to data models and specific technologies?
- Some details are confidential. Is a generalized view with generic component names acceptable?
- May I sketch a diagram as I talk?
### What a Strong Answer Covers
- A layered map of the system: clients, entry points, core services, data stores and outside dependencies
- One key user flow traced end to end, showing where data is read and written
- The main technical trade-offs and constraints, and how they shaped product decisions
- How the system copes with load and failures, and how it is monitored
- The candidate's own part in technical decisions, explained at a depth that suits a product manager
### Follow-up Questions
- Which part of this architecture most limits what the product can do next, and what would changing it cost?
- Tell me about a time a technical constraint changed your roadmap.
- If traffic grew tenfold overnight, what would break first, and how would you know?
Overview: A technical product manager interview prompt asking the candidate to explain how a product they worked on is built. It tests whether they can map the main components and data flows, trace a key user action end to end, and explain the trade-offs, scaling and failure handling that shaped the product.
