LinkedIn·Software Engineer·Onsite - System Design / Architecture·Senior

SeniorPrefer not to say

May 2026

Summary

LinkedIn system design round for a software engineer role, focused entirely on making a meeting scheduler thread-safe under write-heavy concurrency. The problem had real depth and the follow-up about flipping the read/write ratio was the part that actually tripped me up.

Questions Asked (2)

You have a meeting scheduler with add_booking and find_earliest operations. The workload is write-heavy with many concurrent bookings. Design and implement a thread-safe version, choosing between a single mutex, fine-grained per-bucket locks, or a reader-writer lock. Justify your locking strategy and discuss deadlock avoidance and throughput trade-offs.

System DesignTechnical Trade-offsAlgorithms & Data Structures

Author's notes

I started with a single mutex just to get something working, which felt embarrassingly simple but the interviewer didn't push back immediately.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the data structure and concurrency requirements, then propose a design that uses fine-grained locking (e.g., per-bucket locks) to maximize write throughput, while carefully avoiding deadlocks through lock ordering or lock-free techniques. Justify your choice by comparing it to a single mutex and a reader-writer lock, highlighting the trade-offs in contention, complexity, and scalability.

Pro tip: Emphasize that in a write-heavy scenario, a reader-writer lock can actually hurt performance due to writer starvation and overhead; instead, consider a sharded approach with per-bucket locks and possibly lock-free reads for find_earliest to achieve high concurrency.

1. Clarify Requirements and Assumptions

Ask about the expected number of concurrent writers, read frequency, and whether find_earliest needs to be strictly consistent or can be eventually consistent. Also confirm the data structure (e.g., sorted list, heap, or time-bucketed map).

2. Propose Data Structure and Locking Granularity

Suggest a time-bucketed structure (e.g., array of buckets per hour) with a lock per bucket. Explain that this reduces contention compared to a single mutex and allows concurrent writes to different buckets.

3. Justify Locking Strategy and Compare Alternatives

Argue that fine-grained locks offer better throughput for write-heavy workloads than a single mutex or reader-writer lock. Mention that reader-writer locks can cause writer starvation and have higher overhead.

4. Address Deadlock Avoidance and Consistency

Describe how to avoid deadlocks by acquiring locks in a consistent order (e.g., by bucket index) or by using lock-free techniques for reads. Discuss how to maintain consistency for find_earliest, possibly using a global lock only for that operation or a concurrent priority queue.

5. Discuss Throughput Trade-offs and Scalability

Analyze the trade-offs: fine-grained locks increase complexity but improve concurrency; single mutex is simple but serializes all operations; reader-writer lock may not suit write-heavy loads. Mention potential optimizations like lock striping or optimistic concurrency.

Key Points to Mention

Fine-grained locking (per-bucket) reduces contention and improves write throughput in write-heavy scenarios.
Single mutex is simple but becomes a bottleneck under high concurrency.
Reader-writer locks can cause writer starvation and have higher overhead, making them less suitable for write-heavy workloads.
Deadlock avoidance via consistent lock ordering or lock-free data structures for reads.
Trade-offs: complexity vs. performance, consistency vs. availability, and scalability considerations.
Use of concurrent data structures (e.g., ConcurrentHashMap) or lock striping to implement per-bucket locks.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.

What changes about your locking strategy if find_earliest is called orders of magnitude more often than add_booking?

Technical Trade-offsSystem Design

Author's notes

This is where I got a bit turned around.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the read-heavy workload and its implications for lock contention. Then propose shifting from exclusive locking to reader-writer locks or lock-free reads, and discuss trade-offs like writer starvation and consistency.

Pro tip: Mention that you'd measure the read-to-write ratio and consider optimistic concurrency control or copy-on-write to avoid blocking readers entirely, showing you balance performance with correctness.

1. Clarify the workload

Confirm the read-to-write ratio and whether find_earliest needs strong consistency or can tolerate stale reads.

2. Identify contention points

Analyze how the current locking strategy (e.g., exclusive locks) causes readers to block each other and writers to block readers.

3. Propose alternative locking

Suggest reader-writer locks, optimistic concurrency, or lock-free data structures to allow concurrent reads.

4. Address trade-offs

Discuss potential writer starvation, increased complexity, and memory overhead of versioning or copy-on-write.

5. Recommend a solution

Choose a strategy based on requirements, e.g., reader-writer lock with writer priority or a lock-free heap if reads dominate.

Key Points to Mention

Reader-writer locks allow multiple concurrent readers but require careful writer priority to avoid starvation.
Optimistic concurrency control (e.g., version numbers) lets readers proceed without locks, validating only on write.
Copy-on-write or immutable data structures enable lock-free reads at the cost of memory and write complexity.
Lock-free data structures (e.g., concurrent skip lists) can provide scalable reads but are hard to implement correctly.
The choice depends on consistency requirements: strong consistency may need synchronization, while eventual consistency allows more concurrency.
Benchmarking and profiling are essential to validate that the new locking strategy actually improves throughput.

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.