LinkedIn, AI track. I passed the technical screen before the layoffs, and it didn't get scheduled for onsite until this week. The hiring manager round is scheduled for before National Day — nothing much to say about that yet. After preparing for so long I was actually pretty confident, but today one of the system design rounds completely wrecked me. I'm not fully willing to accept that, but I'm still giving back to the forum. I've realized that in a market this bad, sticking together and helping each other really matters.
The screen covered a lot of project detail. Thirty minutes to code one problem, and the dry run/walkthrough took about 5 minutes. I'd seen this one on the forum before, so I was prepared. The recruiter said the feedback was very good. The hiring manager was easygoing, and the recruiter said the feedback was good with enough scope. They even gave me the questions this team had used in past interviews: 2 system design rounds and 2 coding rounds. One system design topic was a skill/course recommendation system, the other a metrics monitoring system. For coding, one was an ML implementation problem, and the other was similar to the screen question — and I was told not to mention that one under any circumstances.
The onsite started. C1 (the first coding round) was merge intervals to compute total length — I'd seen it on the forum, and apparently the optimal solution uses a tree structure, but I'd never actually coded it by hand, I only remembered the approach. I wrote something on the spot that was maybe 95% there, and again the dry run didn't compile. Looking back afterward I found there was actually a bug in it. It was pure coding, not much room for chit-chat.
SD1 (the first system design round) turned out to be the monitoring question, just as I'd hoped. The focus was on comparing push vs. pull models — the two approaches emphasize different things at scale — plus aggregation strategy. I think the feedback was decent. The interviewer respected me leading the discussion, always letting me finish my train of thought before jumping in.
C2 (the second coding round) was Word Ladder. I breezed through it, but there were two follow-ups. The first was about caching — I was a bit confused, isn't this just DFS with memoization? He hinted that I should cache the neighbors, and then I got it: pull the neighbor-finding function out on its own, rewrite it, and add an LRU cache. The second follow-up was: what if the word list can be updated? I said I'd add a lock, but I might not finish in time. He said it wasn't that complicated — just add it inside the neighbor function. I threw together some executor.submit code in a panic; afterward I realized what he actually meant was that I didn't need to worry about parallelism at all, and just needed to wrap the line that accesses the word list with a lock. Which left me confused — if it's not concurrent, how would the word list even get updated while a query is running?
SD2 (the second system design round) was a key-value store question that completely wrecked me. I hadn't reviewed that at all and had zero ideas. I remember the forum really did have this question before, but I genuinely thought it wouldn't come up in the AI track, so it just didn't cross my mind. Takeaway: interview write-ups are genuinely useful. This forum isn't just people venting about embarrassing failures — it's full of good people who genuinely hope the ones who come after can do better than they did. Since I couldn't be the one who paved the way, I guess I'll settle for being the one who comes after.
Discussion
Loading comments…