How the interviewer opens it
“Design a search service that adapts results to a user's preferences and recent activity. Keep results relevant to the current query. Support users with little history and respect their privacy choices.”
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
- Domain and scale
- Traffic and read:write mix
- Latency and freshness
- Query relevance
- Signals and sparse histories
- Privacy
- Consistency and availability
- Durability and event delivery
- Quality evidence
- Exclusions
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
- Return relevant search results that respect the user's filters.
- Adapt result order to consented preferences and recent activity.
- Use explicit preferences even when the user has no activity history.
- Honor consent withdrawal, retention limits, and deletion requests.
Usually out of scope
- Build the base text search engine.
- Serve ads or recommendations outside search.
- Infer sensitive traits.
What interviewers ask about
- Query relevance and user preferences
- A user's past interests can conflict with the current query. More clicks can hide worse search results.
- Preferences and sparse histories
- Explicit preferences can exist before any activity. Sparse histories can reflect temporary needs instead of lasting interests.
- Consent and deletion
- Old events can survive consent withdrawal and later consent renewal. Delayed work must not restore personal data without valid consent.
- Search latency
- Personalization adds data access and score computation to every search. A slow activity read must not discard available preferences or delay useful results.
Common mistakes
- The design lets past interests override an exact query or a hard filter.
- The design treats click rate as the only measure of search quality.
- The design ignores saved preferences when the user has no activity profile.
- The search path reads raw histories or makes a remote call for each candidate.
- The privacy plan deletes activity profiles but ignores preferences, logs, derived features, offline copies, and backups.
- The service trusts stale consent or assigns new consent epochs to old events.
The bar by level
- Senior (L5/E5)
- Defines event deduplication, feature age, and request deadlines. Preserves available preferences during activity failures. Binds events to their original consent period. Prevents consent races and rejects stale work. Separates relevance tests from click gains.
- Staff (L6+/E6+)
- Demonstrates deletion deadlines across offline jobs, backups, and derived data. Defines safe recovery after deletion. Addresses exposure bias and experiment validity. Justifies quality, latency, and cost choices. Cross-region consent remains an optional extension.
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 personalized search ranking system
Reported date not specified
Source snapshot: Nov 12, 2026
View source