Build Collaborative Document Editing Shared by People and AI Agents

This prompt is one of five offered in a take-home for a software engineering role on an AI product team. The candidate picks one prompt; across the set they cover frontend, backend and infrastructure work. The take-home is budgeted at 8–12 hours. The chat logs from the AI coding tools you use (such as Cursor, Codex or Claude Code) are submitted along with the code, and the work is judged on agentic development practice, 0-to-1 product scoping, and user or developer experience design. A later onsite round reviews the submission in detail. **Prompt:** build collaborative document editing in which people and AI agents work on the same document. ### Constraints and Clarifications - Time box: 8–12 hours for design, code, tests and a written explanation. - AI coding tools are allowed, and their session logs are part of what is evaluated. - The review round treats the submission as a prototype, so anything you defer should be written down with a reason. ### Clarifying Questions - What kind of document: rich text, Markdown or code? How large can one get? - How many people and agents edit one document at the same time? - How do agents take part: does a person invoke one on a selection, or do agents also work in the background? May an agent change the text directly, or only propose changes? - Is offline editing required, or only recovery from short disconnections? - What control do people need over agent edits: approval, attribution, undo? ### Part 1 — Scope and build the prototype Decide what the prototype must support within the time box and what it defers. Describe how concurrent edits are merged, how clients stay in sync, how an agent reads the document and writes its changes, how people see and control agent edits, and how documents are stored. Explain how you will use AI coding agents to build it so that the submitted logs show a disciplined workflow. ```hint Agents are slow collaborators An agent may need several seconds to produce an edit while people keep typing in the same paragraph. Decide how its edit still lands in the right place. ``` #### What This Part Should Cover - A concurrency approach, such as operational transformation or CRDTs, with the reason for the choice, and a sync protocol that survives reconnects. - An agent edit protocol: what the agent reads, how its output is anchored, whether it edits directly or proposes changes, and how people accept or undo them. - Persistence and presence, plus tests showing that concurrent edits converge. - Agentic practice visible in the logs: a written spec as context, small tasks, tests, and reviewed diffs. ### Part 2 — Product review: trade-offs and scaling limits In the onsite review, the interviewer treats your submission as a prototype and probes it in detail; expect every shortcut to be found and asked about. Explain the trade-offs you made, where the system stops scaling first, which needs of teams editing with agents it does not yet meet, and where its UI falls short. ```hint Count the operations Estimate operations per second for one document with several people typing and an agent producing output, then for all open documents, and see which component saturates first. ``` #### What This Part Should Cover - Trade-offs between merge approaches, direct edits versus proposed changes, and history retention versus storage. - The first scaling limits: servers holding documents, history growth, very popular documents, and model cost and latency. - Needs such as trust in agent edits, attribution, access control for agents, and privacy of content sent to model providers. - UX for agent output: visibility while it is being produced, stale proposals, and undo. ### Part 3 — A new customer requirement The interviewer then introduces requirements from other customers and asks how you would integrate them, how long the work would take, and how it changes the roadmap. The requirements vary; practice with this one: an enterprise customer requires every agent edit to be approved by a person, a full history of which person or agent changed what, and the ability to revert everything one agent run changed without losing later human edits. ```hint Authorship must survive merging Selective revert is only possible if every piece of text still knows which person or agent run wrote it after edits have been merged. ``` #### What This Part Should Cover - Enforcing approval and recording authorship at the level of individual edits. - A selective revert that preserves later human work and handles conflicts visibly. - A task-level estimate, a roadmap order, and success measures. ### What a Strong Answer Covers - A scope that fits the time box and still demonstrates people and an agent editing one document concurrently without lost or misplaced edits. - Treating agents as participants with identity, permissions and slower timing, rather than as a text box that overwrites the document. - Continuity from Part 1 decisions to the Part 2 limits and the Part 3 plan. - Evidence of disciplined use of AI coding agents, especially tests for convergence. ### Follow-up Questions - How would a background agent keep a document's summary current without flooding people with proposals? - How would you support hours of offline editing followed by a large merge? - A document is larger than the model's context window. What does the agent read? - How do you stop an agent acting for one user from reading or editing content that user cannot access?