What LinkedIn Tests

The single most-recurring prompt in LinkedIn's design round is an infrastructure primitive: top-K over rolling time windows. Return the most-shared URLs or the most-frequent service exceptions over the last five minutes, the last hour, the last day, with tens of millions of items flowing in daily. It is the question LinkedIn reaches for first, ahead of the news feed and its billion-member fan-out. The round leans on building blocks at least as much as on the marquee product surfaces the brand suggests.

Underneath, the round runs on two clusters that show up about equally often. One is distributed-systems building blocks. Top-K leads, then a distributed key-value store, a job scheduler paired with an observability dashboard, a rate limiter, a distributed cache. The other is product designs drawn from LinkedIn's own surface: the feed and its fan-out, a notification system at scale, messaging, people-you-may-know, people-search typeahead. Most loops hand you one or the other. The building-block prompts are at least as common as the marquee product ones, which is what makes LinkedIn's round read differently from a feed-first company.

The LinkedIn angle

Almost everything they put on the board is real-time ranking over data that will not sit still. It sits under feed ranking and search suggestions, under job recommendations and trending, under the notification pipeline. That is why top-K is the signature prompt and not a curveball. LinkedIn invented Kafka, and its real-time analytics store, Pinot, answers top-N queries straight off a Kafka log. Name those where they fit. Say where each one stops being the right tool. Drop them as decoration and the brand-drop works against you, because the person across the table may have built the thing.

Who gets the round, and how much it counts

The bar climbs steeply with level, and the loop knows it. A new grad may not see a full architecture round at all. The junior slot leans toward object-oriented and low-level design, design patterns and clarifying questions, with the occasional "how would you improve this product" prompt, instead of production-grade distributed systems. By senior it is a dedicated, weighted round. At staff, candidates report two separate design rounds on top of the coding and managerial rounds: one heavy on distributed systems, and sometimes a second that starts low-level and gets pushed up to high-level. Confirm your own schedule with your recruiter, since the split moves by team and by year.

• ~ New grad / junior. A lighter design slot skewed to low-level and object-oriented design over full distributed architecture.
• 1 Mid / senior. One weighted 45-to-60-minute design round in the onsite that carries real signal.
• 2 Staff. Two design rounds reported, one distributed-systems-heavy, alongside the coding and managerial seats.

What scales with level is the depth they hold you to. The prompt itself barely moves. Mid-level, a clean end-to-end design you can defend is enough. Senior and up, they want the engineer who has partitioned a real store and picked a consistency model with reasons. That engineer also knows how the thing degrades when a hot key lands on one shard at 3am. The further up you interview, the more of the hour lives in that second half.

How LinkedIn runs the round

It is one problem, roughly 45 to 60 minutes, on a shared virtual whiteboard by 2025 and 2026. You go deep on a single prompt rather than touring several. The reported cadence is steady. Clarify requirements for five to ten minutes, sketch a high-level design for ten to fifteen, then spend the bulk of the hour inside one subsystem before scaling and reliability questions close it out. A strong big-picture design is expected within the first thirty minutes, so scope fast and start drawing.

The shapes LinkedIn asks most

Prompts cluster into a handful of recurring shapes, with top-K clearly in front. LinkedIn does not publish how often each one comes up, so treat the percentages below as soft. What is solid is the ordering: this is roughly the sequence you will meet them in.

Read the spread as a set of distinct problems to learn. The order matters less than the shapes. Top-K is real-time aggregation under a tight memory and latency budget. The feed is fan-out plus two-pass ranking. Notifications fan out across channels with delivery guarantees. A distributed key-value store is a storage primitive with partitioning and hot keys. People-you-may-know is graph candidate generation over connection degrees. Bank hardest on top-K, then the feed and notifications. The key-value store and people-you-may-know round out the set, and the infrastructure prompts deserve as much practice as the product ones.

The LinkedIn angle

Name LinkedIn's real systems where they fit, because the person across the table may have built them. Real-time top-N and trending run on Pinot, their OLAP store that reads off a Kafka log. The feed is served by FollowFeed, an indexing layer over Kafka and Espresso, with RocksDB underneath and a first-pass and second-pass ranker. The source of truth for profiles and InMail is Espresso, their distributed document store, with cluster management by Apache Helix. People-you-may-know and other Hadoop-derived data are served read-only from Voldemort, while Venice handles derived-data serving with Kafka as a write buffer. Drop these where they earn a place, defend the category if the brand is unfamiliar, and never reach for them as decoration.

Running the hour

Run the time as an arc. Spend the first few minutes scoping. State what is in and out, name the read-versus-write skew, and put rough numbers on the table so every later choice visibly follows from them. Sketch entities and an API, walk a high-level design one requirement at a time, and leave real room to go deep; the second half is where senior and staff verdicts get made. The cadence itself is universal, so the delivery framework lesson drills it. This section stays on what LinkedIn rewards on top.

The LinkedIn angle

LinkedIn relaxes consistency almost everywhere, so say which parts can lag and why. Feed entries, view counts, people-you-may-know results all run seconds behind and nobody notices, so data moves asynchronously through Kafka and eventual consistency is the default. Core read paths like profile and feed hold higher availability, around 99.9 percent. Do not just assert the relaxation. Point at a path and say why a few seconds stale is safe there. Then know where Kafka's ordering and delivery guarantees stop, because that is the next question coming.

The LinkedIn angle

Treat the design round as a level decision, because at LinkedIn it often is. The process overview lays out a pooled loop where a hiring committee owns your final level, with no single manager deciding it, and design weight climbs with seniority. A thin design showing is the most plausible thing to cost a senior or staff candidate a rung. Depth beats breadth here. Take one subsystem all the way down, at the depth that proves you have built and run this in production.

The worked designs

Five designs, frequency-ordered, one per distinct shape. Start with top-K, since it is the most-asked and the move from single-machine order statistics to distributed real-time aggregation is the instinct the others borrow from.

Each design assumes the fundamentals from the System Design course. Lean on the scaling playbook for reads and writes, and the toolbox for when to reach for Kafka, a key-value store, a cache, or a search index. These pages stay on the LinkedIn-flavored design itself rather than re-teaching the mechanics.