Employee Resource Access Management
Reported by candidates from Rippling's online assessment. Pattern, common pitfall, and the honest play if you blank under the timer.
With 100000 operations in the queue, a Rippling OA reported in July 2026 punishes anyone who rescans every grant on each call. The task is an access-control service: GRANT, REVOKE, GET_ACCESS and GET_RESOURCES, processed in order, one output row per operation. It's a hash-table design problem in disguise, and the follow-ups about independent grants and precise revocation tell you what the interviewer cares about. The logic is easy. The bookkeeping is where people slip. If you blank on the data model mid-assessment, StealthCoder runs invisibly on your desktop and gives you a working structure in real time.
The problem
Implement an access-control service for employees and resources. One employee may hold several independent access types on the same resource. Operations Process rows in order and return one row for every operation. ["GRANT", employeeId, resourceId, accessType]: Grant READ, WRITE, or ADMIN. Return ["true"] if a new grant was added and ["false"] if it already existed. ["REVOKE", employeeId, resourceId, accessType]: Revoke one access type. Use ALL to revoke every access type the employee has on that resource. Return whether at least one grant was removed. ["GET_ACCESS", employeeId, resourceId]: Return all access types currently held on that resource, sorted as READ, WRITE, ADMIN. Return an empty row when none exist. ["GET_RESOURCES", employeeId]: Return every resource on which the employee currently has any access, sorted lexicographically. Return an empty row when none exist. Interviewer follow-ups Interviewers asked candidates to preserve multiple independent grants, make revocation precise, and discuss how the data model and APIs would evolve for larger access systems. Function manageEmployeeAccess(operations: String[][]) → String[][] Examples Example 1 operations = [["GRANT","e1","repo","READ"],["GRANT","e1","repo","WRITE"],["GRANT","e1","db","ADMIN"],["GET_ACCESS","e1","repo"],["GET_RESOURCES","e1"],["REVOKE","e1","repo","READ"],["GET_ACCESS","e1","repo"],["REVOKE","e1","repo","ALL"],["GET_RESOURCES","e1"]] return = [["true"],["true"],["true"],["READ","WRITE"],["db","repo"],["true"],["WRITE"],["true"],["db"]] Revoking READ leaves WRITE intact. Revoking ALL then removes repo from the employee's resource list. Constraints 1 <= operations.length <= 100000 accessType is READ, WRITE, ADMIN, or ALL where allowed.
Reported by candidates. Source: FastPrep
Pattern and pitfall
The trick is a nested map: employeeId to resourceId to a set of access types. GRANT adds to the set and returns true only if the type wasn't there. REVOKE removes one type, or clears the whole set for ALL, and returns true only if something was actually removed. The pitfall is cleanup. When a resource's set empties, delete the resource key, or GET_RESOURCES will list resources with no access. Also delete the employee key when it empties if you want clean state. Sort at read time. GET_ACCESS sorts by fixed rank READ, WRITE, ADMIN, not alphabetically, since alphabetical would put ADMIN first. GET_RESOURCES sorts keys lexicographically. Each grant and revoke is O(1), and reads cost only the size of that employee's data, so 100000 ops is fine. Return an empty row, not a missing row, when nothing exists. StealthCoder is your hedge if the empty-set cleanup or the ordering detail slips under the clock.
Memorize the pattern. If you can't, run StealthCoder. The proctor sees the IDE. They don't see what's behind it.
You can drill Employee Resource Access Management 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. Made by an engineer who treats the OA as theater. If yours is tonight, you don't have time to grind. You have time to hedge.
Get StealthCoderRelated leaked OAs
You've seen the question.
Make sure you actually pass Rippling's OA.
Rippling reuses patterns across OAs. Made by an engineer who treats the OA as theater. If yours is tonight, you don't have time to grind. You have time to hedge. Works on HackerRank, CodeSignal, CoderPad, and Karat.
Employee Resource Access Management FAQ
What's the core trick in the Rippling Employee Resource Access Management question?+
Use a map of employee to resource to a set of access types. Sets give you O(1) add and remove, and the boolean return falls out of whether the set changed. Everything else is sorting on read and cleaning up empty entries.
How do I handle REVOKE with ALL?+
Look up the employee's set for that resource. If it's non-empty, clear it, delete the resource key, and return true. If it's missing or empty, return false. Don't loop through the three types separately unless you track whether any removal happened.
Why does GET_ACCESS ordering trip people up?+
The required order is READ, WRITE, ADMIN, which isn't alphabetical. Plain string sort puts ADMIN first and fails the example. Map each type to a rank and sort by it, or just iterate the three types in fixed order and check membership.
Will brute force pass with 100000 operations?+
Probably not if you store a flat list of grants and scan it per operation. That drifts toward quadratic time. Hash maps keep grant and revoke constant time, and reads only touch one employee's data.
How should I prepare for this in 48 hours?+
Write the nested-map solution once from scratch and test the example, especially revoking READ then ALL. Then think through the follow-ups: multiple independent grants, precise revocation, and how you'd evolve the model, such as adding roles or groups, or an inverted index from resource to employees.