How the interviewer opens it
“Design a dating app like Tinder. Users see nearby profiles one at a time, swipe left or right, and get a match when both people swipe right on each other.”
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
- scale
- read:write mix and payloads
- discovery rules and location
- swipe and match semantics
- latency
- consistency versus availability
- blocking and privacy
- durability and deployment
- ranking and exhaustion
- notifications and scope
The answers stay with the interviewer. In a SysRound round, Alex answers them as an interviewer would.
Scope of a strong answer
Core requirements
- Maintain a profile, discovery preferences, and current approximate location
- Discover nearby eligible profiles while excluding previous swipes, existing matches, and blocked users
- Record left and right swipes and create a durable match when both users like each other
- List matches, notify users, and support blocking and account deletion
Usually out of scope
- Chat and message delivery
- Paid features, boosts, and swipe undo
- Training a recommendation model
- Building authentication, a moderation pipeline, or a push notification provider
What interviewers probe
- Finding fresh nearby profiles without unbounded scanning
- Geographic density varies enormously, users move between cells, and long-lived users exclude most nearby candidates. A fast radius query alone does not produce a useful page.
- Creating one durable match under concurrent swipes and retries
- If opposite-direction likes live on different shards, both requests can commit and then check stale state, causing a missed match. Retries and crashes can also duplicate match records or lose notifications.
- Blocking and deletion across cached discovery and match views
- Discovery and match lists benefit from caches and asynchronous indexes, but stale eligibility can expose someone to a person they blocked. Location data also creates a safety risk that ordinary cache staleness rules do not address.
Common mistakes
- Spending most of the interview on recommendation models or chat instead of discovery and reciprocal matching.
- Treating a geographic cell as an exact distance boundary or ignoring location freshness.
- Ignoring the size and lookup cost of left-swipe history because only right swipes seem important.
- Storing the two likes independently and overlooking the concurrent-read race that can miss a match.
- Acknowledging swipes before durable storage or publishing match events without a crash-safe handoff.
- Treating blocks like ordinary eventually consistent preference filters.
The bar by level
- Senior (L5/E5)
- Drives the scale and consistency discussion. Designs bounded candidate retrieval with history membership checks, handles simultaneous likes and expired decisions, and makes match publication crash-safe. Accounts for stale locations, history lag, blocking, and derived match lists without putting every operation in one global transaction.
- Staff (L6+/E6+)
- Defines the consistency boundary for each user-visible promise and proves it through concurrent swipes, blocks, crashes, and delayed events. Quantifies history and candidate-filtering costs, addresses geographic skew and index repair, and explains how pair ownership, user-centric indexes, and privacy checks evolve across regions without claiming impossible recall or exactly-once external delivery.