How the interviewer opens it
“Design a marketplace like Facebook Marketplace. Users should be able to list items with photos, find items for sale nearby, and message sellers.”
The prompt is vague on purpose. The first few minutes are yours: narrow it to the core features and agree on the numbers before you draw anything.
What to clarify first
- product and sale semantics
- scale and deployment
- read:write mix
- photos
- location, filtering, and ranking
- latency and availability
- consistency and durability
- messaging behavior
- identity and access
- scope boundaries
The answers stay with the interviewer. In a SysRound round, Alex answers them as an interviewer would.
Scope of a strong answer
Core requirements
- Create, edit, delete, and mark listings as sold, with photos
- Browse and search nearby listings with text, category, and price filters
- View listing details and current availability
- Start and continue a private buyer-seller conversation about a listing
Usually out of scope
- Checkout, payments, reservations, and shipping
- Auctions, offers, and inventory management
- Building authentication or a social graph
- Full automated moderation and recommendation systems
- Group chat, message attachments, and end-to-end encryption
What interviewers probe
- Nearby search without scanning or unstable pagination
- Distance, text, price, and category filters must work together across 100M active listings. Dense neighborhoods have very different query costs from sparse areas, and changing results complicate pagination.
- Publishing and updating listings across photos, the database, and search
- A listing spans independently failing systems. Publishing too early exposes broken photos, while delayed or reordered index updates can make sold or deleted items reappear.
- Durable messaging with retries, ordering, and reconnects
- Buyers may send from several devices over unreliable connections. Database commits, acknowledgments, and WebSocket delivery can fail independently, so an apparently simple chat needs explicit retry and recovery semantics.
Common mistakes
- Spending the interview building a shopping cart or payment flow instead of nearby discovery and seller messaging.
- Storing or serving photo bytes through the listing database and API servers.
- Choosing separate text and geo stores without explaining how combined filtering and pagination work.
- Treating the search index as authoritative for current status, ownership, or deletion.
- Dual-writing the database and index without replay, versioning, or a repair path.
- Treating WebSocket delivery as durable messaging and ignoring retries, offline history, or participant authorization.
The bar by level
- Mid-level (L4/E4)
- Produces a coherent listing, photo, nearby-search, and messaging flow. Uses object storage and a geo-capable index, distinguishes search results from authoritative listing state, and persists messages with participant checks. Can explain basic retry deduplication and offline history when prompted.
- Senior (L5/E5)
- Drives the scope and capacity estimates. Specifies reliable database-to-index propagation, versioned deletion handling, media publication states, bounded search pagination, and durable per-conversation ordering. Walks through commit-versus-acknowledgment failures and reconnect recovery without promising exactly-once transport.
- Staff (L6+/E6+)
- Separates product guarantees from implementation choices: approximate location, tolerable discovery staleness, authoritative status, and no reservation guarantee. Identifies photo delivery and search as distinct capacity drivers, avoids premature sharding, and gives workable index rebuild, failover, and retention plans. Adapts to safety takedowns or regional ownership by stating which guarantees and costs must change.