How the interviewer opens it
“Design a service that detects spelling errors in search queries and suggests or applies corrections. The service works with an existing search system.”
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
- Product and language
- Query traffic
- Query size
- Vocabulary
- Read:write mix
- Latency
- Actions and accuracy
- Consistency and availability
- Freshness and durability
- Data, privacy, and 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
- Detect probable spelling errors in English search queries.
- Return a correction, offer a suggestion, or keep the query unchanged.
- Keep the original query available after any correction.
- Add new names and terms without a service restart.
Usually out of scope
- Build the search index or the document ranker.
- Translate queries.
- Rewrite queries for grammar or style.
- Build a separate model for each user.
What interviewers ask about
- Meaning of a query
- A nearby common word is not always the intended word. A rare name can look like a spelling error.
- Response time under load
- Each token can produce many candidates. Full query combinations can exceed the time budget even when the vocabulary fits in memory.
- New names and terms
- New names must become visible quickly. Untrusted query counts can also promote errors or abusive terms.
- Evidence that a change helps
- Clicks do not prove that a correction preserved intent. Automatic changes also alter the data that future models learn from.
Common mistakes
- The design treats dictionary membership as a complete test for spelling errors.
- The service chooses the nearest common word without considering the full query.
- The service applies every proposed correction without checking accuracy or preserving the original query.
- The design ignores candidate growth across several tokens.
- The service learns directly from query volume without controls for abuse or previous corrections.
- The evaluation measures correction volume instead of accuracy, coverage, and harm to valid queries.
The bar by level
- Senior (L5/E5)
- Controls expansion across tokens and meets the latency budget. Defines action thresholds and evaluation groups. Handles durable updates, compatible releases, and rollback.
- Staff (L6+/E6+)
- Defines measurable harm limits for valid queries and rare names. Designs experiments that account for feedback bias. Balances freshness, abuse resistance, memory cost, and availability.