Posting this to help others since I found it really hard to find recent Staff-level interview experiences for LinkedIn. Sharing everything I remember (some details might be slightly off since it was a long day lol).

Background: 7.5 YOE, currently Senior SDE at a mid-size product company. Was targeting Staff at LinkedIn, Google, and Uber simultaneously. LinkedIn was actually my second choice going in — ended up being the one that worked out.

Timeline:
Recruiter reached out on LinkedIn (ironic). Phone screen → 2 week gap → Onsite, 5 rounds in a single day. The whole process took around 5 weeks. The 2-week gap between phone screen and onsite felt long but the recruiter was responsive whenever I pinged, so no complaints.

Phone Screen: Coding

LRU Cache with TTL expiry. Standard LRU but each entry has a time-to-live. get() should return -1 if the key has expired even if it's still in the cache. Follow-up was about how you'd handle cleanup of expired entries without impacting get() latency — discussed lazy eviction vs background thread and tradeoffs.

Went fine. Got the onsite scheduled within 3 days.

Onsite Round 1: System Design

Design LinkedIn's notification delivery system — what notifications to send (connection requests, post likes, job recommendations, InMail), how to prioritize them, delivery across push/email/in-app.

Started with requirement clarification — are we designing the generation of notifications or just the delivery pipeline? He wanted both which honestly made me a bit nervous because that's a LOT of surface area for 45 minutes.

Clarified scale (~900M members, not all active, need to handle bursts during peak hours), then defined the data model for notification events — type, priority tier, recipient, channel preferences, dedup key.

Went with an event-driven architecture, Kafka as the backbone. Producer services (connections service, feed service, jobs service etc) emit notification events to topic partitions keyed by user ID. Notification orchestrator service consumes events, checks user preferences (Redis with a persistent fallback like DynamoDB — explained why pure SQL would be a bottleneck here), applies per-user rate limiting, and routes to channel-specific delivery services.

For prioritization, designed a three-tier priority system — P0 (InMail, connection acceptance), P1 (post engagement), P2 (job suggestions, "people also viewed"). P2 gets batched into digests.

Interviewer pushed hard on deduplication — what if the same "X liked your post" event gets produced twice? Talked about idempotency keys and a short-TTL dedup cache. This is where I think I could've gone deeper honestly — he kept asking follow-ups and I gave reasonable answers but I could tell he wanted me to go further into the distributed dedup problem. I talked about bloom filters briefly but didn't commit to a full approach because I wasn't confident enough to go deep on it under pressure.

Last 10 minutes went into observability — what metrics would you track. Delivery latency percentiles, drop rates by channel, notification open rates as a product health signal.

He was nodding through most of it and building on my points rather than redirecting, which I took as a good sign. But I walked out of this round genuinely unsure because of the dedup part.

Onsite Round 2: Coding (Data Structures)

Design a RateLimiter class:

• boolean allowRequest(String clientId, int maxRequests, int windowSeconds) — sliding window
• Thread-safe
• Follow up: distributed environment with multiple server instances

Single-machine version: ConcurrentHashMap<String, Deque<Long>> with timestamp-based sliding window. Discussed why fixed window counter has the boundary burst problem.

Thread safety: per-key locking with computeIfAbsent + synchronized blocks on the deque. He asked me to walk through a specific race condition — two threads checking same client's window, both seeing count=99 (limit=100), both allowing, 101 requests go through.

Distributed follow-up: tradeoffs between centralized Redis counter (accurate but network hop latency) vs local counters with periodic sync (fast but allows temporary over-counting). Mentioned LinkedIn probably uses a hybrid approach.

This round went well. Felt confident walking out.

Onsite Round 3: Craftsmanship / Engineering Excellence

This round is unique to LinkedIn. It's behavioral but deeply technical — they want to know how you think about quality and mentorship at scale. Honestly the one I found hardest to prepare for because you can't really practice it the way you practice coding or design.

Questions (best I can remember, might be mixing up the order):

