← Back to Directory

LinkedIn interview notes, page 6 of 32

Large Enterprises

Most of these LinkedIn write-ups come from Software Engineers (156), then Product Managers (66) and Data Scientists (37). The most reported rounds are the technical phone screen (169), the product sense round (62), the system design round (42) and the behavioral / leadership round (20).

316 interview notes · updated Oct 2026

LinkedIn·Product Manager·Onsite - Product Sense / Strategy

Apr 2026
Got a product strategy question at LinkedIn for a PM role, basically asked to do a post-mortem on LinkedIn Stories. Not a lot of context given upfront, just dropped into the deep end.
  • LinkedIn Stories was a product that failed. What would you have done differently?

“This one tripped me up more than I expected.”

View Post

LinkedIn·Software Engineer·Onsite - System Design / Architecture

Apr 2026
LinkedIn system design round for a software engineer role. The whole thing was one big question about trending topics, and it went deeper than I expected. Left feeling like I covered maybe 70% of what they wanted.
  • Design a system that continuously tracks the Top K most frequent items (tweets, search queries, clicks, etc.) over a sliding time window such as the last minute, hour, or day, at massive scale.

“I started with the functional requirements which felt okay, multiple window sizes, per-region vs global aggregation, query latency targets.”

View Post

LinkedIn·Product Manager·Onsite - Product Sense / Strategy

Apr 2026
PM interview at LinkedIn, one question about Spotify and social features. Pretty open-ended product sense round, felt like they wanted to see how you think about cross-product strategy more than whether you use Spotify yourself.
  • How would you improve Spotify by adding or enhancing social features?

“I went straight to the user problem angle, which felt right, but I spent too long on the setup and barely had time to prioritize between ideas.”

View Post

LinkedIn·Machine Learning Engineer·Technical Phone Screen

Apr 2026
LinkedIn ML engineer interview that was basically one meaty probability/sampling problem with a bunch of follow-ups stacked on top of each other. The core question sounds straightforward until they start asking about edge cases and scale. Felt like a coding round but drifted into system design territory by the end.
  • Given an array of weights representing a discrete probability distribution, implement a function that samples a random index with probability proportional to each weight.
  • What if the weights don't sum to 1? Give at least two approaches to handle unnormalized weights.
  • If you use rejection sampling for unnormalized weights, what is the expected number of trials needed as a function of the total sum?
  • If the array is very large but probability mass is concentrated on a small number of indices, what optimizations would you consider and what are the trade-offs around time, memory, preprocessing, and update cost?

“Prefix sum plus binary search, pretty standard.”

View Post

LinkedIn·Machine Learning Engineer·Technical Phone Screen

Apr 2026
LinkedIn ML engineer phone screen, basically one meaty probability/randomness problem the whole time. The kind of question that sounds like a puzzle but has real depth once you start pulling at it.
  • You have a biased coin function that returns 0 with unknown probability p and 1 with probability 1-p, where p can be anything in (0,1). Using only this function, implement another function that returns a uniform random integer from 0 to 6 inclusive. Also discuss the expected number of calls to the biased function.

“My first instinct was to just call the function a bunch of times and map ranges, which is completely wrong because you can't fix bias that way.”

View Post

LinkedIn·Product Manager·Onsite - Product Sense / Strategy

Apr 2026
LinkedIn PM interview with a single product design question about improving one of their core features. Pretty standard format, one question, no frills.
  • How would you improve LinkedIn Messaging?

“Classic improve-a-product question but the fact that it's their own product adds some pressure.”

View Post

LinkedIn·Machine Learning Engineer·Technical Phone Screen

Apr 2026
LinkedIn ML engineer screen, one meaty theory question about logistic regression that sounds straightforward until you're actually in it.
  • How does the log-likelihood loss function used in logistic regression connect to the principle of maximum likelihood estimation?

“I knew the mechanics but fumbled the explanation.”

View Post

LinkedIn·Machine Learning Engineer·Technical Phone Screen

Apr 2026
LinkedIn ML Engineer interview with a from-scratch K-Means implementation question. The depth they expected on stopping criteria and edge cases was a bit more than I anticipated going in.
  • Implement K-Means clustering from scratch, including the fit API that takes a matrix of points and a number of clusters, returning final centroids and per-point cluster assignments.

“I got the core loop down fine: initialize centroids, assign points by nearest Euclidean distance, recompute means, repeat.”

View Post

LinkedIn·Software Engineer·Technical Phone Screen

May 2026
LinkedIn phone screen for a software engineer role, one coding problem the whole time. Pretty straightforward if you've seen grouping-by-key problems before, but the T9 angle threw me for a second.
  • Given a list of words and a T9 phone keypad mapping, group all words that encode to the same digit string. Return only groups with two or more words.

“My first instinct was to just build the digit string for each word and throw everything into a hashmap keyed by that string.”

View Post

LinkedIn·Machine Learning Engineer·Technical Phone Screen

May 2026
LinkedIn MLE interview that was pretty much all algorithms with a graph search problem at its core. The follow-ups got progressively more system-design-flavored, which I wasn't fully expecting from a coding round.
  • Given a start word and an end word of equal length plus a dictionary of valid words, find the minimum number of single-letter substitutions to transform the start word into the end word, where each intermediate word must exist in the dictionary. Return -1 if no path exists.
  • How would you optimize neighbor generation using a reusable cached function? Walk through the eviction policy and the complexity trade-offs of using an LRU cache here.
  • If the dictionary can be updated at runtime with words being added or removed, how do you ensure correctness and thread-safety during concurrent read queries? Specifically, how do you handle cache invalidation when the dictionary changes?

“Classic BFS word ladder.”

View Post