The Staff Engineer Collaboration Interview: CRDTs, Offline Edits, and Durable Sync

Converged text is only one part of a correct editor

Two engineers edit an architecture document offline. They reconnect, the replicas converge, and one engineer discovers that a confidential paragraph was synchronized to someone whose access had been revoked. A successful merge is not a complete collaboration-system design.

CRDT research describes replicated data types designed to converge under specified update and delivery conditions. It does not make authorization, user intent, persistence or history retention disappear. Begin the interview by stating which properties your hypothetical editor needs and which problems the merge mechanism will solve.

Use an illustrative shared design document. Clarify whether the product needs rich text, comments, attachments, simultaneous cursors and offline edits. Ask how long offline work can remain disconnected and whether permission revocation must prevent a reconnecting client from submitting changes. A meeting notes application and a sensitive approval document may need different policies.

Define user-visible promises: local input is responsive; accepted edits are durably recoverable; authorized replicas eventually see accepted changes; disconnected state is visible; permission boundaries are enforced. Separate “saved on this device,” “accepted by the server” and “synchronized to others.” Those labels give both the design and the user a way to reason about partial failure.

Explain merge semantics with a concrete conflict

Yjs provides shared data types and integration with collaborative editors. Automerge’s document model supports collaborative structured documents with its own data semantics. Choose one model for the exercise and explain how the editor maps user actions into it, rather than implying the two libraries are interchangeable storage formats.

Consider two users editing the same sentence. A convergent sequence can preserve inserted characters from both users while producing prose neither intended. For a field such as an approval state, automatic convergence may be even less useful. State which data can merge mechanically and which operations require a user decision or server-side invariant.

Distinguish operation identity, causal relationships and wall-clock time. A laptop clock is not a dependable global ordering authority. Explain how the selected library represents concurrent changes and missing history, using its supported protocol rather than inventing a timestamp-based last-write rule for all content.

Yjs document updates are documented as commutative, associative and idempotent, with state-vector support for exchanging missing changes. That permits flexible update transport within those semantics. It does not imply that arbitrary application events, permission changes or side effects can be replayed without additional rules.

For the interview, draw an example with two concurrent inserts and a later delete. Ask what each user should see and how undo behaves. Keeping the example small prevents a diagram full of replication boxes from obscuring the actual document semantics you are promising.

Make synchronization durable across disconnections

WebSocket supplies a bidirectional protocol over a connection. It does not by itself persist edits or resume application-level synchronization after a reconnect. Describe an update protocol with document identity, authenticated session, update payload, acknowledgment and a mechanism for discovering what each side lacks.

Persist accepted updates or a valid checkpoint with the history needed to resume. A server that broadcasts an update and then crashes before saving it can create disagreement about whether the edit is durable. Decide when the sender receives a durable acknowledgment and what happens if that acknowledgment is lost.

Yjs documents offline editing using local persistence such as its IndexedDB integration. In the hypothetical product, store local changes promptly and distinguish device persistence from remote acceptance. On reconnect, authenticate again, validate access and exchange missing state. Avoid treating possession of an old document identifier as continuing permission.

Bound message and document sizes, and apply per-session and per-document backpressure. A fast client or unusually large offline update should not consume every collaboration worker. For slow recipients, explain whether you buffer, coalesce, disconnect with a resume path or fall back to loading a checkpoint.

Trace the uncertain acknowledgment: the server stores an update, the network drops, the client resends. The merge protocol can tolerate duplicate document updates where documented. Your application still needs to avoid duplicating associated notifications, audit events or attachment processing. Use separate operation identities for those effects.

Separate transient presence from document history

Yjs awareness represents information such as cursor positions and user presence separately from persisted document content. Apply that distinction: presence may expire when a client disappears, while a committed paragraph should not. A cursor heartbeat is not a document-saving signal.

Choose a product policy for offline presence and reconnects. Show that someone is disconnected without presenting their last cursor as live activity. Avoid making every cursor move a durable event in the document log unless a particular requirement justifies that storage and privacy cost.

Yjs Undo Manager supports selective tracking and operation origins. An undo action in a collaborative document needs a defined scope: should it reverse only this user’s edits, a grouped local action or everyone’s intervening work? The answer is a product choice supported by the library’s semantics, not a universal definition of undo.

Treat comments, attachments and resolved discussion state carefully. The text CRDT may not own the attachment’s lifecycle or permissions. A deleted reference can leave an uploaded file behind; a restored reference can point to a file already removed by cleanup. Define ownership and retention for those resources alongside document history.

For a rich-text editor, also ask how formatting and selection positions survive concurrent edits. Use the library’s editor binding or position mechanism where available. The goal is to show awareness of user-facing consistency, not to build a new sequence algorithm from scratch during the interview.

Enforce permissions and make compaction a migration

Place authorization before accepting updates and before returning document state. Recheck it when a session reconnects or access changes. An open socket authenticated an hour ago should not be a permanent permission grant. Define how revocation reaches active sessions and what data is already present on a client device.

A client that downloaded content while authorized may retain an offline copy. The architecture cannot promise to erase that knowledge through server-side revocation alone. State that boundary directly and decide which documents are eligible for offline access. This is a product security decision requiring policy and technical controls together.

Compaction should preserve the information needed by supported clients. A checkpoint can shorten load time while a very old offline client still needs a valid synchronization path. Define a supported history horizon and a recovery flow for clients outside it, such as importing their local work into a newly authorized document view for review.

Version the persisted format and synchronization protocol. Test a client from the prior supported version against a newer server and checkpoint. A deployment that makes historical updates unreadable is a data migration problem, not a routine websocket restart. Keep an inspectable rollback or conversion plan.

Use restricted diagnostic records. Document identifiers, update sizes and sequence progress may be sufficient to investigate lag; raw text should not automatically enter logs. An operationally convenient payload dump can bypass the permission rules the serving layer carefully enforced.

Rehearse the document journey from offline to accepted

Practice simultaneous edits, an offline reconnect, a duplicate update, a server crash after persistence, a revoked user and a client older than the compaction horizon. For each scenario, identify the local state, authoritative accepted state, visible status and recovery path. These scenarios are an editorial practice framework, not a published hiring rubric.

Measure time to local persistence, remote acceptance and recipient visibility separately. Track reconnect success, missing-history recovery and rejected unauthorized updates. A low socket round-trip time does not prove that an edit is durably saved or visible to an authorized colleague.

Explain the simplest useful deployment first: an authorized document service, a supported collaboration library, durable history, device persistence and ephemeral presence. Add partition placement and load isolation when the workload requires them. A globally distributed transport is a poor substitute for a clear document contract.

The staff-level argument is that convergence is a mechanism serving a broader product promise. Your design should preserve edits, explain disconnected state and respect permission boundaries when reality interrupts the happy path. Practice that argument with Interview Copilot, then reconnect the two offline engineers and account for every piece of state.