Openai·Software Engineer·Onsite - System Design / Architecture·Senior

SeniorPrefer not to say

Apr 2026

Summary

System design round at OpenAI for a software engineer role. The core problem was building an in-memory social network with snapshot support, which sounds manageable until you get into the versioning rabbit hole.

Questions Asked (1)

Design an in-memory social network that supports adding users, adding and removing friendships, and retrieving a user's friends. Then extend it to support snapshots: a snapshot() call that captures the current state of the graph, and a getFriendsAt(userId, snapshotId) that returns a user's friends as of that snapshot. Walk through your data representation choices and the time/space trade-offs of different snapshotting strategies.

System DesignTechnical Trade-offsData Modeling

Author's notes

I started with the adjacency map part, which felt fine.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by defining a simple in-memory graph representation using adjacency sets for O(1) friendship operations, then introduce snapshots by discussing strategies like full copies, copy-on-write, and persistent data structures. Compare time/space trade-offs, emphasizing how persistent data structures (e.g., immutable balanced trees) enable efficient snapshots with structural sharing. Conclude with a recommendation based on expected read/write patterns and snapshot frequency.

Pro tip: Mention that snapshots can be implemented with a versioned adjacency list using persistent data structures, and highlight that this approach is used in real systems like Git and Datomic. This shows awareness of production-grade solutions.

1. Clarify requirements and constraints

Ask about expected scale (number of users, friendships), read/write ratio, snapshot frequency, and whether snapshots need to be immutable or can be garbage-collected. This guides data structure choices.

2. Design basic graph operations

Propose an adjacency list using hash sets (or hash maps) for O(1) average-case add/remove friendship and O(1) retrieval of friends. Discuss memory overhead and alternatives like sorted arrays for cache efficiency.

3. Introduce snapshotting strategies

Present three approaches: (a) full copy of the graph per snapshot (simple, high space), (b) copy-on-write with versioning (moderate space, O(1) snapshot), (c) persistent data structures (e.g., immutable balanced trees) with structural sharing (low space, O(log n) updates).

4. Analyze time/space trade-offs

Compare each strategy: full copy uses O(V+E) space per snapshot and O(1) snapshot time; copy-on-write uses O(1) snapshot time but O(V+E) worst-case space; persistent structures use O(log n) update time and O(1) snapshot time with O(V+E) total space across all versions. Discuss read performance for getFriendsAt.

5. Recommend and justify

Choose a strategy based on requirements: for frequent snapshots and infrequent writes, persistent data structures are ideal; for infrequent snapshots, full copy may suffice. Mention hybrid approaches like periodic full snapshots with incremental deltas.

Key Points to Mention

Adjacency list representation with hash sets for O(1) friendship operations
Snapshot strategies: full copy, copy-on-write, persistent data structures
Time/space trade-offs: snapshot creation time, update time, memory overhead
Structural sharing in persistent data structures (e.g., HAMT, balanced trees)
Versioning and garbage collection of old snapshots
Read performance of getFriendsAt: O(1) for full copy, O(log n) for persistent structures

AI-generated suggestions, not part of the candidate's original notes. May be inaccurate — verify before relying on them.