Design a Real-Time Collaborative Coding Interview Pad, Then Threat-Model It

Design a browser-based collaborative coding pad of the kind hiring teams use for live technical interviews, and then threat-model the system you designed. Assume the usual scope for this kind of product. An interviewer creates a pad and shares a join link with a candidate. Everyone in the pad edits the same file in real time and sees the others' cursors and selections. Participants choose a programming language, press Run, and see the program's output appear on every screen. After the interview, the interviewer can reopen the pad and play back how the code evolved. The round has two phases. First you design a system that actually works; then you switch to a security perspective and build a threat model on top of the architecture you just drew. Leave time for both: a polished functional design with no security analysis, or a list of generic threats that never refers to your components, does not answer the prompt. ### Constraints and Clarifications - In scope: pad creation and sharing, real-time co-editing with presence, language selection, code execution with output streamed to all participants, and post-session playback. - Out of scope unless you choose to add it: video and audio, interview scheduling, and candidate scoring. - No scale or latency targets were given; propose your own and use them consistently. - Treat every program a participant runs as untrusted: anyone who can open a pad can submit code to your servers. ### Clarifying Questions - Who may join a pad: anyone holding the link, or only invited and authenticated users? Can the interviewer lock or end a pad? - How many participants does a pad have, and how many pads are live at peak? - Which languages must Run support, and what time and memory limits should a run have? - Is the service multi-tenant, shared by many hiring companies, and are there limits on where candidate data may be stored? - How long are pads and their history retained, and who may view them afterwards? ### Part 1 — Design the working system Lay out the architecture: the client, the real-time collaboration path, the code execution path and the storage behind them. Explain how simultaneous edits from two people end up as the same document on every screen, how a press of Run turns into output on all participants' screens, what you store and where, how playback works, and how the system scales and behaves when a component fails. ```hint Decide who orders the edits Before choosing a technology, decide which component, if any, gets to put two simultaneous edits into a single order, and what a client should do with a remote edit that arrives while it still has unsent changes of its own. ``` #### What This Part Should Cover - A concrete component layout with APIs and a data model - A convergence strategy for concurrent edits, including reconnects and server failure - The execution path: queuing, the isolation boundary, resource limits and output streaming - Scaling and failure handling for long-lived connections and for the execution fleet ### Part 2 — Threat-model your design Treat your Part 1 diagram as the system under review. Identify the assets worth protecting, the actors who might attack them and the trust boundaries in your design, enumerate the threats that matter most, and propose the controls you would build. Rank the threats and say which you would fix before launch, which you would accept or monitor, and how you would detect and respond to an attack in progress. ```hint Walk your own diagram Go one boundary at a time; at each crossing, ask who controls the data that crosses it and what they could gain by making it malicious. ``` #### Clarifying Questions for this Part - Which incident would hurt customers most: a candidate seeing the interview question early, candidate code leaking, another company reading a pad, or the execution fleet being abused? - Do customers expect audit logs of who opened or viewed a pad? #### What This Part Should Cover - Assets, actors and trust boundaries mapped onto the specific components from Part 1 - A structured enumeration of threats, with the execution boundary analyzed the way an attacker would approach it - Specific, layered controls plus detection and incident response - Prioritization by likelihood and impact, with residual risk stated ### What a Strong Answer Covers - Both phases completed, with the threat model tied to concrete components rather than a generic checklist - A convergence approach for concurrent edits that holds up under simultaneous typing, reconnects and server restarts - Isolation of untrusted code covering escape, network egress and resource exhaustion - Access control for pads, role separation between interviewer and candidate, and isolation between customer companies - Explicit trade-offs between isolation strength, run latency and cost - Pacing and depth appropriate for a senior candidate who drives the discussion ### Follow-up Questions - A researcher reports that a submitted program can read environment variables holding credentials on the execution host. Walk through your response and the structural fix. - How would you detect and stop people using pads to mine cryptocurrency or to launch attacks from your execution fleet? - An interviewer pastes the question into the pad an hour before the session. How do you keep the candidate from seeing it early? - How does the design change if some customers require that candidate code and output never leave their region?