Find the Unique User with Access to Every Camera
Reported by candidates from Verkada's online assessment. Pattern, common pitfall, and the honest play if you blank under the timer.
The Verkada OA reported in September 2026 hands you a pile of [source, relationship, destination] triples and asks for the one user who can reach every camera. The detail that bites is the cycle: group_x and group_y can be members of each other, so a naive walk loops forever. It's a graph traversal problem with a set-comparison at the end. If you blank on the visited-set handling mid-assessment, StealthCoder is the invisible safety net that reads the screen and gives you a working solution while you keep your cool.
The problem
An access-control graph is provided as relationship triples. Each triple is [source, relationship, destination]. camera_owner means that a user or group directly owns a camera. group_member means that a user or group belongs to another group. A user can access every camera owned directly by that user or by any group reachable through one or more membership relationships. Groups may contain other groups, and group membership may contain cycles. Return the unique user_* identifier that can access every camera appearing in a camera_owner relationship. Return the empty string when there are no cameras or when zero or multiple users can access every camera. Function findAdminUser(permissions: String[][]) → String Examples Example 1 permissions = [["user_alice","group_member","group_ops"],["group_ops","camera_owner","camera_lobby"],["user_alice","camera_owner","camera_roof"],["user_bob","group_member","group_ops"]] return = "user_alice" Both users inherit access to camera_lobby from group_ops, but only user_alice directly owns camera_roof. Example 2 permissions = [["user_a","group_member","group_x"],["group_x","group_member","group_y"],["group_y","group_member","group_x"],["group_y","camera_owner","camera_1"],["user_b","camera_owner","camera_1"]] return = "" The group cycle is traversed safely. Both user_a and user_b can access the only camera, so there is no unique result. Constraints 0 <= permissions.length <= 2000. Every triple contains exactly three non-empty strings. The relationship is either camera_owner or group_member. Users, groups, and cameras begin with user_, group_, and camera_, respectively. A group_member destination is a group; its source is a user or group. A camera_owner destination is a camera; its source is a user or group. Each identifier has length at most 80.
Reported by candidates. Source: FastPrep
Pattern and pitfall
Build two maps: membership edges (source to groups it joins) and direct camera ownership (owner to cameras). Collect all cameras from camera_owner triples. For each user_* node, run a DFS or BFS over membership edges with a visited set, which makes cycles harmless. Union the cameras owned by every node you reach, including the user itself. If that set's size equals the total camera count, the user qualifies. Count qualifying users and return the identifier only if exactly one does. The pitfalls: forgetting to include the user's own direct cameras, skipping the visited set and hanging on cycles, and returning a user when there are zero cameras. Users only appear as sources, so gather them from every triple's source field starting with user_. With 2000 triples, a traversal per user is fast enough. If the traversal logic slips under pressure, StealthCoder is the hedge during the live OA.
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 Find the Unique User with Access to Every Camera 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 Verkada's OA.
Verkada 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.
Find the Unique User with Access to Every Camera FAQ
What's the trick in the Verkada unique admin problem?+
Treat it as reachability on a directed graph. From each user, follow group_member edges with a visited set, gather every camera owned along the way, and compare against the full camera set. The visited set is what makes the cyclic group example work.
How do I handle cycles between groups?+
Keep a visited set per traversal. Before pushing a node onto the stack or queue, check whether you've seen it. Group_x and group_y pointing at each other then get processed once each and the loop ends.
What edge cases should I test before submitting?+
Test empty input, which should return an empty string. Test cameras that exist but no user reaches all of them. Test two users who both reach everything. Also test a user who owns a camera directly with no groups at all.
Is the time complexity a concern with 2000 triples?+
Not really. Running a traversal from each user costs roughly users times edges, which is at most a few million operations at this size. You can skip clever optimizations like reverse propagation and just write the clear version.
How do I prepare for this in 48 hours?+
Rehearse graph traversal with a visited set, building adjacency maps from raw triples, and set equality checks. Write this exact problem once from scratch, including the cycle example. Parsing the prefixes user_, group_, camera_ is the only fiddly part.