Snapshot Set Iterator
Reported by candidates from Databricks's online assessment. Pattern, common pitfall, and the honest play if you blank under the timer.
Databricks reported this one in July 2025, and the whole problem comes down to one choice: what structure holds an insertion-ordered set that supports remove and re-add cheaply. It's an insertion-ordered set plus snapshot iterators, and the examples look friendlier than the edge cases. If you've got an OA invite, expect to spend your time on ordering and snapshots, not on fancy algorithms. Get the structure right and the rest is bookkeeping. StealthCoder sits invisibly on your screen as a safety net if you blank mid-assessment, but you can walk in knowing the plan already.
The problem
Process a finite sequence of operations on an insertion-ordered set and its snapshot iterators. Each operation is one of: ["ADD", value]: add value when absent. Adding an existing value does nothing. ["REMOVE", value]: remove value when present. Removing a missing value does nothing. A removed value that is later added again appears at the end of the insertion order. ["ITERATOR", iteratorId]: create a new iterator over a snapshot of the current values in insertion order. ["NEXT", iteratorId]: return the next value from that iterator, or "<END>" when it is exhausted. Mutations after an iterator is created never change that iterator's snapshot. Return one string for every NEXT operation, in operation order. Function runSnapshotSet(operations: String[][]) → String[] Examples Example 1 operations = [["ADD","a"],["ADD","b"],["ITERATOR","it"],["ADD","c"],["REMOVE","a"],["NEXT","it"],["NEXT","it"],["NEXT","it"]] return = ["a","b","<END>"] The iterator snapshots [a,b]. Adding c and removing a afterward do not affect it, so its two values are followed by the exhaustion sentinel. Example 2 operations = [["ADD","x"],["ADD","y"],["ADD","x"],["REMOVE","x"],["ADD","x"],["REMOVE","z"],["ITERATOR","s"],["NEXT","s"],["NEXT","s"],["NEXT","s"]] return = ["y","x","<END>"] The duplicate add and missing remove are no-ops. Removing and re-adding x moves it behind y in the current insertion order. Constraints 1 <= operations.length <= 10000 Every operation has a valid name and arity. Values and iterator IDs are non-empty strings. Values are never equal to "<END>". Every iterator ID is created exactly once before its first NEXT.
Reported by candidates. Source: FastPrep
Pattern and pitfall
The trick is an ordered hash structure. A dict that preserves insertion order works, since deleting a key and re-adding it puts it at the end, which is exactly the rule here. In Java, use LinkedHashSet. ADD checks membership, REMOVE deletes if present. ITERATOR copies the current keys into a list and stores it with a position index in a map keyed by iterator ID. NEXT returns the item at the index and advances, or returns "<END>" past the end. The common pitfall is storing a live view instead of a copy, so later mutations leak into the iterator. Another is thinking a duplicate ADD should refresh position. It shouldn't. With up to 10000 operations, copying per iterator is fine. If you freeze on the live OA, StealthCoder is the hedge, but this is a short solution you can write from memory.
If this hits your live OA and you blank, StealthCoder solves it in seconds, invisible to the proctor.
You can drill Snapshot Set Iterator 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. Built by an Amazon engineer who would have shipped this the night before his JPMorgan OA if he'd had it.
Get StealthCoderRelated leaked OAs
You've seen the question.
Make sure you actually pass Databricks's OA.
Databricks reuses patterns across OAs. Built by an Amazon engineer who would have shipped this the night before his JPMorgan OA if he'd had it. Works on HackerRank, CodeSignal, CoderPad, and Karat.
Snapshot Set Iterator FAQ
How hard is the Snapshot Set Iterator problem really?+
Easy to medium. There's no clever algorithm, just the right data structure and careful reading. Most failures come from live views instead of copies, or from mishandling re-added values. If you know ordered sets, you can finish it quickly.
What's the core trick?+
Use an insertion-ordered set. Removing and re-adding a value moves it to the end, and duplicate adds change nothing. On ITERATOR, copy the current values into a list and keep an index per iterator ID in a map.
Why must the iterator copy the data?+
Mutations after creation must not change the snapshot. If your iterator points at the live set, later ADD and REMOVE calls would change what it returns. Example 1 tests exactly this, where c is added and a is removed after the iterator exists.
Does a duplicate ADD change the order?+
No. Adding an existing value is a no-op, so its position stays put. Only a REMOVE followed by a fresh ADD moves it to the end. Example 2 shows x landing behind y after that sequence.
How do I prepare in 48 hours?+
Write this once from scratch with an ordered set and a map of iterator IDs to snapshot lists with indexes. Then test both examples plus a case with a NEXT after exhaustion. Check that you return one string per NEXT, in operation order.