Coding questions · DoorDash
Implement a hierarchical key-value store
Implement a hierarchical key-value store evaluates algorithm design, data structures, correctness, complexity, edge cases, and implementation details in a realistic interview setting. A strong answer states assumptions, handles edge cases, explains trade-offs, and shows how to validate the result clearly.
Implement an in-memory hierarchical key-value store where keys are UNIX-like paths joined by '/'. The root node is '/' with initial value '#'. Each node stores a string value. Support: (1) Create(path, value): create a node; parent must exist; fail if the node already exists. (2) SetValue(path, value): set the value; node must exist. (3) GetValue(path): return the value; node must exist. (4) Delete(path): delete the node only if it has no children; node must exist. Define the class interface, choose appropriate data structures, and provide time/space complexities. Include unit tests and discuss how you would add concurrency safety and optional persistence to disk.
What a Strong Answer Covers
- A clear algorithm with the right data structures and enough pseudocode or code-level detail to implement it.
- A correctness argument that explains why the algorithm covers all required cases.
- Time and space complexity, plus at least one alternative approach when relevant.
- Focused tests for normal cases, edge cases, and failure modes.
Follow-up Questions
- How would the approach change if the input were streaming or too large for memory?
- What invariants would you assert in production code?
- Which tests would catch off-by-one, duplicate, or tie-breaking bugs?
Implement a Hierarchical Key-Value Store
Design an in-memory hierarchical key-value store where keys are UNIX-like paths joined by '/'. The root node is '/' and starts with value '#'. Every node stores a single string value and may have child nodes.
Implement a driver solution(operations) that replays a list of operations and returns a list with one result per operation. Each operation is a list whose first element is the op name:
['create', path, value]— Create a new node atpathwithvalue. The parent node must already exist and the node must NOT already exist. ReturnsTrueon success,Falseotherwise.['set', path, value]— Set the value of an existing node. The node must exist. ReturnsTrueif updated,Falseif the node does not exist.['get', path]— Return the node's string value, orNoneif the node does not exist.['delete', path]— Delete the node only if it exists AND has no children (and is not the root). ReturnsTrueif deleted,Falseotherwise.
The store is pre-populated with the root: get('/') returns '#'.
Example:
operations = [
['create', '/a', 'x'], # -> True
['create', '/a/b', 'c'], # -> True
['delete', '/a'], # -> False (has child '/a/b')
['get', '/a/b'], # -> 'c'
['delete', '/a/b'], # -> True
['delete', '/a'] # -> True (now a leaf)
]
solution(operations) == [True, True, False, 'c', True, True]
Constraints
- Paths are non-empty strings beginning with '/'.
- The root '/' always exists with initial value '#' and cannot be deleted.
- Create fails if the immediate parent does not exist or if the node already exists.
- Set/Get require the target node to already exist.
- Delete requires the node to exist and to have no children.
- Values are arbitrary strings.
Hints
- Store every node under its full path (e.g. '/a/b') in a flat hash map keyed by path, instead of nesting dicts — this makes existence checks O(1).
- Keep a separate children map (path -> set of child full-paths) so Delete can reject non-leaf nodes in O(1) and Create can validate the parent quickly.
- Derive a node's parent by trimming after the last '/'; the parent of '/a' is '/', and the parent of '/a/b' is '/a'. Handle the root '/' as a special case.
- For concurrency, guard the maps with a read-write lock (or per-subtree locks); for persistence, append each mutating op to a write-ahead log and replay it on startup.
Solution
Solution Alignment
The prompt asks for an implementation-level answer. The safest way to present it is to define the state, maintain clear invariants, then walk through complexity and tests.
Problem Restatement
Implement an in-memory hierarchical key-value store where keys are UNIX-like paths joined by '/'. The root node is '/' with initial value '#'. Each node stores a string value. Support: ( 1) Create(path, value): create a node; parent must exist; fail if the node already exists. ( 2) SetValue(path, value): set the value; node must exist. ( 3) GetValue(path): return the value; node must exist. ( 4) Delete(path): delete the node only if it has no children; node must exist. Define the class interface, choose appropriate data structures, and provide time/space complexities. Include unit tests and discuss how you would add concurrency safety and optional persistence to disk.
Recommended Approach
Model the states explicitly and use BFS for unweighted shortest paths, Dijkstra for weighted non-negative paths, or topological DP for DAGs. Track visited states at the right granularity so cycles do not cause repeated work.
Correctness
The implementation should maintain an invariant after each loop or operation that directly matches the problem statement. At termination, that invariant implies the returned value has considered every valid candidate exactly once, or has preserved the required data-structure state after every API call.
Complexity
BFS is O(V + E) time and O(V) space for a standard graph. Expanded-state problems multiply those bounds by the number of state dimensions.
Edge Cases and Tests
Disconnected graph, source equals target, cycles, duplicate edges, unreachable target, and whether the answer counts nodes, edges, moves, or transfers.