How the interviewer opens it
“Design a browser-based interface design tool. Users share vector documents, reuse components, and edit together. Keep large documents responsive and preserve consistent shared edits.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
What to clarify first
- Scale
- Document size
- Read and write mix
- Document behavior
- Latency and client limits
- Initial view limits
- Consistency and availability
- Durability
- Disconnects
- Access and exclusions
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
Scope of a strong answer
Core requirements
- Create and edit vector shapes, text, groups, and pages
- Edit shared documents with other users
- Reuse components with instance overrides
- Keep large documents responsive
Usually out of scope
- Full offline work
- Component libraries across documents
- Advanced typography and character-level text collaboration
- Comments, video calls, and a version history interface
What interviewers ask about
- Concurrent document edits
- Concurrent edits affect both properties and document structure. Clients must agree without creating cycles, missing parents, or revived deleted nodes.
- Reconnects and server failures
- Retries, tentative edits, and server failures cross different state boundaries. The service must preserve acknowledged edits and prevent duplicate changes.
- Changes to reusable components
- One definition can affect thousands of instances. Concurrent overrides and nested definitions must preserve clear values without excessive work.
- Large document response
- Large documents exceed the initial view budget. Dense views and remote edits can block input even when servers meet latency targets.
Common mistakes
- Treats the tool as a shared text document and ignores document structure.
- Uses WebSockets as the complete consistency and durability design.
- Selects OT or CRDT without defining concurrent shape and group behavior.
- Copies component values into every instance without clear override rules.
- Promises fast initial views without bounds on content, assets, or visual detail.
- Confirms edits before durable commit or loses tentative edits during recovery.
The bar by level
- Senior (L5/E5)
- Defines structural conflict rules, optimistic reconciliation, durable acknowledgement, and retry behavior. Connects partial document load with live edits. Bounds initial work and protects frame time.
- Staff (L6+/E6+)
- Establishes invariants across document ownership, durable state, snapshots, and partial client state. Quantifies traffic, recovery, and initial view limits. Explains semantic and latency trade-offs when requirements change.