Katkat
Back

Design Employee-to-Employee Distance

GleanMachine Learning Engineer · Onsite
MediumMachine Learning EngineerOnsiteML System Design

Last updated

This question evaluates competencies in ML system design, similarity and representation modeling, feature and data engineering, scalable low-latency serving architectures, and privacy, fairness, and evaluation practices.

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.

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)?

Hints

Hint 1

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 2

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 3

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 4

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.

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?