How the interviewer opens it
“Design a people search service for a professional network. Members search for people by names, skills, employers, and other filters. The service must respect each profile's visibility rules.”
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
- Search behavior
- Scale
- Read and write mix
- Latency
- Relevance and pages
- Visibility rules
- Consistency and cursor lifetime
- Availability
- Durability
- Existing services 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
- Search profiles by name, skill, employer, and title
- Apply exact filters for the current employer, location, and skills
- Rank results and support multiple result pages
- Enforce profile visibility, connection rules, and blocks
Usually out of scope
- Create or edit profiles
- Build the connection service
- Search contact details
- Recommend people without a search query
- Train a custom rank model
What interviewers ask about
- Name and skill matches
- Common names and broad skills match many profiles. Exact filters and text relevance require different match rules.
- Profile visibility
- Search data can lag after access changes. The service must enforce current rules without one remote request per result.
- Changes to profiles
- Concurrent edits can reach search in a different order. A repair can also restore a deleted profile.
- Large result sets
- Broad queries create large candidate sets. Access checks remove results, while edits and failures can change later pages.
Common mistakes
- The design trusts index visibility after a member restricts access.
- The design shares final results across viewers without a new access check.
- The design scans every profile or uses large offsets for later pages.
- The design discards older field patches without obtaining complete state for the accepted version.
- The design promises full pages despite fixed work limits and many access rejections.
- The design promises fresh continued pages without a clear snapshot lifetime or freshness exception.
The bar by level
- Senior (L5/E5)
- Enforces restrictions after acknowledgement on every page. Defines safe versioned replacement and deletion behavior. Explains cursor expiry, candidate budgets, and partial responses. Handles access failures.
- Staff (L6+/E6+)
- Defines correctness across source commits, search updates, rebuilds, and access decisions. Quantifies access cost. Reconciles freshness with snapshot age. Defends privacy during failures and repairs. Explains limits on completeness, relevance, and latency.
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 people search system like LinkedIn search
Reported date not specified
Source snapshot: Nov 12, 2026
View source