AO
Back

Referral Network Data Structure and Algorithms

Also reported as Top-K Ranking on a Referral Network · Network Growth Estimation

CodingOnsiteLast reported May 2026Low Frequency

Problem Overview

One first-hand report, from Mercor's Applied AI onsite in May 2026: a 90-minute coding round in three parts. You get 60 minutes alone for Parts 1 and 2 (screen recorded, no LLM, search allowed for syntax only); then the interviewer joins, reviews them, and you do Part 3 together. No tests are provided: you write and run your own. The candidate compared the network to the follower/followee graph in the social-network question other AI labs ask.

The report gives each part in one sentence, so the method names, return shapes and the details below are our setup. Ask your interviewer. The tests build a tree: each user has at most one referrer. The tests follow referrals downward (referrer to referee). On a tree, counting pairs of users, distinct paths or shortest paths that way all give the same number; the clarifications cover the readings that differ, such as treating the graph as undirected.

Part 1 — The referral network

Store who referred whom: each user can be a referrer, a referee, or both.

  • ReferralNetwork() starts empty.
  • add_referral(referrer: str, referee: str) -> bool records one referral. It returns False and changes nothing for a self-referral or a referral already recorded (our setup).
  • get_referees(user: str) -> list[str] returns the users user referred directly, sorted; an empty list for anyone else.

Part 2 — Rank users two ways

Built on Part 1, rank the top k users by each of two measures. Both top_k_* methods return [(user, score), ...], highest score first, ties to the smaller user id (our setup; the tests avoid ties at the cut).

  • total_candidate_count(user: str) -> int: every candidate who came from user, directly or indirectly (everyone below them).
  • flow_centrality(user: str) -> int: how many times the user appears on referral paths between other users. We count the pairs (u, w) of other users where u is above user and w is below, which on a tree is the number of referral paths that pass through user.
  • top_k_by_candidate_count(k: int) and top_k_by_flow_centrality(k: int).

Part 3 — Expected network size

expected_network_size(days: int, p: float, seed: int = 1, cap: int = 10) -> float: the expected network size after days days. Every referrer has probability p of making one successful referral each day, and each person can make at most 10 successful referrals in their lifetime (cap). Our setup: the network starts with seed people, and a new member starts referring the day after joining.

Approach Trade-offs

Approaches actually attempted in reports — including ones that lost candidates time. Pick deliberately.
ApproachNotes
Memoized DFS for descendant countCaches subtree sizes to avoid recomputation across multiple top-K queries, but requires cache invalidation if the graph is mutable.
Monte Carlo simulation for Part 3Easier to implement, but approximate: it needs many trials for a stable answer, unlike the exact per-count state.

What Reports Emphasize

Common mistakes: No test cases are provided: you write and run your own.

Interviewer hints: The interviewer joins after the first 60 minutes of async coding to review Parts 1 and 2 before the candidate completes Part 3 live.; Google search is allowed but only for syntax lookups, not for algorithmic approaches like graph traversal strategies.

Practice

Write your own against 10 test cases, or read the worked solution — approach, complexity, and code that runs.
Mercor · Coding · Reported 1× across candidate reports
Is this helpful?