How the interviewer opens it
“Design an ads management and display system for a social feed. Advertisers should be able to create campaigns with budgets and targeting, and people browsing the feed should see relevant ads without campaigns overspending.”
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
- serving scale
- read:write mix
- targeting and relevance
- latency
- pricing and billable impressions
- budget consistency and availability
- updates and pause behavior
- durability and reporting
- deployment
- 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 and update campaigns, creatives, targeting rules, daily budgets, and active or paused status
- Choose an eligible, relevant ad for a feed slot
- Authorize delivery without exceeding a campaign's daily budget
- Record billable impressions once and provide basic spend reporting
Usually out of scope
- Building or training a ranking model
- Real-time bidding and auction pricing
- Advertiser payments and invoicing
- Creative moderation and sophisticated fraud detection
- Conversion attribution
- Multi-region serving for v1
What interviewers probe
- Hard budget caps under concurrent delivery
- Thousands of serving workers can select the same campaign before any impression is reported. Checking an asynchronous spend total allows all of them to spend the same remaining money.
- Impression settlement, retries, and expiration
- Serving an ad is not the same as displaying it. Some deliveries never render, callbacks arrive late or twice, and expiration races with charging.
- Relevant selection within a tight serving deadline
- The system has a million active ads, but only 50 ms to obtain user features, find eligible candidates, rank them, and authorize money. Exhausted campaigns and skewed targeting can waste most of that work.
- Campaign changes across cached serving state
- Eligibility indexes need local copies for speed, but advertisers expect pauses, targeting changes, and budget edits to take effect promptly. A delayed control update must not become permission to keep spending.
Common mistakes
- Spends most of the interview on advertiser CRUD and ranking while leaving budget enforcement as an asynchronous counter.
- Confuses a successful ad response with a billable impression and never defines the reservation lifecycle.
- Calls serving read-heavy without counting the financial writes on delivered ads.
- Uses floating-point money, non-idempotent retries, or independent counters that can collectively exceed the cap.
- Treats budget expiration, campaign pause, and UTC day rollover as cache invalidation alone.
- Adds auctions, model training, and multiple regions before solving the fixed-price, single-region money invariant.
The bar by level
- Senior (L5/E5)
- Owns the complete money lifecycle and failure cases: retries, lost responses, expiration versus billing, budget decreases, and midnight. Sizes serving and accounting separately, keeps selection within a deadline, and gives a concrete plan for campaign updates and hot-budget contention.
- Staff (L6+/E6+)
- Makes the financial invariant explicit across owners, delegated quota, failover, and configuration changes. Explains when stranded quota and underdelivery are necessary for safety, and when batching or delegation is worth the operational cost. Connects strict budget policy, late-event billing rules, freshness guarantees, and regional failure behavior rather than promising all of them independently.