Implement a TextDocument class that stores a single mutable string and supports apply_operation (InsertAtEnd, DeleteFromEnd), undo_last, and redo_last. Each operation must run in time proportional to the size of the change, and applying a new operation must clear the redo history.

The key insight is to maintain two stacks (undo and redo) storing inverse operations rather than full snapshots. InsertAtEnd inverse is DeleteFromEnd of the same length; DeleteFromEnd inverse is InsertAtEnd of the removed characters. On apply, push the inverse onto the undo stack and clear redo. On undo, pop from undo, re-execute the inverse, and push the forward operation to redo. Likely follow-ups: extend to arbitrary cursor position inserts, handle concurrent edits, or discuss how this scales to a CRDT model. Clean OOP design, correct stack discipline (redo cleared on new apply), edge cases (delete more than available should be a no-op without error), and O(change size) complexity per operation.

Implement a permissions system for a hierarchy of pages. Each page can have its own permission setting or inherit from its parent. Given a user and a page, determine the effective permission. (Reported as a full-time SWE tech phone screen focused on permission data structures.)

Model pages as a tree. Walk from the target page upward toward the root until you find an explicitly set permission; if none is found, fall back to a default. A hashmap from page ID to (permission, parent_id) supports O(depth) lookup. Follow-ups typically ask about caching effective permissions, handling cycles, and invalidating the cache when a parent's permission changes. Correct tree traversal, use of appropriate enums/types for permission levels, and thoughtful handling of the inheritance-break case where a child explicitly overrides a parent.

Implement a TaskGraph class representing a directed acyclic graph of tasks with operations to add tasks, add dependencies, and execute all tasks in valid dependency order.

Use topological sort (Kahn's algorithm with an in-degree map, or DFS with a visited set). On add_dependency, increment in-degree of the dependent task. Execute by enqueuing all zero-in-degree tasks and processing in BFS order, decrementing in-degrees of neighbors. Cycle detection is a required follow-up: if the queue empties before all tasks are processed, a cycle exists. Overall complexity is O(V + E). Correct topological ordering, cycle detection, and clean graph representation. Notion cares about code quality and how the candidate thinks about failure modes.

Design a real-time collaborative document editing system (in the style of Notion or Google Docs) supporting concurrent edits from multiple users with low-latency sync.

Establish requirements: consistency model (eventual vs. strong), latency budget, offline support. For conflict resolution, present OT (transform concurrent operations so they commute — used in Google Docs) vs. CRDTs (data structures that merge automatically — better for offline-first). In Notion's block model, each block is an independent unit with a type, content, and parent reference, so conflicts are scoped to a single block. Use WebSockets for live updates backed by a sync service, event sourcing for the operation log, and sharding by workspace. Discuss tradeoffs of OT (simpler for linear text) vs. CRDTs (better for Notion's tree structure). Follow-up: how do you handle a user who goes offline for hours and then reconnects? Deep understanding of OT vs. CRDTs, awareness of Notion's block-based architecture, clear data modeling for blocks with parent references, and honest trade-off discussion.

Design the data model and database schema for Notion's block-based content system. Every element — text, heading, image, database row, page — is a block. Blocks can be nested and reordered. Walk through the schema, indexing strategy, and how you would execute a query like 'fetch all blocks in a workspace matching a keyword.' (Confirmed as a Notion onsite system design round by 1Point3Acres and Glassdoor candidates.)

Core table: blocks(id, workspace_id, parent_id, type, content jsonb, created_at, updated_at, order). Index on (workspace_id, parent_id) for tree traversal; GIN index on content for full-text search. Fetching a page requires a recursive CTE or a BFS traversal with parent_id. For keyword search at scale, sync blocks to a dedicated search index (Elasticsearch or Postgres tsvector) asynchronously. Follow-ups: how do you handle moves (update parent_id), deletes (soft-delete with deleted_at), and access control (join against permissions table)? Comfort writing SQL schemas and indexes, understanding of recursive queries, awareness of the full-text search problem at scale, and ability to write efficient queries live.

Design a job scheduling and workflow engine that executes a DAG of tasks where each task may depend on the output of prior tasks. (Reported as a Notion onsite system design question on 1Point3Acres thread 1082834.)

Components: a task store (postgres), a scheduler that emits tasks whose dependencies are satisfied to a queue (Kafka or SQS), worker pools that consume tasks and write results back, and a status tracker. On task completion, the scheduler re-evaluates the dependency graph (decrement in-degree; enqueue newly ready tasks). Handle retries with exponential backoff, idempotency keys on task execution, and dead-letter queues. For scale, shard workflow instances. Follow-up: how do you detect and handle a stuck workflow where a task hangs indefinitely? Clear decomposition into scheduler, queue, workers, and state store; correct handling of task dependencies without polling; and operational concerns like retry and failure isolation.

Notion Interview Questions

Notion runs a 4-to-5 stage SWE loop: recruiter screen, technical phone screen (60 min, practical coding), virtual onsite with a system design round (data modeling + SQL emphasis), a pair-programming or functional-implementation round, and a values/behavioral interview — sometimes with an executive for senior levels. The process is explicitly non-LeetCode in style; Notion asks product-shaped coding questions, and interviewers evaluate code quality and SOLID principles alongside correctness. As of 2025-2026 Notion has added an AI-fluency component requiring hands-on familiarity with tools like Claude Code and Cursor.

7 real questions across 2 rounds

Reported via 1Point3Acres threads 1150323, 1157560, 1141145; Glassdoor Notion Labs SWE interview reviews 2024-2025; PracHub Notion Coding & Algorithms page; Blind post 2dypDFWo. The React JSON Tree Viewer and Sliding Window Median questions were removed: no traceable candidate thread places either at Notion specifically (the former appears only on secondary aggregators without a named source; the latter conflicts with Notion's stated non-LeetCode-style posture and was not found in any direct Notion candidate report).

Run a Notion mock with the AI interviewer. It asks questions like these, follows up on your answers, and tells you exactly what to fix. The only score that means anything is the one on your real answers.

Continue with Google

Keep prepping

All company interviews