Device Registry Operations
Reported by candidates from OnePay's online assessment. Pattern, common pitfall, and the honest play if you blank under the timer.
The mistake that sinks a first attempt on this OnePay problem is the UPDATE precedence. It's a September 2026 report, and it looks like a long spec but it's plain simulation with a hash map. Parse the rules, process each operation in order, and keep the output strings exact. Nothing here is algorithmically hard. The risk is skimming past one rule and failing a hidden test. If you blank on the details live, StealthCoder runs invisibly on your screen and gives you a working solution as a safety net.
The problem
You maintain an in-memory registry of devices. Each device has an ID, a type, a current state, a registration time, a last-maintenance time, and a failure count. The array typeStateRules defines which states are allowed for each device type. Each rule has the form type:state1|state2|.... Types are unique. Process every string in operations in order. Each operation uses one of these formats: REGISTER id type state registeredAt lastMaintenanceAt failureCount COUNT_ACTIVE UPDATE now maintenanceAgeLimit failureLimit Registration A REGISTER operation succeeds only when all of the following are true: The device ID is not already registered. The device type appears in typeStateRules. The requested state is allowed for that type. registeredAt is nonnegative. lastMaintenanceAt is at least registeredAt. failureCount is nonnegative. Append OK when registration succeeds. Otherwise append REJECTED and leave the registry unchanged. Active Counts A COUNT_ACTIVE operation counts devices whose current state is exactly ACTIVE. Append the positive counts as comma-separated type=count entries in lexicographic type order. Omit types whose count is zero. If no device is active, append the empty string. Batch Status Updates For UPDATE now maintenanceAgeLimit failureLimit, inspect every registered device: If its failure count is at least failureLimit and OFFLINE is allowed for its type, its target state is OFFLINE. Otherwise, if now - lastMaintenanceAt is at least maintenanceAgeLimit and MAINTENANCE is allowed for its type, its target state is MAINTENANCE. Otherwise, its state does not change. Failure-based updates therefore take precedence over maintenance-age updates. Append the number of devices whose state actually changed. Return the appended outputs in operation order. Function processDeviceOperations(typeStateRules: String[], operations: String[]) → String[] Examples Example 1 typeStateRules = ["sensor:ACTIVE|MAINTENANCE|OFFLINE","camera:ACTIVE|OFFLINE"] operations = ["REGISTER s1 sensor ACTIVE 10 10 0","REGISTER c1 camera ACTIVE 12 12 2","REGISTER s1 sensor ACTIVE 13 13 0","COUNT_ACTIVE","UPDATE 30 15 2","COUNT_ACTIVE"] return = ["OK","OK","REJECTED","camera=1,sensor=1","2",""] The first two registrations succeed, while the repeated ID s1 is rejected. Before the update, both devices are active. During the update, c1 becomes OFFLINE because its failure count reaches the threshold, and s1 becomes MAINTENANCE because its maintenance age is 20. No active devices remain. Example 2 typeStateRules = ["sensor:ACTIVE|OFFLINE"] operations = ["REGISTER d1 sensor MAINTENANCE 0 0 0","REGISTER d2 camera ACTIVE 0 0 0","REGISTER d3 sensor ACTIVE -1 0 0","COUNT_ACTIVE"] return = ["REJECTED","REJECTED","REJECTED",""] The first registration uses a state that is not allowed for sensor, the second uses an unknown type, and the third has a negative registration time. All are rejected. Example 3 typeStateRules = ["camera:ACTIVE","sensor:ACTIVE|MAINTENANCE|OFFLINE"] operations = ["REGISTER c1 camera ACTIVE 0 0 5","REGISTER s1 sensor ACTIVE 0 0 5","UPDATE 20 10 5","COUNT_ACTIVE"] return = ["OK","OK","1","camera=1"] Both devices meet the failure threshold, but camera does not allow OFFLINE, so only s1 changes state. The camera remains active. Constraints 1 <= typeStateRules.length <= 50. 1 <= operations.length <= 5000. Every type appears in exactly one rule, and every rule lists at least one unique state. Device IDs, types, and states contain only letters, digits, hyphens, and underscores, with no spaces. Every operation has exactly the fields shown in its format. Every valid numeric field is between 0 and 10^9. For every UPDATE, now is at least every registered device's lastMaintenanceAt.
Reported by candidates. Source: FastPrep
Pattern and pitfall
This is simulation. Build a map from type to a set of allowed states, and a map from device ID to a record holding type, state, registeredAt, lastMaintenanceAt and failureCount. REGISTER checks six conditions, and any failure leaves the registry untouched. COUNT_ACTIVE groups ACTIVE devices by type, sorts the type names lexicographically, skips zero counts, and returns an empty string if none. The pitfall is UPDATE. Failure check comes first, and it only applies if OFFLINE is allowed for that type. If it isn't allowed, you must fall through to the maintenance check, not stop. Example 3 shows this. Also count a device only if its state actually changed, so a device already OFFLINE targeting OFFLINE adds nothing. Compute targets per device in one pass. With 5000 operations, a linear scan per UPDATE is fine. If the live OA rattles you, StealthCoder is the hedge that catches the fall-through logic you forgot.
The honest play: practice the pattern, and have StealthCoder ready for the one you didn't see coming.
You can drill Device Registry Operations 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 for the candidate who saw this exact problem leak two days before his OA and wondered if anyone had a play.
Get StealthCoderRelated leaked OAs
You've seen the question.
Make sure you actually pass OnePay's OA.
OnePay reuses patterns across OAs. Built for the candidate who saw this exact problem leak two days before his OA and wondered if anyone had a play. Works on HackerRank, CodeSignal, CoderPad, and Karat.
Device Registry Operations FAQ
How hard is the OnePay Device Registry Operations problem really?+
Easy to medium. There's no clever algorithm, just careful parsing and rule ordering. Most failures come from missing one condition in REGISTER or botching the UPDATE precedence. If you read the spec twice and test the three examples, you should pass.
What's the trick in the UPDATE operation?+
Check failure count against failureLimit first, but only target OFFLINE if the type allows it. If not, fall through to the maintenance age check. Then count only devices whose state truly changed, not devices that already sat in the target state.
What data structures should I use?+
A hash map from type to a set of allowed states, and a hash map from device ID to a device record. For COUNT_ACTIVE, tally counts per type in a map, then sort the keys lexicographically before building the output string.
What output edge cases break solutions?+
COUNT_ACTIVE with no active devices must append an empty string, not skip the output. Also omit types with zero count. UPDATE outputs a number as a string. A rejected REGISTER must not partially modify the registry.
How do I prepare for this in 48 hours?+
Practice string-parsing simulation problems with multiple command types. Write the parser first, then one handler per command. Hand-trace the three examples from the prompt, especially Example 3, since it covers the fall-through case that trips people up.