What to Expect in the Linear System Design Interview

Linear's system design questions stay close to its own product: real-time sync, offline-first clients, and collaborative data models. The discussion happens in the architecture round of the virtual onsite, which runs 45 to 60 minutes. Candidates report applied design work, not abstract trivia. The interviewer grades your product judgment together with your architecture. If you understand how Linear's app itself works, you understand the interview.

Why Sync Is the Core Topic

Linear's client is offline-first. Offline-first means the app keeps a full local copy of your data and works without a network. A sync engine is the part that keeps that local copy and the server matched. This design is why the app feels instant: reads and writes go to local data first. Expect the interview to test whether you can reason about this model.

Question Types Candidates Report

• Design a sync engine for an issue tracker. The signature question shape. Covered in the walkthrough below.
• Design real-time collaboration features. Presence indicators, live updates, and comment threads across many open clients.
• Model the data for an issue tracker. Issues, projects, workflows, and the state machine of an issue. A state machine is a model where an item moves between defined states by defined rules.
• Design fast search over a workspace. Instant results over issues and documents, including offline.
• Scale the update path. Push changes to many thousands of connected clients at once.

A Walkthrough: Sync for an Offline-First Issue Tracker

Here is a high-level path through the signature question.

Step 1: Requirements. Each user's client holds a local copy of their workspace. Edits must apply instantly on the local client. All clients must converge to the same state. Converge means they end up identical after syncing.

Step 2: The local store. The client keeps data in a local database, such as IndexedDB in the browser. The user interface reads only from this store. That choice is what makes every screen fast.

Step 3: The change log. Every edit becomes a small change record: object, property, new value. The client applies it locally at once and queues it for the server. A queue preserves the order of pending changes when the client is offline.

Step 4: The server as the ordering authority. The server receives changes from all clients and puts them in one global order. It then broadcasts each accepted change to every connected client. Broadcast delivery usually uses WebSockets, which are long-lived two-way connections.

Step 5: Conflict resolution. Two people may edit the same field while one is offline. A simple rule works here: last writer wins, applied per property. That means the latest change to a single field replaces the earlier one, but changes to different fields both survive. Say clearly why this is acceptable for issue tracking and would not be for text editing.

Step 6: Bootstrap and catch-up. A new client downloads a snapshot of the workspace once. After that, it requests only the changes since its last known position. Discuss how a version number per workspace makes this cheap.

Step 7: A quick size estimate. A workspace with 50,000 issues at one kilobyte each is about 50 megabytes. That fits comfortably in a local browser database. Saying this out loud shows the design is realistic, not hopeful.

What the Interviewer Grades

Four things decide the result. First, whether your design keeps the client fast, since speed is the product's identity. Second, whether clients truly converge, including the offline cases. Third, the quality of your tradeoffs, such as choosing last-writer-wins and knowing its limits. Fourth, product judgment: what you would ship first and what can wait.

How to Prepare

• Learn the standard building blocks first. Queues, WebSockets, caching, and database replication all appear here. Grokking the System Design Interview covers them with worked examples.
• Go deeper on real-time systems. Grokking the Advanced System Design Interview treats replication, ordering, and consistency in detail.
• Practice the walkthrough aloud. Design a sync engine for a notes app and for a to-do app. The reasoning transfers directly.
• Know the rest of the loop. The architecture round sits inside a larger process, described in What is the Linear interview process like?
• Connect design to product. End every design with what you would build first. Linear grades that sentence too.