Versioned Key-Value Store with Suffix Truncation
Reported by candidates from Nuro's online assessment. Pattern, common pitfall, and the honest play if you blank under the timer.
Nuro reportedly served this one in September 2026, and it looks scarier than it is. Strip the wording and it's a per-key sorted map with three operations: insert or overwrite, floor lookup, and chop off everything from a version upward. That's it. You'll see 100000 operations and think you need a fancy tree, but the delete rule makes it simpler than it sounds. If you've got an OA invite for Nuro, nail the data structure choice first and the code writes itself. If your head goes blank mid-assessment, StealthCoder is the invisible safety net running on your desktop.
The problem
Process an ordered array operations for a versioned key-value store. Each row has one of these forms: ["PUT", key, version, value]: store value for key at version. Replace the value when that exact key and version already exists. ["GET", key, version]: return the value at the greatest stored version less than or equal to version, or "null" when no such version exists. ["DELETE", key, version]: remove every stored value for key whose version is greater than or equal to version. Return one string per operation in input order. PUT and DELETE return "null"; GET returns its selected value or "null". The operation order is one committed linearization order. Each operation must observe every earlier operation in the array. Function processVersionedStore(operations: String[][]) → String[] Examples Example 1 operations = [["PUT","a","1","red"],["PUT","a","4","blue"],["GET","a","3"],["GET","a","4"],["DELETE","a","3"],["GET","a","10"],["PUT","a","1","green"],["GET","a","1"]] return = ["null","null","red","blue","null","red","null","green"] The first read uses version 1, and the second uses exact version 4. Deleting at 3 removes version 4 but preserves version 1. The later put replaces that exact version. Example 2 operations = [["PUT","x","2","x2"],["PUT","x","5","x5"],["PUT","y","3","y3"],["GET","x","1"],["GET","x","4"],["DELETE","x","2"],["GET","x","9"],["GET","y","3"]] return = ["null","null","null","null","x2","null","null","y3"] Keys have independent histories. The delete removes both versions of x while leaving y unchanged. Constraints 1 <= operations.length <= 100000. Every row is exactly one valid PUT, GET, or DELETE form. Every key and value is a non-empty string of at most 100 characters. Every version is a base-10 integer string in the range [0, 1000000000]. The total number of characters across all rows is at most 2000000.
Reported by candidates. Source: FastPrep
Pattern and pitfall
What it really reduces to: a hash map from key to a list of (version, value) pairs kept sorted by version. GET is a floor query, so binary search for the greatest version <= target. DELETE removes every version >= target, which is a suffix of the sorted list, so you binary search the cut point and truncate. PUT binary searches too: if the exact version exists, overwrite, otherwise insert. The pitfall is insertion in the middle of an array, which is O(n) per op. Since deletes truncate suffixes and puts can land anywhere, a sorted container (TreeMap style) is cleaner if your language has one. Parse versions as integers, not strings, or ordering breaks on "10" vs "4". Return the literal string "null", not a null value. If you freeze on the insertion cost, StealthCoder can hand you a working solution live during the OA.
StealthCoder is the hedge for the one pattern you didn't drill. It runs invisibly during the screen share.
You can drill Versioned Key-Value Store with Suffix Truncation cold, or you can hedge it. StealthCoder runs invisibly during screen share and surfaces a working solution in under 2 seconds. The proctor sees the IDE. They don't see what's behind it. If you're reading this with an OA window open, you're who this was built for.
Get StealthCoderRelated leaked OAs
This OA pattern shows up on LeetCode as time based key value store. If you have time before the OA, drill that.
You've seen the question.
Make sure you actually pass Nuro's OA.
Nuro reuses patterns across OAs. If you're reading this with an OA window open, you're who this was built for. Works on HackerRank, CodeSignal, CoderPad, and Karat.
Versioned Key-Value Store with Suffix Truncation FAQ
What's the trick in the Nuro versioned key-value store problem?+
Keep a separate sorted structure of versions per key. GET becomes a floor lookup via binary search, and DELETE becomes a suffix truncation. Once you see those two moves, every operation is O(log n) or close to it.
How hard is this OA question really?+
Medium. There's no deep algorithm, just careful data structure choice and edge cases. Most failures come from string versus integer comparison, forgetting the overwrite on an exact version, or returning a real null instead of the string "null".
Do I need a TreeMap or can I use a plain list?+
A list with bisect works if you handle insertion. Appends are fast when versions arrive increasing, but random puts cost O(n) shifts. With 100000 operations that's usually still fine, but a sorted map avoids the worry if your language offers one.
What edge cases should I test before submitting?+
Test a GET on a key that was never stored, a GET below the smallest version, a PUT overwriting an exact version, and a DELETE that removes everything for a key followed by a new PUT. Also check version 0 and versions like 10 versus 4 for numeric ordering.
How do I prepare for this in 48 hours?+
Write a floor lookup with binary search from scratch, then a per-key map of sorted versions. Practice truncation after a binary search cut. Then run both examples by hand, since the delete-then-put sequence in example 1 catches most bugs.