What to Expect in the Notion System Design Interview

Question

Design Gurus · Accepted Answer

Notion's system design interview is grounded in the company's actual engineering rather than abstract prompts, and Notion's engineering is distinctive: a product where everything is a block (pages, paragraphs, databases, and rows are all nodes in one composable tree), users define their own schemas, edits collaborate in real time, and the whole thing works offline. Candidates report that collaborative-editing machinery (operational transformation and CRDTs) genuinely comes up, making this one of the few loops where that literacy is explicitly rewarded.

The preparation strategy follows: learn the practical collaboration canon, understand the block model's implications, and practice designing systems where flexibility and performance fight.

The Question Territory

Design a collaborative block-based editor. The house question in various scopes: represent documents as block trees, propagate edits in real time, resolve conflicts, and support offline editing with later reconciliation. The OT-versus-CRDT-versus-LWW conversation lives here; what matters is honest tradeoff literacy, not deriving algorithms.
Design Notion databases. User-defined schemas (every user invents their own properties), views (filters, sorts, groupings) over large collections, relations and rollups across databases, and the performance problem of making schemaless-feeling data fast. This is the most Notion-specific territory: flexible data models that must not be slow.
Design offline sync. Local-first editing on multiple devices, operation logs, conflict handling that never silently loses a user's writing, and sync efficiency for large workspaces.
Design permissions and sharing. Hierarchical inheritance (page trees inherit access), granular overrides, guests and link sharing, and the fan-out problem of permission checks on every block read.
Design search or AI features over user content. Indexing constantly changing user-structured data, permission-aware retrieval, and the RAG layer behind workspace AI assistants.

What Interviewers Are Probing

Data-model-first thinking. Like Adobe's loop, Notion's rounds reward starting with the model: blocks as nodes with type, properties, content, and children, and everything else derived. Candidates who start with services and add "some database" underneath invert the company's actual architecture.
Practical conflict-resolution literacy. The graded conversation: last-writer-wins per property (cheap, occasionally lossy), OT (ordered operations, server as sequencer), CRDTs (merge without coordination, heavier metadata), and which Notion-shaped problems need which. Block-level LWW with property granularity covers most cases; text within a block wants finer machinery; naming that distinction is the fluency signal.
The flexibility-performance tension. User-defined schemas defeat classic indexing; interviewers probe how you make arbitrary filters and sorts fast: property indexing strategies, materialized views for hot queries, and honest limits ("this filter combination degrades to a scan; here is how we bound it").
Offline-first semantics. What happens to edits made on a plane: operation queues, idempotent replay, conflict surfacing versus silent merge, and the user experience of reconciliation. Never losing user writing is the invariant; say it.
Permission checks at read scale. Hierarchical inheritance makes naive per-block checks explosive; expect probes on caching resolved permissions, invalidation on sharing changes, and the tradeoff between check latency and staleness after revocation.

Walkthrough Sketch: Notion-Style Databases

Requirements first: users define collections with arbitrary typed properties, collections reach hundreds of thousands of rows, views apply filters, sorts, and groupings, relations connect collections with rollups aggregating across them, and everything collaborates in real time. Model first: a database is a block whose children are row blocks; properties are a schema object on the database block (versioned, because users edit schemas live); row property values store as typed key-value pairs against property IDs, not names, so renames are metadata operations.

The performance core: arbitrary user filters cannot all be fast, so design tiers: per-property indexes built lazily on access patterns (index the properties users actually filter by), materialized view results for hot views with incremental maintenance (an edit updates affected view caches via the change stream rather than recomputing), and bounded degradation for cold complex queries with pagination and async completion. Relations and rollups ride the same change stream: a row edit invalidates dependent rollups, recomputed incrementally with the dependency graph tracked, and cycles (users will create them) detected and bounded. Real-time collaboration reuses the block machinery: property edits are block operations with per-property LWW, schema edits are versioned operations that must order before dependent row edits, and the sequencer per database session provides that ordering. Close with the honest limits, stated like a product engineer: schema changes on a hundred-thousand-row database are backgrounded with progress surfaced, the rollup chain has a depth bound, and the design's philosophy is that users get spreadsheet flexibility with database performance for the 95 percent of usage that follows patterns, and graceful degradation for the rest.

How to Prepare

Foundations and depth: Grokking the System Design Interview for method, Grokking System Design Fundamentals for blocks, and Advanced System Design Interview, Volume II for replication, ordering, and consistency depth.
Learn the collaboration canon properly. LWW, OT, CRDTs at practical depth, plus offline-first patterns. Notion's own engineering blog posts on its data model and sharding are the best company-specific hour available, and the Figma design answer covers the shared real-time territory.
Practice the two house designs: the block-based collaborative editor and the flexible database, each end to end with the tradeoffs narrated.
Rehearse the flexibility-performance conversation. For any user-defined-schema design, practice naming what is fast, what degrades, and how you bound the degradation: that honesty is the round's differentiator.

For the full loop, see What is the Notion interview process like?, and prepare the values dimension with Top Notion behavioral interview questions and your answer to "Why Notion?"