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

SeniorPrefer not to say

May 2026

Summary

Coinbase system design round, basically asked me to build a key-value store from scratch and then talk through how I'd extend it. Not the hardest thing in the world but the follow-up questions about future extensions tripped me up more than I expected.

Questions Asked (1)

Design a basic in-memory key-value store with store(key, value) and read(key) operations. Walk through your data structure choice, collision handling, overwrite behavior, and how you'd handle reads on missing keys.

System DesignAlgorithms & Data StructuresData Modeling

Author's notes

I jumped straight to hash map, which was obviously right, but then kind of fumbled when they pushed on collision handling.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements (e.g., expected operations, concurrency, persistence) and then propose a hash table as the core data structure. Walk through the implementation details: hash function, collision resolution (e.g., chaining or open addressing), overwrite semantics, and missing key handling. Discuss trade-offs and potential optimizations like resizing.

Pro tip: Mention that in a real system like Coinbase, you'd also consider thread-safety and persistence, but for an in-memory store, a concurrent hash map or sharded locks could be used. This shows awareness of production concerns.

1. Clarify Requirements

Ask about expected scale, concurrency needs, and whether persistence is required. Confirm that only store and read operations are needed.

2. Choose Data Structure

Propose a hash table for O(1) average-case time complexity. Explain why it's suitable for key-value storage.

3. Handle Collisions

Describe collision resolution strategies: separate chaining (linked lists) or open addressing (linear probing). Discuss trade-offs.

4. Define Operations

Explain store(key, value): if key exists, overwrite value; else insert. Explain read(key): return value if key exists, else return null or throw an exception (depending on requirements).

5. Discuss Edge Cases and Optimizations

Cover resizing when load factor exceeds threshold, handling null keys/values, and potential concurrency mechanisms if needed.

Key Points to Mention

Hash table provides O(1) average time for store and read.
Collision handling: separate chaining vs. open addressing.
Overwrite behavior: update existing key's value.
Missing key: return null, throw exception, or use a sentinel value.
Load factor and resizing to maintain performance.
Thread-safety considerations (e.g., synchronized methods, concurrent hash map).

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