How the interviewer opens it
“Design a search autocomplete service. It suggests query completions as users type. It must respond quickly and reflect changes in query popularity.”
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
- Result behavior
- Traffic
- Read and write mix
- Corpus and locales
- Latency
- Relevance and freshness
- Consistency and availability
- Durability
- Phrase eligibility and safety
- Scope limits
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 up to ten query completions that match a prefix and a locale.
- Reflect significant popularity changes within five minutes.
- Admit new phrases after they pass eligibility checks.
- Stop suggestions for a blocked phrase within 60 seconds.
Usually out of scope
- Return search results.
- Build the safety review system.
- Support ads or sponsored suggestions.
- Complete text from documents that users did not submit as queries.
What interviewers ask about
- Results for short prefixes
- A short prefix can match millions of phrases. The service must return relevant results without work that grows with every match.
- Changes in query popularity
- Popularity can rise or fall before the next full refresh. Previous winners alone do not contain every phrase that should replace them.
- Updates during failures
- Servers can receive different updates during a failure. Recovery must preserve complete results without losing changes or restoring stale safety decisions.
- Queries that must not appear
- New phrases have no approved identity yet. Admission must count users across a rolling window without exposing private text or bypassing safety decisions.
Common mistakes
- Count keystrokes as popularity events.
- Scan and sort all matching phrases for every request.
- Store large candidate lists at every prefix without estimating memory.
- Change scores without finding new candidates after previous winners fall.
- Sum distinct users across time buckets without removing duplicate users.
- Treat cached results as exempt from safety blocks.
The bar by level
- Senior (L5/E5)
- Meets latency and freshness targets with bounded reads. Handles score decreases, replacement candidates, event retries, rolling user counts, and safety blocks.
- Staff (L6+/E6+)
- Defines recovery across regions and partial updates. Proves candidate completeness and score authority. Quantifies index and admission costs. Preserves safety deadlines during outages.
Sources · 2 references
These records explain where the question appears. A company tag or candidate report does not guarantee a future interview question.
PracHub · 1 record
Uber
Design a search autocomplete system
Reported Jul 15, 2025
Software Engineer
Source snapshot: Nov 12, 2026
SysRound · 1 record
No company association
Design a search autocomplete system
Reported date not specified
Source snapshot: Nov 12, 2026
View source