How the interviewer opens it
“Design a service that finds users whose behavior resembles an advertiser's seed audience. The service must respect user consent and exclude sensitive targeting attributes.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
What to clarify first
- Seed audience
- Audience scale and refresh
- Events, retention, and durability
- Read and write traffic
- Consent, audience status, and availability
- Allowed data and revisions
- Model and relevance
- Advertiser reports
- Request controls
- Access and scope
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
Scope of a strong answer
Core requirements
- Create an audience from an advertiser's approved seed audience.
- Refresh audience membership daily.
- Check audience eligibility during an internal ad request.
- Enforce consent, audience status, and sensitive data rules.
Usually out of scope
- Match advertiser identities to platform identities.
- Design the similarity model.
- Design auctions, bids, or billing.
- Export user lists to advertisers.
What interviewers ask about
- Audience refresh deadlines
- Thousands of audiences share the same user population. Each job must finish on time without publishing partial results or results from obsolete configurations.
- Audience relevance
- The approved model supplies similarity scores, not proof of useful future behavior. The service must measure relevance without future data leakage.
- Consent and audience status
- Stored membership can outlive consent or audience approval. Every ad decision needs current permission despite cache delays, regional failures, and restored data.
- Sensitive data and advertiser access
- Approved behavior can correlate with sensitive traits. Repeated seed changes can reveal information, while policy changes can invalidate existing audiences and unfinished jobs.
Common mistakes
- Designs the similarity algorithm but omits the audience data flow and eligibility API.
- Runs a separate raw event scan for each audience without estimating the work.
- Treats stored membership as permission despite consent withdrawal, an audience pause, or a policy disable.
- Rejects old job attempts but permits publication from obsolete seed, configuration, or policy versions.
- Assumes that removal of explicit sensitive attributes also removes sensitive proxies.
- Exposes exact counts or user-level membership through advertiser reports.
The bar by level
- Senior (L5/E5)
- Estimates shared computation and membership traffic. Explains candidate selection, relevance tests, atomic publication, and recovery. Rejects obsolete seed and policy jobs. Bounds consent and status cache delays. Enforces seed minimums and report controls.
- Staff (L6+/E6+)
- Defines control ordering across policy changes, publication, caches, and recovery. Proves permission deadlines under regional failures. Traces deletion through retained data. Explains privacy limits under repeated requests. Balances recall, refresh cost, and advertiser fairness with measurable limits.
Sources · 1 reference
These records explain where the question appears. A company tag or candidate report does not guarantee a future interview question.
SysRound · 1 record
No company association
Design a lookalike audience targeting system
Reported date not specified
Source snapshot: Nov 12, 2026
View source