← Back to Directory

LinkedIn interview notes, page 21 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

Jun 2026
LinkedIn PM interview, just one question but it does a lot of heavy lifting. Pick a product you love and walk through how you'd launch it. Sounds breezy until you realize they want the whole thing.
  • Describe a product you love and walk through how you would launch it.

“I picked something I genuinely use every day, which helped, but I spent too long gushing about why I liked it and not enough time on the actual launch plan.”

View Post

LinkedIn·Product Manager·Hiring Manager Screen

Jun 2026
Did a product interview at LinkedIn and got asked the classic metrics question. Nothing too wild but it made me realize I don't have a crisp answer for this as often as I should.
  • How did you measure the success of a product you worked on?

“I rambled a bit.”

View Post

LinkedIn·Software Engineer·Onsite - System Design / Architecture

Jun 2026
LinkedIn system design round for a software engineering role. One question, but it had a lot of surface area and I felt like I kept getting pulled in different directions trying to cover everything.
  • Design a system that continuously tracks the top K elements from a large or streaming dataset. Cover data structures, how you'd handle updates, scalability, and support for high-throughput queries.

“I went straight for a min-heap of size K and felt pretty good about it until they pushed on the streaming angle.”

View Post

LinkedIn·Software Engineer·Technical Phone Screen

Jun 2026
LinkedIn coding interview, one question about designing a phone book from scratch. Pretty straightforward on the surface but the follow-up about reverse lookups is where things get interesting.
  • Design a phone book data structure that supports adding a name/number pair, removing an entry by name, looking up a number by name, and finding all names associated with a given number. Walk through your data structure choices and the time complexity of each operation.

“The add/remove/lookup by name part is basically just a hash map and I got through that fine.”

View Post

LinkedIn·Software Engineer·Onsite - Coding / Algorithms

Jun 2026
LinkedIn SWE coding round focused on LRU cache design and then pivoted into a pretty deep concurrency discussion. The problem itself is a classic but the follow-up questions about thread safety caught me more off guard than I expected.
  • What data structures would you use to implement an LRU cache that supports O(1) get and put operations, and why?
  • Implement a working LRU cache class with a constructor that takes capacity, a get method, and a put method.
  • Walk through the time and space complexity of your LRU cache implementation.
  • How would you make your LRU cache thread-safe for concurrent access from multiple threads? Compare coarse-grained locking, fine-grained locking, and concurrent data structures.
  • What race conditions or consistency problems could occur if multiple threads call get and put simultaneously, and how does your design prevent them?

“I knew the answer here (hashmap plus doubly linked list) but I fumbled explaining WHY the doubly linked list specifically.”

View Post

LinkedIn·Product Manager·Onsite - Product Sense / Strategy

Jun 2026
LinkedIn product interview, one question about the newsfeed. Pretty open-ended and I felt like I was rambling halfway through but it is what it is.
  • What feature would you build to drive more engagement on the LinkedIn newsfeed?

“Spent the first minute just trying to nail down what 'engagement' even means for LinkedIn specifically, because likes and shares feel like the wrong metric for a professional network.”

View Post

LinkedIn·Data Scientist·Technical Phone Screen

Jun 2026
LinkedIn data scientist interview with a meaty stats/experimentation question about a flawed email A/B test. The whole thing centered on Simpson's paradox and whether you could trust aggregate results when the data was sliced by city and week. Felt more like a case study than a typical interview question.
  • A marketing team ran an email test across two cities over two weeks. Email B outperforms Email A within every city and every week, but when you combine all the data, Email A looks better overall. How do you figure out which email is actually better?
  • What would you actually report to stakeholders if Email B wins in every individual subgroup but Email A wins in the combined data?
  • Can you compute a valid confidence interval if you only have access to aggregated data and not the raw observations?
  • If the original test was poorly designed, how would you redesign the experiment to avoid this confounding problem?

“This is a Simpson's paradox setup and I knew that pretty quickly, which helped.”

View Post

LinkedIn·Machine Learning Engineer·Onsite - System Design / Architecture

Jun 2026
LinkedIn system design round for an ML Engineer role, which ended up being a deep distributed systems question that felt more backend-heavy than I expected for the position. The breadth of what they wanted covered was a lot to fit into one session.
  • Design a distributed key-value storage service that supports high availability across zones, horizontal scalability to billions of keys, low-latency reads and writes, per-key read-after-write consistency, TTL, conditional updates, and optional range scans. Walk through the full design including API, sharding, replication, read/write paths, on-disk storage, failure handling, and observability.

“This is basically a 'design DynamoDB but explain every decision' question and I was not ready for the full scope of it.”

View Post

LinkedIn·Software Engineer·Technical Phone Screen

Jun 2026
LinkedIn coding screen focused on a classic phone keypad word-matching problem. The interviewer wanted to see two distinct approaches, not just a working solution, which I wasn't fully expecting.
  • Given a list of words and a digit string (using the standard phone keypad mapping), return all words whose digit sequence matches the input. Walk through a backtracking approach and then an optimized solution.

“My first instinct was DFS, trying each possible letter at each digit position and checking against the word list.”

View Post

LinkedIn·Software Engineer·Technical Phone Screen

Jun 2026
LinkedIn SWE interview with a classic algorithm puzzle. Nothing too wild, but the O(n) constraint is what makes it interesting.
  • In a group of n people labeled 0 to n-1, find the 'celebrity': someone everyone else knows, but who knows nobody. You have access to a knows(a, b) API. Return the celebrity's label, or -1 if none exists. Do it in O(n) API calls.

“The naive approach is obvious and wrong, O(n^2) calls if you just check every pair.”

View Post