What to Expect in the LinkedIn System Design Interview

LinkedIn's system design interview is notably product-centric: rather than abstract infrastructure prompts, candidates design core LinkedIn features (the feed, the notification system, People You May Know, search, messaging) and are graded on architectural depth and product sense together. The company's evaluation culture weighs communication heavily: how clearly you structure the design, surface tradeoffs, and connect technical choices to member and business impact is scored alongside the architecture itself.

That combination defines the preparation: you need the standard distributed-systems toolkit, plus fluency with the specific shape of LinkedIn's data, which is a graph. Members, companies, skills, jobs, and the edges among them (connections, follows, employments, endorsements) form the economic graph underneath every product surface, and most design prompts are secretly graph problems wearing product clothing.

The Question Territory

• Design the LinkedIn feed. The flagship prompt: ranked professional content with fan-out tradeoffs (push versus pull versus hybrid for members with 30 connections versus 30 million followers), ranking with professional-context stakes, and the freshness-versus-precompute economics.
• Design a notification system. Multi-channel (in-app, email, push) with member-first constraints as a real design input: aggregation ("47 people viewed your profile" rather than 47 pings), rate limiting per member, and preference resolution. At LinkedIn, notification restraint is a values statement; designs that treat annoyance as a cost function fit the house.
• Design People You May Know. The classic graph problem: triangle closing at a billion-member scale, candidate generation (second-degree traversal, shared affiliations) versus ranking, precompute versus online serving, and the cold-start member.
• Design job search or recommendations. Two-sided matching (members and jobs), retrieval plus ranking, freshness of postings, and the marketplace tension: optimizing for applications versus successful hires.
• Design profile view tracking or an analytics surface. Write-heavy event ingestion, aggregation windows, and privacy semantics (who viewed whom, and who is allowed to know).
• SQL and data-layer judgment. LinkedIn loops often include concrete data questions: schema design for connections and endorsements, query shapes over relationship data, and when a graph store earns its complexity versus sharded relational tables.

What Interviewers Are Probing

1. Graph-data instincts. The one-line test: does the candidate recognize that connection degree distributions are wildly skewed (most members have hundreds of connections; some have millions of followers) and design for the skew? Hybrid fan-out, influencer special-casing, and hot-key handling all descend from taking the skew seriously.
2. Product sense inside the architecture. Why does feed ranking at LinkedIn differ from a consumer social feed? (Professional stakes, lower posting frequency, longer content half-life, and a members-first constraint on engagement bait.) Candidates who let product reality shape technical choices score on both rubrics at once.
3. Tradeoff narration. The communication grading is real: state alternatives, choose with reasons, and quantify ("precomputing feeds for all members costs X storage; pull-on-demand costs Y latency at p99; hybrid by follower count gets both curves"). Silent good decisions score worse than narrated good decisions here.
4. Scale arithmetic on a billion-member base. Members, daily actives, feed requests per second, notification volume: rough numbers stated and used. LinkedIn's scale is public enough that order-of-magnitude fluency is expected.
5. Member-impact closing. Designs that end with what the member experiences (feed latency, notification sanity, recommendation quality) rather than purely with system metrics match the evaluation culture.

Walkthrough Sketch: People You May Know

Requirements first: suggest relevant new connections for a billion members, refreshed at least daily, served in under 100 milliseconds on profile and network surfaces, with quality mattering more than coverage (a bad suggestion erodes trust in the whole module). Structure the problem as candidate generation, ranking, and serving, and say so: the decomposition itself is a graded artifact.

Candidate generation runs offline: second-degree traversal (friends of friends) dominates, weighted by triangle count (shared connections), plus non-graph sources: shared employer and school, co-attendance signals, and address-book matches where members consented. The skew problem arrives immediately: second-degree expansion for a member connected to a celebrity explodes, so cap per-neighbor contributions and sample the high-degree nodes rather than fully expanding them. Batch pipelines (the natural fit for daily refresh) write per-member candidate lists to a serving store; the ranking model scores candidates on connection likelihood and value (acceptance probability, downstream engagement), trained on historical invitation outcomes, with the guardrail metric stated: acceptance quality, not just invitations sent, because monetizing social pressure degrades the graph. Serving reads the precomputed ranked list, filters real-time exclusions (already connected, recently dismissed, invitations pending), and backfills from a lighter online generator for new members whose batch lists are empty: the cold-start path handled explicitly.

Close with member-first hygiene: dismissals honored immediately and persistently, no resurfacing of declined suggestions, and privacy semantics for sensitive edges (a therapist and their clients sharing an employer field is the cautionary tale). Naming that class of concern unprompted is a LinkedIn-native signal.

How to Prepare

• Method and depth: Grokking the System Design Interview for the structured approach and the feed/notification classics, Grokking System Design Fundamentals for the building blocks, and Advanced System Design Interview, Volume II for the sharding, replication, and consistency depth the follow-ups reach.
• Drill the graph transforms. Practice PYMK and feed fan-out once each, end to end, with the degree-skew handling explicit. The skew instinct transfers to most LinkedIn prompts.
• Rehearse narrated tradeoffs. For every design decision in practice, speak the alternative and the reason. At LinkedIn this habit is worth as much as the decision itself.
• Refresh SQL and schema judgment for the data-layer questions: connections, endorsements, and event tables, with index reasoning.

For the full loop, see our answer on the interview process at LinkedIn, and prepare the culture dimension with Top LinkedIn behavioral interview questions and your answer to "Why LinkedIn?"