AO
Back

Referral Network Data Structure and Algorithms

CodingPhone, OnsiteSoftware Engineer, Machine Learning EngineerLast reported May 2026Low Frequency

Problem Overview

Implement a referral network system (similar to a social network follower/followee graph) in three parts: **Part 1:** Design and implement the core referral network data structure.
Full problem statement
Implement a referral network system (similar to a social network follower/followee graph) in three parts: **Part 1:** Design and implement the core referral network data structure. Each user can be a referrer (who recommends others) and/or a referee (who was recommended). Support operations such as adding referral relationships. **Part 2:** Built on Part 1, implement two ranking functions that return the top-K users by: 1. Total candidate count — the total number of users reachable from a given user, counting both direct and indirect referrals (i.e., the full descendant subtree/subgraph). 2. Flow centrality — the number of times a user appears on referral paths between other pairs of users in the network. **Part 3:** Implement a function to estimate the expected total network size after N days, given: every referrer has probability p of making one successful referral each day, and each person can make at most 10 successful referrals over their lifetime. No test cases are provided; candidates must write and run their own tests. LLMs are not allowed for Parts 1 & 2 (Google for syntax only); Part 3 is done live with the interviewer.

Follow-up Arc

Interviewers escalate through these phases. The order varies, but most candidates see at least one from each bucket.
Edge cases · 1Trade-off discussion · 2
Edge cases
Walk me through your data structure choice and how you handle cycles or duplicate referrals.
Probes for: After candidate implements Part 1
Trade-off discussion
How does your flow centrality calculation work, and what is its time complexity?
Probes for: After candidate implements Part 2 ranking functions
How does the 10-referral lifetime cap affect your model, and how did you account for it?
Probes for: After candidate implements Part 3 growth estimator

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 and handles complex stochastic dependencies, but is approximate and slower than closed-form expected value computation.

Practice

Open the editor to write a solution against test cases, then return here to compare against the follow-ups.
Open Editor →
Mercor · Coding · Reported 3× across candidate reports