Watch 10 video solutions for Count Mentions Per User, a medium level problem involving Array, Math, Sorting. This walkthrough by codestorywithMIK has 5,547 views views. Want to try solving it yourself? Practice on FleetCode or read the detailed text solution.
You are given an integer numberOfUsers representing the total number of users and an array events of size n x 3.
Each events[i] can be either of the following two types:
["MESSAGE", "timestampi", "mentions_stringi"]
timestampi.mentions_stringi string can contain one of the following tokens:
id<number>: where <number> is an integer in range [0,numberOfUsers - 1]. There can be multiple ids separated by a single whitespace and may contain duplicates. This can mention even the offline users.ALL: mentions all users.HERE: mentions all online users.["OFFLINE", "timestampi", "idi"]
idi had become offline at timestampi for 60 time units. The user will automatically be online again at time timestampi + 60.Return an array mentions where mentions[i] represents the number of mentions the user with id i has across all MESSAGE events.
All users are initially online, and if a user goes offline or comes back online, their status change is processed before handling any message event that occurs at the same timestamp.
Note that a user can be mentioned multiple times in a single message event, and each mention should be counted separately.
Example 1:
Input: numberOfUsers = 2, events = [["MESSAGE","10","id1 id0"],["OFFLINE","11","0"],["MESSAGE","71","HERE"]]
Output: [2,2]
Explanation:
Initially, all users are online.
At timestamp 10, id1 and id0 are mentioned. mentions = [1,1]
At timestamp 11, id0 goes offline.
At timestamp 71, id0 comes back online and "HERE" is mentioned. mentions = [2,2]
Example 2:
Input: numberOfUsers = 2, events = [["MESSAGE","10","id1 id0"],["OFFLINE","11","0"],["MESSAGE","12","ALL"]]
Output: [2,2]
Explanation:
Initially, all users are online.
At timestamp 10, id1 and id0 are mentioned. mentions = [1,1]
At timestamp 11, id0 goes offline.
At timestamp 12, "ALL" is mentioned. This includes offline users, so both id0 and id1 are mentioned. mentions = [2,2]
Example 3:
Input: numberOfUsers = 2, events = [["OFFLINE","10","0"],["MESSAGE","12","HERE"]]
Output: [0,1]
Explanation:
Initially, all users are online.
At timestamp 10, id0 goes offline.
At timestamp 12, "HERE" is mentioned. Because id0 is still offline, they will not be mentioned. mentions = [0,1]
Constraints:
1 <= numberOfUsers <= 1001 <= events.length <= 100events[i].length == 3events[i][0] will be one of MESSAGE or OFFLINE.1 <= int(events[i][1]) <= 105id<number> mentions in any "MESSAGE" event is between 1 and 100.0 <= <number> <= numberOfUsers - 1OFFLINE event is online at the time the event occurs.Problem Overview: You receive a sequence of events where users can mention other users. The task is to compute how many times each user gets mentioned. The main challenge is that events must be processed in the correct chronological order and different event types can change how mentions are counted.
Approach 1: Direct Simulation (Naive) (Time: O(n * m), Space: O(m))
The most straightforward strategy is to iterate through the events and simulate the system exactly as described. For each event, parse the mention information and update a counter array or hash map for the mentioned users. If an event references multiple users, iterate through each referenced ID and increment their counters. This works but becomes inefficient when mention rules require repeatedly checking many users (for example broadcasting to all users or evaluating conditions across the entire user list). Because each event can trigger operations over many users, the worst‑case runtime grows to O(n * m) where n is the number of events and m is the number of users.
Approach 2: Sorting + Simulation (Time: O(n log n), Space: O(n + m))
A better approach sorts all events by their timestamp first. This guarantees that mentions are processed in the exact order they occur. After sorting, iterate through the events once and simulate the system state. Maintain a data structure such as an array or hash map to store the mention count for each user. When processing an event, parse the mention tokens and update counts immediately. Sorting ensures that earlier actions always affect later ones correctly, which avoids complicated backtracking logic.
This approach relies on a combination of sorting and step‑by‑step simulation. Each event is processed once after sorting, so the dominant cost is the sort itself: O(n log n). Mention updates are constant time using array indexing or hash lookups, which keeps the simulation efficient even when many users exist. Storing counts and event data requires O(n + m) space.
The key insight is that chronological ordering removes ambiguity. Once events are sorted, the problem becomes a deterministic scan of the event list. This pattern appears frequently in problems combining array processing with time‑based state updates.
Recommended for interviews: The sorting + simulation approach is the expected solution. Interviewers want to see that you first enforce chronological order and then maintain a simple state while scanning the events. Explaining the naive simulation briefly shows you understand the baseline, but implementing the sorted simulation demonstrates stronger algorithmic judgment and cleaner complexity.
| Approach | Time | Space | When to Use |
|---|---|---|---|
| Direct Simulation (Naive) | O(n * m) | O(m) | Small input sizes or when mention rules require scanning all users |
| Sorting + Simulation | O(n log n) | O(n + m) | General case where events must be processed chronologically |