LinkedIn System Design Interview: The Full Guide

You can solve every LeetCode Hard on the planet and still blank when someone asks you to design People You May Know. LinkedIn's system design interview doesn't care how many binary trees you've reversed. It cares whether you've ever thought about a professional social graph at scale, and most people haven't.

This guide covers the round structure, what each level actually expects, the topics LinkedIn genuinely asks, and a concrete prep plan. It's aimed at senior (ID3), staff (ID4), and principal (ID5) candidates.

The Full Interview Loop

LinkedIn's onsite for software engineers has five rounds. Remote interviews use CoderPad throughout.

Round	Format	Duration
Recruiter screen	Behavioral + background	30 min
Technical phone screen	2 coding problems, no execution	60 min
Standard coding	1 medium-hard DSA problem	45 min
Coding with AI	DSA problem + production follow-ups	45 min
Hiring manager	Background, behavioral, project discussion	45 min
System design	High-level design, whiteboard	45-60 min
Project deep dive	Your work, your decisions	45 min

Staff and principal candidates typically see two system design rounds instead of one. The project deep dive is a separate conversation from the system design, and interviewers expect you to own the decisions on whatever project you bring.

The phone screen is CoderPad with no execution. You dry-run by hand. Pick a problem with a clean trace path.

What the Bar Looks Like at Each Level

This is where candidates under-prepare. The same prompt, "design LinkedIn's news feed," means completely different things depending on the level you're targeting.

ID3 (Senior): One system design round. You need a solid high-level architecture, correct component selection, and the ability to discuss trade-offs when the interviewer probes. Distributed systems depth is expected. Pure API design without scalability thinking gets you to a no hire.

ID4 (Staff): Two system design rounds. The bar jumps significantly here. You're expected to go multiple layers deep without prompting. Not just "use Kafka for the feed pipeline" but why Kafka, what partition key you'd use, how you handle consumer lag, what happens when a celebrity posts and your fan-out explodes. Interviewers probe until they hit a wall. Your job is to make the wall very, very far away.

ID5 (Principal): Two rounds, both heavy. Expect the conversation to drift toward system evolution over time, operational concerns, how you'd approach a migration from an existing architecture, and cross-team impact. Generic textbook designs fail hard here. They've read every system design textbook. So have the other candidates.

How the Round Works

The round is 45 to 60 minutes. LinkedIn interviewers are more domain-specific than most. They will ask you to design a LinkedIn product or feature, not an abstract system. "Design a URL shortener" shows up rarely. "Design LinkedIn's job recommendation system" or "Design PYMK" shows up constantly.

Spend the first five minutes clarifying scope. What's the scale? DAU? Read/write ratio? Consistency requirements? Latency budget? LinkedIn has roughly 1 billion members, but don't assume that's the scope unless asked to design for LinkedIn itself.

A rough time allocation that works at ID3 and above:

0-5 min: Requirements and clarifying questions
5-15 min: High-level architecture, data model
15-30 min: Deep dive into one or two components
30-40 min: Scalability, failure modes, trade-offs
40-45 min: Evolution, what you'd do differently

Topics LinkedIn Actually Asks

LinkedIn's system design questions cluster around the platform's actual engineering problems. These come up repeatedly across candidate reports from 2024 and 2025.

Feed and content delivery

Design LinkedIn's news feed
Design LinkedIn Live (video streaming at scale)
Design a real-time notification system

Recommendations and graph

Design PYMK (People You May Know)
Design LinkedIn's job recommendation system
Design LinkedIn's connection graph infrastructure

Messaging

