How the interviewer opens it
“Design a service that suggests people a user may know. The service can use friendships, profiles, and interactions. Explain how it provides useful suggestions and respects privacy.”
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
- Users and graph size
- Traffic and read:write mix
- Results and feedback
- Response time and availability
- Relationships and system boundary
- Permitted signals
- Privacy and consistency
- Freshness
- Retention and durability
- Quality
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
- Find people whom a user may know
- Rank suggestions by their expected usefulness
- Use only permitted signals for candidate discovery and scores
- Exclude friends, blocked accounts, ineligible accounts, and active dismissals
Usually out of scope
- Implement friend requests and messages
- Import address books
- Build a general model training platform
- Use exact location or private message content
What interviewers ask about
- People to suggest
- Graph hubs can dominate the cost of two-hop searches. Sparse accounts need useful evidence from other permitted sources.
- Privacy changes
- A suggestion can reveal a private link through its presence or score. Removing the explanation does not remove that influence.
- Recommendation usefulness
- Clicks do not prove that two people know each other. Repeated suggestions and biased feedback can reduce useful results.
Common mistakes
- The design traverses the full two-hop graph during every request.
- The design treats average degree as a safe limit for graph work.
- The design uses private links for discovery or scores, then filters only accounts and explanations.
- The design uses stale recommendation data as the authority for privacy decisions.
- The design excludes blocks in only one direction.
- The design measures clicks without measuring confirmed friendships or dismissals.
The bar by level
- Senior (L5/E5)
- The candidate separates candidate discovery from request service. The design handles degree skew, sparse users, duplicate events, and stale pools. The candidate defines current permission checks for both account exclusions and signal dependencies. Revoked graph evidence cannot continue to affect candidate presence or scores.
- Staff (L6+/E6+)
- The candidate defines consistency contracts across source services and derived data. The candidate quantifies graph work, permission checks, and dependency storage. The design handles aggregate feature revocation, regional failures, and incomplete permission checks. The candidate compares quality gains against computation cost and addresses feedback bias.