Grammarly·Software Engineer·Technical Phone Screen·Intermediate

IntermediatePrefer not to say

Jun 2026Remote

Summary

Grammarly SWE interview with a coding round focused on building a transactional key-value store from scratch. Not the hardest problem conceptually, but the details pile up fast and I underestimated how much the nested transaction bookkeeping would slow me down.

Questions Asked (1)

Design and implement an in-memory key-value store that supports set, delete, and count operations, along with nested transactions using begin, commit, and rollback.

Algorithms & Data StructuresSystem DesignTechnical Trade-offs

Author's notes

I got the basic set/delete/count part down quickly.

Create a free account to read the full note

AI HintsAI Generated

Suggested Approach

Start by clarifying requirements and constraints, then propose a design using a stack of transaction layers, each maintaining a map of changes. Discuss the trade-offs between different data structures and transaction isolation levels, and outline how to implement set, delete, count, begin, commit, and rollback efficiently.

Pro tip: Emphasize that rollback should discard only the current transaction's changes, and commit should merge changes into the parent transaction, not directly to the main store unless it's the outermost transaction. This shows you understand nested transaction semantics.

1. Clarify Requirements

Ask about expected operations, transaction nesting depth, concurrency requirements, and performance constraints. Confirm whether reads should see uncommitted changes within the same transaction.

2. Design Data Structures

Propose using a main key-value store (e.g., hash map) and a stack of transaction layers, each layer storing a map of changes (key to value or deletion marker). This allows efficient rollback and commit.

3. Implement Operations

For set/delete, record changes in the current transaction layer. For count, traverse layers from top to bottom to find the latest value for each key, or maintain a count per layer. For begin, push a new layer; for commit, merge current layer into parent; for rollback, pop the current layer.

4. Analyze Trade-offs

Discuss time and space complexity: set/delete O(1), count O(number of layers * keys) or optimized with per-layer counts. Consider alternatives like copy-on-write or versioning, and their pros/cons.

5. Test and Edge Cases

Mention testing nested transactions, rollback of deletes, commit of empty transactions, and handling of keys that exist in multiple layers. Also consider concurrency if required.

Key Points to Mention

Use a stack of transaction layers to support nested transactions.
Each layer stores a map of changes (key to value or tombstone for deletion).
Commit merges the current layer into the parent layer, not directly to the main store unless it's the outermost transaction.
Rollback simply discards the current layer.
Count operation must consider all layers, with the topmost layer taking precedence.
Time complexity: set/delete O(1), count O(number of layers) or optimized with per-layer counts.
Trade-offs: memory overhead vs. simplicity, isolation levels, and concurrency control.

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