Moderator List Hierarchy

medium

CodingReported Jun 2026 · Low frequency

Moderator List Ordering

CodingMachine Learning Engineer, Software EngineerReported May, 2026

Problem Overview

Create a Reddit-like moderator hierarchy by processing a newline-separated audit log.

This interview prompt is commonly divided into three stages:

One moderator roster
Several communities
Demotion events that change the current roster order

The governing permission rule is:

One moderator may remove another only when they currently rank above that moderator in the list.
A moderator ranks higher when their effective access time is earlier.

For the first stage, every record contains four comma-delimited values:

target, action, actor, timestamp

target: the moderator affected by the event
action: add or remove for Parts 1 and 2; Part 3 also allows demote
actor: the moderator responsible for the event
timestamp: an integer time value that advances through the log

You may rely on the following:

Log entries arrive in timestamp order.
Part 1 never has duplicate timestamps.
In Parts 2 and 3, timestamps do not repeat within the same community.
All recorded operations are valid.
SYSTEM can act as the user that establishes the initial moderator, although it does not appear in the returned list unless it is itself added.
A moderator who is removed and later added again receives a fresh access timestamp.

Every stage requires the same three capabilities:

A constructor that initializes state from the log text
can_remove_mod(...)
get_mod_list(...)

Problem Statement

Build a class that manages one moderator roster:

class ModList:
    def __init__(self, logs: str):
        pass

    def can_remove_mod(self, actor: str, target: str) -> bool:
        pass

    def get_mod_list(self) -> list[str]:
        pass

Rules

An add event makes target an active moderator beginning at timestamp.
A remove event makes target inactive.
can_remove_mod(actor, target) produces True exactly when:
- both names currently belong to active moderators
- actor != target
- actor has an effective access timestamp earlier than target
get_mod_list() must return active moderators in descending rank order, from first to last.

Example

logs = """
nora,add,SYSTEM,11
owen,add,nora,12
priya,add,nora,13
quinn,add,owen,14
priya,remove,nora,15
""".strip()

mod_list = ModList(logs)

mod_list.can_remove_mod("nora", "owen") # True
mod_list.can_remove_mod("owen", "nora") # False
mod_list.can_remove_mod("owen", "quinn") # True
mod_list.get_mod_list() # ["nora", "owen", "quinn"]

nora joined before owen, and owen joined before quinn; priya was removed, so she is absent from the final ordering.

Problem Statement

Expand the design so it handles separate moderator rosters for multiple communities. Records now use this layout:

community, target, action, actor, timestamp

Implement:

class CommunityModList:
    def __init__(self, logs: str):
        pass

    def can_remove_mod(self, community: str, actor: str, target: str) -> bool:
        pass

    def get_mod_list(self, community: str) -> list[str]:
        pass

Rules

Each community maintains its own moderator membership independently.
One username may be a moderator in more than one community and have different access times in each.
can_remove_mod evaluates permissions only within the supplied community.

Example

logs = """
gardening,nora,add,SYSTEM,21
gardening,owen,add,nora,22
gardening,priya,add,nora,23
photography,riley,add,SYSTEM,24
photography,owen,add,riley,25
gardening,priya,remove,nora,26
""".strip()

mod_list = CommunityModList(logs)

mod_list.get_mod_list("gardening") # ["nora", "owen"]
mod_list.get_mod_list("photography") # ["riley", "owen"]
mod_list.can_remove_mod("gardening", "nora", "owen") # True
mod_list.can_remove_mod("photography", "owen", "riley") # False

In gardening, nora predates owen while priya was removed. In photography, riley has the earlier access time, so owen cannot remove her.

Problem Statement

Enhance the multi-community design with a third possible event:

community, target, demote, actor, timestamp

A demotion leaves the target active but replaces their effective access timestamp with the demotion time. Put differently, the target moves lower in that community's moderator order.

Implement the same three methods:

class ReorderableCommunityModList:
    def __init__(self, logs: str):
        pass

    def can_remove_mod(self, community: str, actor: str, target: str) -> bool:
        pass

    def get_mod_list(self, community: str) -> list[str]:
        pass

Example

logs = """
gardening,nora,add,SYSTEM,31
gardening,owen,add,nora,32
gardening,priya,add,nora,33
gardening,owen,demote,nora,34
""".strip()

mod_list = ReorderableCommunityModList(logs)

mod_list.get_mod_list("gardening") # ["nora", "priya", "owen"]
mod_list.can_remove_mod("gardening", "priya", "owen") # True
mod_list.can_remove_mod("gardening", "owen", "priya") # False

After owen is demoted, his effective timestamp becomes 34, placing him after priya, whose timestamp remains 33.

Follow-Up Discussion

How could get_mod_list() run in O(m) without performing a new sort on every call?
How could the implementation reject invalid records rather than assuming every logged event is valid?
How should the design change if timestamps can be duplicated?
How could callers retrieve the moderator hierarchy as it existed at an earlier timestamp?

BackBack to problems

Moderator List Hierarchy

medium

CodingReported Jun 2026 · Low frequency

Moderator List Ordering

CodingMachine Learning Engineer, Software EngineerReported May, 2026

Problem Overview

Create a Reddit-like moderator hierarchy by processing a newline-separated audit log.

