Five rounds, with my approach and follow-ups for each.
I've been lurking on this forum for years, and this interview process benefited a lot from it, so I'm writing up a full account to give back. As usual, I'll use homophone code names for the problems in the original, but I'll just describe them directly here.
Overall impressions first. LinkedIn's interview pace is fairly restrained — not like some companies that cram two or three problems into one round. It's basically one main problem per round, done thoroughly, then extended toward larger data scale. The interviewers were generally patient, letting you finish your own thoughts, and didn't interrupt much. There was also a Host Manager round that doesn't test code at all — it's entirely about your experience and culture fit, and it carried more weight than I expected.
Below is the record in interview order.
Coding Round 1
The problem was pow(x, n).
It looks like an easy problem, but the interviewer wasn't concerned at all with whether I could solve it — he cared about a few details:
I first asked whether n could be negative, whether x could be 0, and whether the result could overflow. The interviewer said n could be negative, and everything else was standard.
Looping and multiplying n times directly is O(n) — I stated that as the baseline, then gave the O(log n) fast-power solution.
He asked for both a recursive and an iterative version. The recursive version reads better; the iterative version doesn't have to worry about stack depth.
The last trap is that when n is INT_MIN, negating it overflows. I didn't notice this at first — it was only when the interviewer asked "what happens when n equals the smallest negative integer" that I caught it. The fix is to cast to long first, or handle that one case separately.
Takeaway: this round wasn't testing algorithmic difficulty, it was testing rigor. My suggestion is to walk through edge cases even on easy problems.
Coding Round 2
The problem was: given a sorted array, find the k numbers closest to x, and the result has to stay sorted.
I gave two approaches and compared them:
Approach 1: binary search for x's insertion point, then expand two pointers outward k times, each time picking whichever side is closer. Complexity O(log n + k).
Approach 2: binary search directly on the left boundary, with the comparison condition being the distance from A[mid] to x versus A[mid+k] to x. Complexity O(log(n-k) + k).
The interviewer had me write out approach 2 and clearly explain why that comparison condition holds. I walked through it: if A[mid] is farther from x than A[mid+k], the window should shift right as a whole. He followed up with "which way do you go when they're equal," and I said left, since the problem requires taking the smaller number when the distances are equal.
There were two follow-ups:
What if the array isn't sorted? Answer: it degrades to using a heap of size k, O(n log k).
What if the array is so large it doesn't fit in memory? Answer: you could use an index or chunking to first locate the rough region, then only read that chunk into memory. I didn't go very deep on this one.
Coding Round 3
This problem wasn't from any online judge — it had more of a design flavor.
Problem: given a very large sorted array, count how many distinct values it contains. It's known that the number of distinct values k is much smaller than the array length n.
My first answer was a linear scan, O(n). The interviewer said, "n is on the order of a billion, k is only a few hundred — can you do better?"
Once it clicked, the idea was: since equal values form a contiguous block, there's no need to walk through them one at a time. Starting from the current value, use binary search to find the right boundary of that block, then jump straight to the next block. Total complexity is O(k log n), which is much faster than O(n) when k is much smaller than n.
The interviewer also mentioned an equivalent divide-and-conquer version:
def countUnique(arr, start, end):
if start == end:
return 1
if arr[start] == arr[end]:
return 1
mid = (start + end) // 2
if arr[mid] == arr[mid+1]:
return countUnique(arr, start, mid) + countUnique(arr, mid+1, end) - 1
else:
return countUnique(arr, start, mid) + countUnique(arr, mid+1, end)
Both approaches boil down to the same thing: use the sortedness to skip over equal elements in one jump instead of visiting them one by one. He had me analyze how the divide-and-conquer version degrades to O(n) in the worst case (all distinct), and I got that right.
System Design
The problem was to design a news feed.
I worked through it in this order:
Requirements clarification. User scale, average number of follows, read/write ratio, freshness requirements (does new content need to show up within seconds), and whether ranking is needed versus pure reverse-chronological order. The interviewer said reads far outnumber writes, a few seconds of delay is acceptable, and ranking is needed but the ranking model itself didn't need to be expanded on.
The core tension. Push (fan-out on write) means fast reads and heavy writes; pull (fan-out on read) means light writes and heavy reads. I said to use push as the default, since the read/write ratio is so skewed, but pull for accounts with huge numbers of followers, to avoid fanning a single post out to millions of inboxes. This is the usual hybrid approach.
Data model. A user table, a follow-relationship table, a content table, and an inbox table. The inbox only stores content IDs and ranking scores; the actual post body is fetched separately, so the inbox stays light.
A few points he dug into:
Should the inbox have a cap? I said to only keep the most recent entries, with older content fetched via pull, so storage stays bounded.
How do you smooth out the fan-out spike when a huge account posts? Answer: an async queue plus batch processing, with some delay allowed.
How does the ranking score get updated? Answer: compute a base score at write time, then do a lightweight re-rank at read time using real-time signals.
How is caching designed? Answer: keep active users' inboxes resident in cache, load inactive users' on demand, and evict with LRU.
Finally we talked about consistency. Content a user posts themselves has to show up in their own feed immediately — that can't rely on async processing, so read-your-own-writes needs special handling.
I was fairly well prepared for this round and it went smoothly.
Host Manager
No code at all — the full forty-five minutes was conversation. The questions were:
Walk me through a project you recently led, and what exactly your role was
Tell me about a time you disagreed with another team, and how it was resolved
Has a project's direction ever been changed halfway through
What's the most valuable feedback you've ever received
What do you want from your next job that this one can't give you
The first four were pretty standard, and my STAR-prepared stories covered them fine. The fifth one caught me a little off guard — it felt like he was checking whether my motivation was genuine, or whether I just wanted to job-hop for a raise. I answered with a specific technical direction instead of speaking in generalities, and the manager was noticeably more engaged after that.
This round didn't have a high density of follow-ups, but every question got a "so what was the actual outcome" follow-up. My advice is to have the outcome of every story clearly worked out, ideally with something quantifiable.
A few takeaways
-
LinkedIn doesn't chase problem difficulty, it chases depth. None of the five rounds had a hard problem, but every problem got grilled on edge cases, complexity, and alternative approaches.
-
Easy problems need more caution, not less. If the interviewer hadn't prompted me on that pow problem in round one, I would have tripped on the overflow.
-
Treat "what if the data scale gets huge" as a default follow-up. Two of my three coding rounds this time asked "what if it doesn't fit in memory."
-
Don't treat the Host Manager round as a throwaway. It carries real weight in the overall evaluation, and what it asks isn't quite the same as a pure behavioral round — it gets into motivation and long-term plans.
-
For the system design round, lay out the tradeoffs of the hybrid approach clearly before going further — don't jump straight into drawing component diagrams.
This got long, but I hope it helps whoever's preparing.
Discussion
Loading comments…