[gameguy43]

Hmmm. Can't get in your interviewer's head, but here's my guess: this might be one of those questions where the bulk of the discussion is supposed to be about weighing tradeoffs of different choices for the data model.

For example: how do you store the explicit blocks? More specifically, how do you articulate that head of IT is blocked from this subtree, but the CEO isn't? Some options:

- store the block as pairwise (individual, subtree)

- same idea, but instead of blocks you store explicit /allowances/ (and allow a tree node to have a flag set of "ignore the tree-based permission system here, and just lock everyone out who doesn't have an explicit permission")

- instead of blocking individuals, you could add an abstraction layer, e.g. user_groups, and assign permissions to /groups/.. You could also add an abstraction layer on top of the treenodes themselves (object_permission_groups?). Different tradeoffs with these options.

Again, hard to know exactly where your interviewer was trying to steer the conversation. But that'd be my guess!

[philipov]

The more I think about it, the less I understand why you'd ever need to explicitly block permissions. Permission groups are a good idea, but since the interviewer said it's not a data structure or algorithm question, I think it's trying to elicit problem analysis from the interviewee. What are the use-cases for blocking permissions? Why can't you just refactor the tree so that all assignments are allow? Using a mix of allow and deny is convoluted.

It seems like a trick question designed to see if the candidate is willing to question assumptions.

[resonantjacket5]

It seems pretty similar to how aws access controls work. By default everything is disallowed. Then you can gain more permissions explicitly. But an explicity deny overrides all explicit allows