Task Row Modifications
Reported by candidates from Notion's online assessment. Pattern, common pitfall, and the honest play if you blank under the timer.
The Notion OA reported in October 2025 looks like a data-structure question dressed up as a spreadsheet. Task Row Modifications gives you ADD, DELETE, MOVE and SUM on tasks that own rows, and the hinted structure is a queue. But the real answer is a map of maps plus a running total. Up to 20000 operations means you can't recompute sums by scanning rows each time. If the hash-map bookkeeping feels slippery under a timer, StealthCoder is the invisible safety net on the live OA. It reads the problem and hands you a working solution if you blank.
The problem
Each task owns zero or more integer-valued rows. Process these operations: ["ADD", taskId, rowId, value] adds a new row to a task. ["DELETE", taskId, rowId] deletes that row. ["MOVE", fromTaskId, toTaskId, rowId] removes the row from the source task and inserts the same row ID and value into the destination task. ["SUM", taskId] returns the decimal sum of every row currently owned by that task. An empty or unseen task sums to 0. Return the values produced by SUM operations in order. Function runTaskRowModifications(operations: String[][]) → String[] Examples Example 1 operations = [["ADD","t1","r1","4"],["ADD","t1","r2","7"],["SUM","t1"],["MOVE","t1","t2","r2"],["SUM","t1"],["SUM","t2"],["DELETE","t2","r2"],["SUM","t2"]] return = ["11","4","7","0"] Moving r2 transfers its value from t1 to t2. Deleting it then leaves t2 empty. Constraints 1 <= operations.length <= 20000. Task and row IDs are non-empty ASCII strings containing no whitespace. Values are decimal integers in [-10^9, 10^9]. An ADD row ID is absent from its task. A DELETE or MOVE source row exists, and a moved row ID is absent from the destination task. Every task sum fits a signed 64-bit integer.
Reported by candidates. Source: FastPrep
Pattern and pitfall
The trick: keep a hash map from taskId to another hash map of rowId to value, and a second map from taskId to its running sum. ADD inserts the row and adds the value to the sum. DELETE looks up the value, removes the row, and subtracts it. MOVE pops the value from the source (adjusting its sum), then inserts it into the destination (adjusting that sum). SUM is an O(1) lookup that defaults to 0 for unseen tasks. Every operation is O(1), so the total is O(n). Pitfalls: forgetting to update both sums on MOVE, crashing on a SUM for an unseen task, and using 32-bit ints when sums can exceed that range. Use a 64-bit type and return strings. The queue hint is misleading, since you only process operations in order. StealthCoder is your hedge on the live OA if the nested-map bookkeeping slips.
If you see this problem in your OA tomorrow, the play is to recognize the pattern in 30 seconds. StealthCoder buys you that recognition.
You can drill Task Row Modifications 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 passed his OA cold and still thinks the filter is broken.
Get StealthCoderRelated leaked OAs
You've seen the question.
Make sure you actually pass Notion's OA.
Notion reuses patterns across OAs. Built by an Amazon engineer who passed his OA cold and still thinks the filter is broken. Works on HackerRank, CodeSignal, CoderPad, and Karat.
Task Row Modifications FAQ
How hard is Task Row Modifications really?+
Easy to medium. There's no clever algorithm, just careful bookkeeping. Every operation is O(1) with hash maps. Most failures come from sloppy MOVE handling or missing defaults, not from the idea itself.
What's the trick to this Notion problem?+
Store rows per task in a nested hash map and keep a running sum per task. Update the sum on every ADD, DELETE and MOVE. Then SUM is a constant-time lookup instead of a scan over all rows.
Do I actually need a queue here?+
No. The hint says queue, but you just iterate through the operations in order and collect SUM results into a list. The state lives in hash maps. Don't force a queue into it.
What edge cases should I test?+
SUM on an unseen task returns 0. Moving the last row out of a task leaves its sum at 0. Negative values work in sums. Large values need 64-bit math. Output must be strings, so convert each SUM result before returning.
How do I prepare in 48 hours?+
Write this once from scratch with nested maps and a sum map. Then rehearse similar in-memory state problems like inventories or ledgers. Focus on keeping derived totals in sync on each mutation, since that's what this question tests.