Design an **employee-to-employee distance** system for a large company. The system takes two employees as input and returns a meaningful "distance" (or, equivalently, a similarity score) between them. This distance powers several internal products: people search, internal networking recommendations, collaboration discovery ("who should I talk to about X?"), org insights, and onboarding suggestions for new hires. Your design should cover what "distance" should mean and how it varies by use case; what employee data you would use (org chart, team, manager chain, office/location, projects, skills, authored documents, communication metadata, collaboration history); how you would model the relationship between two employees; how you would serve low-latency pairwise distance queries at scale; and how you would evaluate quality, freshness, privacy, fairness, and abuse risk. Note that this is an enterprise product, so **viewer-specific access control and privacy are first-class design constraints, not afterthoughts.** ```hint Where to start "Distance" is not one universal metric. Resist collapsing it into a single opaque number — decompose it into interpretable *components* (organizational, collaboration, skill/topic, location/time-zone) and let the use case decide how to weight them. ``` ```hint Modeling the relationship Think in terms of a **heterogeneous graph** (employee / team / project / skill / document / location nodes) plus per-employee **embeddings**. Org distance is a tree/LCA problem; collaboration is a weighted, time-decayed graph; skill similarity is a text/embedding problem. Start rule-based and interpretable, then layer learned models (two-tower retrieval, GBDT over pairwise features, GNN) where labels justify it. ``` ```hint Serving & scale All-pairs distance is $O(N^2)$ — never materialize it for large $N$. Compute embeddings and org/collaboration features **offline**, compare **on demand** for the pairwise API, and precompute **top-K nearest neighbors** (ANN) only for the recommendation/retrieval use cases. ``` ```hint A pitfall to pre-empt Two failure modes interviewers probe: (1) over-ranking same-team people and missing cross-functional collaborators, and (2) leaking signal a viewer is not authorized to see (private docs, HR/protected attributes). Filter on the viewer's ACL *before* a signal contributes to the score, and explain only from visible data. ``` ### Constraints & Assumptions State your own numbers, but design against a realistic enterprise scale: - $N \approx 10\text{k}{-}100\text{k}$ employees; org tree depth $\sim$10; collaboration graph is sparse (most pairs never interact). - Two query shapes: **pairwise** `distance(viewer, A, B, use_case)` (interactive, target p99 $<$ ~100 ms) and **retrieval** `top_k_nearest(viewer, A, use_case)` for recommendation lists. - Data freshness: org/HR changes daily; collaboration signals (meetings, docs, chats, reviews) stream in continuously and should decay over time. - **Privacy/governance is a hard constraint**: the result must respect the *viewer's* access control, and must never expose private communication contents, protected attributes, or sensitive HR/legal/health data. - Assume access to HR system, org directory, calendar, document store, code review/ticketing, and chat *metadata* — but treat raw message content as off-limits unless explicitly governed. ### Clarifying Questions to Ask - Which use case(s) are we optimizing for first — people search, networking recommendations, collaboration discovery, org insights, or onboarding? Each implies a different notion of "close." - Is the output an absolute distance, a relative ranking, or both? (Recommendation needs ranking; org insights may need a calibrated, comparable score.) - What is the access-control model — does every viewer see the same distance, or is it viewer-relative (filtered to what the viewer is permitted to know)? - What collaboration signals are we *governed to use*? Raw chat/email content, or only metadata like co-attended-meeting counts and shared-document counts? - Do we have any labels — search clicks, accepted recommendations, manual relevance judgments — or are we cold-starting with heuristics? - What are the latency and freshness SLAs, and how large is the company (changes the $N^2$ vs. embedding/ANN trade-off)? ### What a Strong Answer Covers - **Problem framing**: recognizes "distance" is contextual and multi-component; ties the weighting/score shape to the specific use case rather than proposing one opaque metric. - **Data & features**: a sensible inventory of sources mapped to concrete features — org/LCA distance, time-decayed collaboration edge weights, skill/topic embeddings, location/time-zone — with privacy-minimizing choices (metadata over content). - **Modeling progression**: an interpretable rule-based baseline first, then a clear path to graph methods (shortest path / personalized PageRank / graph embeddings / GNN) and supervised models (GBDT, two-tower, learning-to-rank), with the label sources spelled out. - **Serving & scale**: offline feature/embedding pipelines vs. online pairwise path; avoiding $O(N^2)$; ANN for top-K retrieval; caching; efficient org-distance via precomputed manager chains / LCA; cold-start for new hires. - **Evaluation**: offline (AUC/NDCG/precision@K, correlation with human judgments, calibration) and online (search success, recommendation acceptance, follow-up-collaboration rate, dismiss/complaint rate); plus quality probes for the over-ranking-same-team and remote/new-hire-disadvantage failure modes. - **Privacy, fairness, abuse**: viewer-scoped ACL enforcement, sparse-signal thresholding to block inference attacks, opt-outs, bias audits (demographic/location/level), and explanations grounded only in visible data. ### Follow-up Questions - A new hire has almost no collaboration history. How does your system avoid returning a useless "everyone is far" result on day one (cold-start)? - How do you enforce that the *same* pair of employees can yield a *different* distance for two different viewers, without recomputing everything per viewer? - Same-team employees almost always dominate the top of the list. How would you detect this over-ranking and surface valuable cross-functional connections instead? - Aggregated, low-cardinality signals (e.g. "two co-attended meetings") can leak who-met-whom. How do you threshold or aggregate sparse signals to prevent inference attacks?