How the interviewer opens it
“Design a service that searches source code across many repositories. Users need text search, symbol search, and repository filters, with current results that respect repository permissions.”
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
- Corpus size
- Search behavior
- Traffic and read:write mix
- Latency and expensive queries
- Freshness and consistency
- Repository changes
- Repository permissions
- Durability and availability
- Result details
- 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
- Search literal text and symbol definitions across repositories.
- Filter results by repository, path prefix, and language.
- Keep search results current as code changes.
- Return results only from repositories that the user can access.
Usually out of scope
- Repository hosting and code edits
- Code execution and build services
- Semantic search with embeddings
- Historical search across all commits
- File-level permissions
What interviewers ask about
- Text and symbol results
- Code contains punctuation and partial names. Short queries match many files, while case rules can change which matches the service returns.
- Code changes
- Events can repeat or disappear. Search must publish complete repository states while keeping branch-head lag within the target.
- Repository access
- Search can reveal private code through snippets, names, counts, or cached responses. Access revocation must take effect independently of code changes.
- Search across many repositories
- Broad queries can contact many shards. One slow shard can dominate latency, while common terms can consume most search capacity.
Common mistakes
- Use a text index without clear rules for punctuation, short queries, and case matches.
- Treat symbol search as plain text search.
- Update files separately without complete repository snapshots or deletion rules.
- Define freshness per commit, then skip commits without a branch-head lag rule.
- Tie access revocation to code freshness or share cached results across different access scopes.
- Ignore query fan-out or hide partial results after a timeout.
The bar by level
- Senior (L5/E5)
- Handles short and case-insensitive queries. Publishes complete repository snapshots despite late events and force pushes. Prevents cache leaks and bounds query cost.
- Staff (L6+/E6+)
- Defines access and snapshot rules across failures. Quantifies branch-head lag, recovery capacity, and query fan-out. Adapts repository placement without weakening those rules.
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 code search engine like GitHub search
Reported date not specified
Source snapshot: Nov 12, 2026
View source