This interview prompt is commonly divided into three stages:

One moderator roster
Several communities
Demotion events that change the current roster order

The governing permission rule is:

One moderator may remove another only when they currently rank above that moderator in the list.
A moderator ranks higher when their effective access time is earlier.

For the first stage, every record contains four comma-delimited values:

target, action, actor, timestamp

target: the moderator affected by the event
action: add or remove for Parts 1 and 2; Part 3 also allows demote
actor: the moderator responsible for the event
timestamp: an integer time value that advances through the log

You may rely on the following:

Log entries arrive in timestamp order.
Part 1 never has duplicate timestamps.
In Parts 2 and 3, timestamps do not repeat within the same community.
All recorded operations are valid.
SYSTEM can act as the user that establishes the initial moderator, although it does not appear in the returned list unless it is itself added.
A moderator who is removed and later added again receives a fresh access timestamp.

Every stage requires the same three capabilities:

A constructor that initializes state from the log text
can_remove_mod(...)
get_mod_list(...)

Problem Statement

Build a class that manages one moderator roster:

class ModList:
    def __init__(self, logs: str):
        pass

    def can_remove_mod(self, actor: str, target: str) -> bool:
        pass

    def get_mod_list(self) -> list[str]:
        pass

Rules

An add event makes target an active moderator beginning at timestamp.
A remove event makes target inactive.
can_remove_mod(actor, target) produces True exactly when:
- both names currently belong to active moderators
- actor != target
- actor has an effective access timestamp earlier than target
get_mod_list() must return active moderators in descending rank order, from first to last.

Example

logs = """
nora,add,SYSTEM,11
owen,add,nora,12
priya,add,nora,13
quinn,add,owen,14
priya,remove,nora,15
""".strip()

mod_list = ModList(logs)

mod_list.can_remove_mod("nora", "owen") # True
mod_list.can_remove_mod("owen", "nora") # False
mod_list.can_remove_mod("owen", "quinn") # True
mod_list.get_mod_list() # ["nora", "owen", "quinn"]

nora joined before owen, and owen joined before quinn; priya was removed, so she is absent from the final ordering.

Problem Statement

Expand the design so it handles separate moderator rosters for multiple communities. Records now use this layout:

community, target, action, actor, timestamp

Implement:

class CommunityModList:
    def __init__(self, logs: str):
        pass

    def can_remove_mod(self, community: str, actor: str, target: str) -> bool:
        pass

    def get_mod_list(self, community: str) -> list[str]:
        pass

Rules

Each community maintains its own moderator membership independently.
One username may be a moderator in more than one community and have different access times in each.
can_remove_mod evaluates permissions only within the supplied community.

Example

logs = """
gardening,nora,add,SYSTEM,21
gardening,owen,add,nora,22
gardening,priya,add,nora,23
photography,riley,add,SYSTEM,24
photography,owen,add,riley,25
gardening,priya,remove,nora,26
""".strip()

mod_list = CommunityModList(logs)

mod_list.get_mod_list("gardening") # ["nora", "owen"]
mod_list.get_mod_list("photography") # ["riley", "owen"]
mod_list.can_remove_mod("gardening", "nora", "owen") # True
mod_list.can_remove_mod("photography", "owen", "riley") # False

In gardening, nora predates owen while priya was removed. In photography, riley has the earlier access time, so owen cannot remove her.

Problem Statement

Enhance the multi-community design with a third possible event:

community, target, demote, actor, timestamp

A demotion leaves the target active but replaces their effective access timestamp with the demotion time. Put differently, the target moves lower in that community's moderator order.

Implement the same three methods:

class ReorderableCommunityModList:
    def __init__(self, logs: str):
        pass

    def can_remove_mod(self, community: str, actor: str, target: str) -> bool:
        pass

    def get_mod_list(self, community: str) -> list[str]:
        pass

Example

logs = """
gardening,nora,add,SYSTEM,31
gardening,owen,add,nora,32
gardening,priya,add,nora,33
gardening,owen,demote,nora,34
""".strip()

mod_list = ReorderableCommunityModList(logs)

mod_list.get_mod_list("gardening") # ["nora", "priya", "owen"]
mod_list.can_remove_mod("gardening", "priya", "owen") # True
mod_list.can_remove_mod("gardening", "owen", "priya") # False

After owen is demoted, his effective timestamp becomes 34, placing him after priya, whose timestamp remains 33.

Follow-Up Discussion

How could get_mod_list() run in O(m) without performing a new sort on every call?
How could the implementation reject invalid records rather than assuming every logged event is valid?
How should the design change if timestamps can be duplicated?
How could callers retrieve the moderator hierarchy as it existed at an earlier timestamp?

Moderator List Hierarchy

Moderator List Ordering

Problem Overview

Part 1: Single Moderator List

Problem Statement

Rules

Example

Part 2: Add Community Support

Problem Statement

Rules

Example

Part 3: Support Moderator Demotion

Problem Statement

Example

Follow-Up Discussion

Moderator List Hierarchy

Moderator List Ordering

Problem Overview

Part 1: Single Moderator List

Problem Statement

Rules

Example

Part 2: Add Community Support

Problem Statement

Rules

Example

Part 3: Support Moderator Demotion

Problem Statement

Example

Follow-Up Discussion