DocuSign·Software Engineer·Onsite - System Design / Architecture·Intermediate

IntermediatePrefer not to say

Jun 2026

Summary

DocuSign software engineer interview that leaned heavily on system design fundamentals. The main problem was building an in-memory key-value store from scratch, which sounds straightforward until you have to justify every decision out loud.

Questions Asked (1)

Design and implement an in-memory key-value store with put, get, update, delete, and exists operations. Justify your choice of underlying data structure, analyze the time and space complexity, and walk through edge cases like duplicate keys and missing key lookups.

System DesignAlgorithms & Data StructuresTechnical Trade-offs

Author's notes

I went with a hash map immediately, which I think was fine, but then they pushed me on whether I'd considered ordered access patterns and I kind of fumbled.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements (e.g., thread safety, persistence, expected operations) and then propose a hash table as the core data structure. Implement the operations with careful handling of edge cases, and analyze time/space complexity. Discuss trade-offs and potential improvements.

Pro tip: Mention that in real-world systems, thread safety and memory management are critical; briefly discuss how you would handle concurrency (e.g., using locks or concurrent data structures) and eviction policies like LRU if the store grows unbounded.

1. Clarify Requirements

Ask about expected operations, data types, thread safety, persistence, and performance constraints to tailor your design.

2. Choose Data Structure

Select a hash table for O(1) average-case operations, and justify why it's better than alternatives like arrays or trees for this use case.

3. Implement Operations

Write pseudocode or explain how each operation (put, get, update, delete, exists) works, including handling of duplicate keys and missing keys.

4. Analyze Complexity

Discuss time and space complexity for each operation, noting average vs. worst-case scenarios and potential collisions.

5. Address Edge Cases and Trade-offs

Cover edge cases like null keys/values, duplicate keys, missing keys, and discuss trade-offs (e.g., memory overhead, resizing, concurrency).

Key Points to Mention

Hash table provides O(1) average time for put, get, update, delete, and exists.
Handling duplicate keys: put should overwrite existing value; update can be explicit or same as put.
Missing key lookups: get and delete should return null/false or throw exception based on contract.
Space complexity is O(n) for n entries, with overhead for hash table structure.
Collision resolution strategies (chaining vs. open addressing) affect performance.
Thread safety considerations: use synchronized methods or ConcurrentHashMap for concurrent access.

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