Design InMail (LinkedIn's messaging system)
Design a distributed chat system

Search and discovery

Design LinkedIn's people/company search
Design a resume parser API

Infrastructure questions at staff level:

Design a distributed job scheduler
Design a message queue (they built Kafka, they know this problem cold)
Design a distributed key-value store
Track top-k events in a sliding time window

The feed, PYMK, and job recommendations are the three most commonly reported questions. Go deep on all three.

Think in Graphs First

This is the single most important LinkedIn-specific insight. LinkedIn's data model is a graph. Members, companies, schools, and skills are nodes. Connections, follows, and applications are edges.

Most candidates design LinkedIn systems as if the data is rows in a relational table. That works for basic questions. It breaks down the moment your interviewer asks how you'd do a second-degree connection lookup efficiently, or how you'd find members who went to the same school and now work at the same company.

LinkedIn built LIquid, a distributed graph database, specifically to power PYMK and the Economic Graph. The Economic Graph has over 270 billion edges and handles more than 2 million queries per second. You don't need to know the internal implementation, but you do need to think about your data model as a graph from the start and reason about graph traversal costs.

When you reach for a relational database for a relationships table, ask yourself: what does a 2-hop neighbor query look like on 1 billion nodes? That question should push you toward graph-native thinking or at least a precomputed-candidates strategy.

PYMK: The Signature Problem

PYMK is worth covering specifically because it's asked so often and the naive solution falls apart fast.

The naive approach: for user A, find all 2-hop neighbors (friends of friends), score them, return top k. On paper, this sounds completely fine. In practice, a single well-connected user can have thousands of connections, and their connections can have thousands more. A full 2-hop expansion on a popular node is billions of edges. Your query just tried to load the economy of a small country into memory.

The production answer is a multi-stage funnel.

Candidate generation pulls a few thousand candidates from three sources: graph walks (n-hop neighbors), embedding-based retrieval (semantic similarity), and heuristic rules (shared employer, school). No single source covers everything.
L0 ranking cuts billions to thousands. The goal here is recall, not precision. An XGBoost ranker does the first cut cheaply.
Neural rankers estimate invitation probability, acceptance probability, and engagement probability. These run on the reduced candidate set, not all possible connections.
Result caching and freshness. Recommendations are precomputed and refreshed in batch, not computed per request. Real-time updates handle events like a new connection or a profile change.

When LinkedIn interviewers ask this question, they want to see the multi-stage funnel, the distinction between recall optimization at early stages and precision at late stages, and some thought about the graph traversal problem.

The naive 2-hop neighbor approach when it meets a graph with 270 billion edges.

Common Mistakes That Kill Good Candidates

Starting with technology, not requirements. Saying "I'd use Kafka for the feed" in the first two minutes before establishing scale, latency budget, or consistency requirements signals that you've memorized patterns without understanding them. Interviewers hear this constantly. It reads as rehearsed, not reasoned.

Designing too generically. If your LinkedIn news feed design could be copy-pasted as a Twitter feed design, you've missed the point. LinkedIn's feed has professional context signals, connection strength weighting, and different read/write patterns from a social network. Show you understand the domain.

Skipping the graph. Treating every LinkedIn problem as a standard relational CRUD system gets flagged fast. You don't need to design a graph database from scratch. You do need to reason about graph-shaped data. If your PYMK solution is a SELECT * FROM connections join, the interview is already over.

No failure modes. Staff and principal candidates who describe a happy-path architecture and stop there consistently get no-hire feedback. What happens when the notification service falls behind? When the job recommendation batch job produces stale results? When a member with 30,000 connections posts? Happy-path-only designs get no-hire feedback at every level above ID2.

Treating the project deep dive as a behavioral question. It isn't. It's a technical interrogation. Pick a project where you drove the architecture decisions, not just the implementation. Your interviewer will spend 30 to 40 minutes probing your schema choices, concurrency model, and trade-offs. "We decided as a team" is not an answer.

The LinkedIn interviewer when you describe a notification architecture with no failure modes.

The 45-Minute Playbook

Minutes 0-5: Clarify scope explicitly. Get numbers. Confirm what "LinkedIn scale" means for this specific problem. Interviewers appreciate candidates who ask about the existing system versus greenfield. Do not skip this. The candidate who jumps straight to architecture at minute zero burns their requirements phase and then has to backtrack in minute 25.

Minutes 5-15: Draw the high-level boxes. Don't jump into Kafka partition counts. API layer, data stores, async pipelines. For LinkedIn problems, identify early whether the core data model is a graph, a feed, or a search index, because that decision shapes everything.

Minutes 15-30: Pick the hardest component and go deep. For a feed system, that's the fan-out problem. For PYMK, that's the candidate generation and ranking pipeline. For job recommendations, that's the feature store and real-time signals. This is where you differentiate.

Minutes 30-40: Probe your own design. Talk through failure modes before the interviewer asks. What degrades gracefully? What falls over? How would you detect it?

Minutes 40-45: Evolution and trade-offs. What would you do differently at 10x scale? What's the biggest risk in your current design?

Prep Strategy and Timeline

Four to six weeks for a senior role. Six to eight for staff.

Weeks 1-2: Build the foundational knowledge. Read LinkedIn Engineering blog posts on the news feed, PYMK, and Kafka. Study the push vs. pull trade-off for feed delivery. Know consistent hashing, bloom filters, and distributed caching cold.

Weeks 3-4: Practice LinkedIn-specific problems. Design the news feed, PYMK, job recommendations, and InMail from scratch. Record yourself. The gap between what you think you said and what you actually said is usually embarrassingly large.

Weeks 5-6 (senior) / 5-8 (staff): Add depth. For staff candidates, add distributed job schedulers, event sourcing patterns, and graph database trade-offs. Practice the concurrency follow-ups that show up in the AI coding round, since those bleed into system design conversations.

Read Jay Kreps' "The Log: What Every Software Engineer Should Know About Real-time Data's Unifying Abstraction" on the LinkedIn Engineering blog. It explains Kafka's design philosophy and gets cited in system design conversations there regularly.

System design is a conversation, not an essay. You need to practice explaining trade-offs out loud, not just thinking through them silently. SpaceComplexity runs realistic system design mocks with rubric-based feedback so you can practice the verbal back-and-forth before the real thing.