Practice/LinkedIn/Design CoderPad

Design CoderPad

System DesignOptional

Problem Statement

Design a collaborative coding platform similar to CoderPad that allows users to write, edit, and execute code in real-time with features like syntax highlighting, multiple language support, and live collaboration for technical interviews.

The system blends two hard problems: low-latency real-time collaboration (presence, conflict resolution, cursor syncing) and safe, scalable code execution across many languages (resource isolation, queuing, streaming logs). A strong answer shows you can decompose the system, pick the right collaboration model (OT/CRDT), isolate untrusted code, and meet tight latency and reliability expectations.

Key Requirements

Functional

Session management -- users create or join a coding session via a shareable link with clear roles (interviewer/candidate) and permissions
Real-time collaboration -- users edit code together in real time with syntax highlighting, cursor presence, and basic IDE features
Code execution -- users execute code in multiple languages with optional stdin and see live stdout/stderr streamed back
Session history -- users save, restore, and replay session history (code edits and runs) for review or feedback

Non-Functional

Scalability -- support thousands of concurrent sessions with 2-5 participants each during peak interview hours
Reliability -- no data loss for code edits; session state survives server restarts
Latency -- keystroke-to-render latency under 100ms for all participants; code output streaming begins within 2 seconds of execution start
Security -- untrusted code execution must be fully sandboxed with strict resource limits and no network access

Interview Reports from Hello Interview

5 reports from candidates. Most recently asked at LinkedIn in Early December 2025.

Also commonly asked at: OpenAI, Meta.

What Interviewers Focus On

Based on real interview experiences, these are the areas interviewers probe most deeply:

1. Real-Time Collaboration and Conflict Resolution

Multiple users editing the same document simultaneously creates high contention on shared state. Interviewers want a specific conflict resolution strategy.

Hints to consider:

Use Operational Transformation (OT) with a server-authoritative model: the server sequences all operations and broadcasts the canonical state
Alternatively, use CRDTs for a peer-to-peer model that converges without central coordination
Implement cursor and selection presence: broadcast each user's cursor position and highlight their selections in different colors
Buffer operations locally and apply optimistically while awaiting server acknowledgment for responsive feel

2. Code Execution Safety and Isolation

Running arbitrary user code requires strong isolation to prevent security breaches and resource exhaustion.

Hints to consider:

Execute code in disposable containers or lightweight VMs (gVisor, Firecracker) with strict CPU, memory, and time limits
Disable network access within execution sandboxes to prevent data exfiltration or attacks
Use a separate worker pool for code execution, isolated from the collaboration servers
Implement kill mechanisms for runaway processes and stream partial output even if execution is terminated

3. Execution Output Streaming

Users expect to see stdout/stderr as the program runs, not after it finishes. Interviewers look for a streaming design.

Hints to consider:

Use WebSocket connections to stream output lines from the execution worker to all session participants in real time
Buffer output in Redis Streams or a similar ordered log that participants can subscribe to
Handle large outputs gracefully: truncate after a configurable limit (e.g., 10K lines) and notify the user
Stream compilation errors separately from runtime output with clear visual distinction

4. Session State and Replay

Session history enables post-interview review and feedback. Interviewers want durable session state.

Hints to consider:

Persist every edit operation (OT operations or CRDT deltas) in an append-only log for complete replay
Take periodic snapshots of the document state to avoid replaying from the beginning
Store execution records (code version, input, output, timing) alongside edit history
Support time-based replay that shows the document evolving and execution results in chronological order

Practice/LinkedIn/Design CoderPad

Design CoderPad

System DesignOptional

Problem Statement

Key Requirements

Functional

Session management -- users create or join a coding session via a shareable link with clear roles (interviewer/candidate) and permissions
Real-time collaboration -- users edit code together in real time with syntax highlighting, cursor presence, and basic IDE features
Code execution -- users execute code in multiple languages with optional stdin and see live stdout/stderr streamed back
Session history -- users save, restore, and replay session history (code edits and runs) for review or feedback

Non-Functional

Scalability -- support thousands of concurrent sessions with 2-5 participants each during peak interview hours
Reliability -- no data loss for code edits; session state survives server restarts
Latency -- keystroke-to-render latency under 100ms for all participants; code output streaming begins within 2 seconds of execution start
Security -- untrusted code execution must be fully sandboxed with strict resource limits and no network access

Interview Reports from Hello Interview

5 reports from candidates. Most recently asked at LinkedIn in Early December 2025.

Also commonly asked at: OpenAI, Meta.

What Interviewers Focus On

Based on real interview experiences, these are the areas interviewers probe most deeply:

1. Real-Time Collaboration and Conflict Resolution

Multiple users editing the same document simultaneously creates high contention on shared state. Interviewers want a specific conflict resolution strategy.

Hints to consider:

Use Operational Transformation (OT) with a server-authoritative model: the server sequences all operations and broadcasts the canonical state
Alternatively, use CRDTs for a peer-to-peer model that converges without central coordination
Implement cursor and selection presence: broadcast each user's cursor position and highlight their selections in different colors
Buffer operations locally and apply optimistically while awaiting server acknowledgment for responsive feel

2. Code Execution Safety and Isolation

Running arbitrary user code requires strong isolation to prevent security breaches and resource exhaustion.

Hints to consider:

Execute code in disposable containers or lightweight VMs (gVisor, Firecracker) with strict CPU, memory, and time limits
Disable network access within execution sandboxes to prevent data exfiltration or attacks
Use a separate worker pool for code execution, isolated from the collaboration servers
Implement kill mechanisms for runaway processes and stream partial output even if execution is terminated

3. Execution Output Streaming

Users expect to see stdout/stderr as the program runs, not after it finishes. Interviewers look for a streaming design.

Hints to consider:

Use WebSocket connections to stream output lines from the execution worker to all session participants in real time
Buffer output in Redis Streams or a similar ordered log that participants can subscribe to
Handle large outputs gracefully: truncate after a configurable limit (e.g., 10K lines) and notify the user
Stream compilation errors separately from runtime output with clear visual distinction

4. Session State and Replay

Session history enables post-interview review and feedback. Interviewers want durable session state.

Hints to consider:

Persist every edit operation (OT operations or CRDT deltas) in an append-only log for complete replay
Take periodic snapshots of the document state to avoid replaying from the beginning
Store execution records (code version, input, output, timing) alongside edit history
Support time-based replay that shows the document evolving and execution results in chronological order