• What does "engineering excellence" mean to you? How do you define it for a team not just yourself?
• Describe a system you inherited that had quality issues. How did you approach improving it?
• How do you handle it when team is under delivery pressure and someone wants to skip tests?
• Tell me about mentoring a mid-level engineer toward senior
• Your team owns a monolith that's hard to deploy. Product wants features. How do you balance?
• Code review philosophy — how does it change junior vs senior?
• How do you maintain design quality across 8-10 engineers on the same system?

I think there were 1-2 more questions but I honestly don't remember, my brain was pretty fried by this point.

I talked about introducing design docs as a standard practice, establishing SLOs before building features rather than after, and creating a "tech health" dashboard that tracked test coverage, p99 latency, and deployment failure rate. The framing that clicked was "make quality visible rather than abstract" — interviewer literally wrote something down when I said that.

For mentorship, shared a specific example of pairing with a mid-level engineer on design reviews, gradually shifting from "here's how I'd design this" to "walk me through your design and I'll ask questions." She really liked that.

Felt decent about this round. You can't fake the stories though — either you've done this stuff or you haven't.

Onsite Round 4: Hiring Manager

More like a conversation than an interview. This was probably the most relaxed round.

• Walk me through your current role and team structure
• Most impactful technical decision in the last year, walk me through how you made it
• Project where you aligned multiple teams — what was hard
• Hypothetical: You own LinkedIn's PYMK ("People You May Know") system. ML team has a new model, 15% better relevance but latency goes from 50ms to 200ms. How do you evaluate this? Who do you involve?
• Follow-up: rollout plan, what signals tell you to proceed vs roll back
• Three Staff engineers disagree on technical approach for a critical project — how do you handle it

The PYMK hypothetical went deep. We talked about A/B testing with latency-bucketed cohorts, perceived vs actual latency (skeleton loading), whether 200ms crosses the threshold where connection request rates actually drop, model distillation for a faster variant. I think I did okay here but I went on a tangent about model serving infrastructure that probably wasn't necessary. He politely steered me back lol.

Onsite Round 5: Coding (Algorithms)

By this point I'd been going for like 4+ hours and was running on caffeine and adrenaline.

Problem 1: Stream of events (timestamp, event_type), design a class to answer "how many events of type X in the last N minutes?" High-throughput concurrent writes.

Used a ConcurrentHashMap with TreeMaps and bucketed timestamps for memory efficiency. query() does a subMap call. Discussed cleanup of old data — I initially forgot to address this and the interviewer had to prompt me, which was embarrassing but I recovered quickly.

Problem 2: Merge K sorted iterators lazily without loading everything into memory. Classic min-heap but the follow-up was making it fault-tolerant — if one iterator throws mid-stream, skip it and continue without losing data from others.

Second one went clean. No follow-ups after this round, interviewer said "that's all from me" with like 8 minutes left which I couldn't tell was good or bad.

Result: Got the call about 8 days later. Selected. Honestly didn't expect it :D

What actually helped me prep:

System design was the area I spent the most time on since that's what Staff rounds really hinge on.

hellointerview was my first stop — expensive but the content quality is legit if budget isn't a concern. Gave me a strong foundation but I felt like I was still just consuming content and not actually practicing enough.

prepd.tech - A college junior randomly sent me an invite and I almost ignored it lol but eventually opened it accidently. It was rough around the edges when I started to be honest. But core remains very strong - It would catch me skipping over capacity estimation or not justifying my database choice, the way an actual interviewer would so gave more than generic AI response.

Most important feature which helped was that they also arranged weekly sessions with engineers/ex-engineers from target companies which were super helpful for understanding what interviewers at those specific companies look for.

bytebytego and Alex Xu's book for setting the fundamentals — you probably already know about these.

For coding — leetcode, focused on medium/hard around trees, heaps, and concurrency. Did around 120 problems over the prep period. Nothing groundbreaking here.

For concurrency concepts and deeper video explanations — Udit Agarwal's youtube channel. Fair warning it's slow paced which is both a blessing and a curse. Good if you actually sit through it, bad if you're impatient like me and keep hitting 2x speed lol. But the depth on threading and concurrent data structures specifically helped a lot for LinkedIn's coding rounds since they love concurrency questions.

Hope this helps ! All the best to everyone preparing, stay strong and doors will open !!