Design a collaborative online IDE

How the interviewer opens it

“Design a shared coding workspace where collaborators edit files, use terminals, and run code. Explain how the service synchronizes workspace state and isolates code execution.”

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

• Files and workspace size
• Scale
• Read and write mix
• Terminal traffic
• Latency
• Consistency and availability
• Durability and recovery
• Execution limits and trust
• Access and location
• Excluded features

The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.

Scope of a strong answer

What interviewers ask about

Edits from several collaborators

Collaborators change overlapping text from different document versions. File renames and deletions also change the meaning of later edits.

Files seen by editors and commands

Editors and tools change the same files through different interfaces. A file copy can erase tool changes before the service notices them.

Code from unknown users

User code can attack the host, exhaust shared resources, or steal credentials. Workspace access can also change during an active session.

Connection loss and runtime failure

Document edits need durable replay, but terminal input causes external effects. A reconnect must not create another runtime or repeat a command.

Common mistakes

• The design replaces entire files and loses concurrent edits.
• The design checks file versions without preventing tool writes between the check and replacement.
• The design promises fresh files for Run but leaves shared terminal behavior undefined.
• The design trusts a container to isolate hostile code without a threat model.
• The design acknowledges edits before durable storage or repeats uncertain terminal input after reconnect.
• The design estimates connection traffic but ignores runtime CPU and memory costs.

The bar by level

Senior (L5/E5)

Defines durable edit acknowledgments, duplicate suppression, and the distinct guarantees for Run and terminal input. Prevents file replacement from erasing unimported tool changes. Handles terminal reconnects and runtime replacement. Selects a credible sandbox and calculates runtime capacity.

Staff (L6+/E6+)

Defines ownership fences across coordinators, runtimes, and durable state. Proves file preservation across concurrent writes, open handles, and failed imports. Tests access revocation and uncertain command outcomes. Balances runtime capacity, start latency, and storage limits. Assess regional recovery only if the interviewer asks that follow-up.