Coinbase·Software Engineer·Technical Phone Screen·Intermediate

Intermediate

Jun 2026

Summary

Coinbase software engineer interview with a multi-part coding problem centered on building an in-memory file storage system from scratch. The problem kept growing with each new operation added, which was the whole point I think.

Questions Asked (2)

Design and implement an in-memory cloud storage service supporting user creation with capacity limits, file add/get operations, and capacity updates with automatic eviction of the largest files.

System DesignAlgorithms & Data StructuresData Modeling

Author's notes

The first few operations felt manageable.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and constraints, then define the data model and operations. Propose a design using appropriate data structures (e.g., hash maps and heaps) to efficiently support user creation, file operations, and capacity updates with eviction. Discuss trade-offs and potential optimizations.

Pro tip: Demonstrate awareness of concurrency and scalability by mentioning thread-safety and potential distributed extensions, even though the problem is in-memory. Also, explicitly state assumptions about file sizes and eviction policies.

1. Clarify Requirements

Ask questions to understand expected scale, file size distribution, eviction policy details (e.g., evict largest files until under capacity), and whether operations need to be thread-safe.

2. Define Data Model

Outline classes for User (with capacity and current usage) and File (with name and size). Choose data structures: a hash map for users, and for each user, a hash map for files and a max-heap to track largest files.

3. Design Operations

Describe algorithms for addFile (check capacity, evict if needed, add file), getFile (retrieve by name), and updateCapacity (adjust limit, evict if necessary). Ensure eviction efficiently removes largest files.

4. Analyze Complexity

Discuss time and space complexity of each operation. For example, addFile may involve O(log n) for heap operations, getFile O(1), and updateCapacity O(k log n) where k is number of evictions.

5. Discuss Trade-offs and Extensions

Mention alternative data structures (e.g., balanced BST, skip list) and trade-offs. Consider concurrency (locks, concurrent data structures) and how the design could scale to distributed storage.

Key Points to Mention

Use of hash maps for O(1) average-time user and file lookups.
Max-heap (priority queue) to efficiently track and evict largest files.
Handling capacity updates: evict largest files until total size <= new capacity.
Edge cases: adding file larger than capacity, updating capacity to less than current usage, duplicate file names.
Thread-safety considerations: locks per user or concurrent data structures.
Trade-offs between different data structures and potential optimizations.

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

Extend the storage service with COMPRESS_FILE and DECOMPRESS_FILE operations that rename files, halve or double their sizes, and enforce constraints like suffix checks and capacity validation on decompression.

Algorithms & Data StructuresTechnical Trade-offsSystem Design

Author's notes

Compress was fine, just rename the key and floor-divide the size.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying the exact semantics of COMPRESS_FILE and DECOMPRESS_FILE, including how renaming works, size changes, and all constraints. Then design a data structure to track file metadata and capacity, and implement the operations with careful validation and atomic updates. Discuss trade-offs between simplicity and efficiency, and consider edge cases like missing files, invalid suffixes, and capacity overflow.

Pro tip: Demonstrate production mindset by discussing atomicity and rollback: if decompression fails partway (e.g., due to capacity), the file should remain unchanged. Also, mention that suffix checks should be case-insensitive and consider hidden files or multiple dots.

1. Clarify Requirements and Constraints

Ask questions to pin down exact behavior: What are the naming rules for compressed files? How is capacity defined and updated? What happens if a file already exists? Are operations atomic?

2. Design Data Structures

Choose a map from filename to file metadata (size, compressed flag) and a variable for total used capacity. Consider whether to store compressed files with a suffix or as separate entries.

3. Implement COMPRESS_FILE

Validate that the file exists and is not already compressed. Check that the new name (with suffix) does not conflict. Update size to half, rename, and adjust capacity if needed.

4. Implement DECOMPRESS_FILE

Validate that the file exists, has the correct suffix, and is compressed. Check that doubling its size does not exceed capacity. If valid, rename to remove suffix, double size, and update capacity.

5. Handle Edge Cases and Trade-offs

Discuss error handling, atomicity (e.g., using transactions or rollback), and performance implications. Mention possible optimizations like lazy capacity checks or concurrent access considerations.

Key Points to Mention

Use a hash map for O(1) file lookups and a separate variable for total used capacity.
Enforce suffix checks: compressed files must end with a specific suffix (e.g., '.gz'), and decompression requires that suffix.
Capacity validation: decompression must ensure new size (2x) does not exceed total capacity; compression frees capacity.
Atomicity: ensure operations are all-or-nothing to avoid inconsistent state if an error occurs mid-operation.
Edge cases: file not found, already compressed/decompressed, name conflicts after renaming, and capacity exactly at limit.
Trade-offs: simplicity vs. efficiency, e.g., recomputing capacity vs. maintaining incrementally, and handling concurrent operations.

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