LinkedIn interview experience
Summary
I went through a multi‑round interview at LinkedIn, including a coding round with AI, a LeetCode‑style Dijkstra problem, and a system design on scaling a NoSQL store, but was unable to solve the coding rounds and received feedback that my design approach was rejected.
Full Experience
Screening round : Explain design of any most recent featue you have developed.
Followed by four more interview rounds.
1 - Coding with AI in CoderPad. Question : Related to scheding using interval tree. The AI was hanging like anything in coderpad. It took 30+ mins to get the codepad in a state where I can answer. When I asked some answer to the AI, the AI hanged badly for 4+ mins. Post that I again reset the entire codepad setup, and it continued. Question and the existing answer in coderpad were not in sync. Interviewer were nice. I was able to write the answer with AI and was able to execute.
2 - Behavior round : Interviwer asked queries and listened to me very patiently. Nice experiance.
4 - Coding round - similar to https://leetcode.com/problems/shortest-path-in-a-hidden-grid/description/ Dijkstra's algo. Unable to solve, explained the logic verbally. My bad.
3 - Design Round - The prompt was to scale a single-node NoSQL key-value store to fifty million key-value pairs at one million queries per second, split evenly between reads and writes.
I proposed a fairly standard approach: horizontal sharding with consistent hashing across a group of nodes, so that a failed node's traffic is absorbed by its peers and keys can be redistributed as capacity is added or removed. I suggested separating the database tier from the web services answering queries, an in-memory cache layer, a Bloom filter to short-circuit lookups for keys that don't exist, and a queue such as Kafka to absorb write bursts when traffic spikes above the stated average.
Every one of these was rejected. The interviewer's position was that SQLite alone would handle the throughput, that Redis or Memcached were poor choices because they hold a duplicate copy of records already in the database — duplication treated as a flaw rather than the deliberate trade‑off every cache makes — that no queueing layer was needed despite peak traffic exceeding the average, and that consistent hashing was unnecessary. He also maintained that the database and the microservices should sit on the same single node, and that a node going out of service didn't particularly matter.
My concern isn't the disagreement itself, it's that there was no room for one. I was interrupted on nearly every point and the round was run as though there was a single correct answer to defend rather than a design to explore. A candidate should be able to justify a trade‑off without being told they're simply wrong.
I'd encourage the team to review how this round is calibrated. Design interviews should test reasoning, not adherence to the interviewer's preferred solution.
Interview Questions (2)
Shortest Path in a Hidden Grid
Find the shortest path from a start cell to a target cell in a hidden grid where each cell can be either open or blocked. The problem can be solved using Dijkstra's algorithm to explore the reachable cells while minimizing the number of steps.
Design a Highly Scalable NoSQL Key‑Value Store
Design a system that can store fifty million key‑value pairs and handle one million queries per second, split evenly between reads and writes. The design should address scaling, high throughput, fault tolerance, and low latency.