Skip to main content
Talentd

Alert Using Same Key-Card Three or More Times in a One Hour Period - Solution & Explanation

MediumArrayHash TableStringSorting12 min readAsked at: IBM, Snowflake, Stripe +2
Practice this problem

Problem Statement

LeetCode company workers use key-cards to unlock office doors. Each time a worker uses their key-card, the security system saves the worker's name and the time when it was used. The system emits an alert if any worker uses the key-card three or more times in a one-hour period.

You are given a list of strings keyName and keyTime where [keyName[i], keyTime[i]] corresponds to a person's name and the time when their key-card was used in a single day.

Access times are given in the 24-hour time format "HH:MM", such as "23:51" and "09:49".

Return a list of unique worker names who received an alert for frequent keycard use. Sort the names in ascending order alphabetically.

Notice that "10:00" - "11:00" is considered to be within a one-hour period, while "22:51" - "23:52" is not considered to be within a one-hour period.

 

Example 1:

Input: keyName = ["daniel","daniel","daniel","luis","luis","luis","luis"], keyTime = ["10:00","10:40","11:00","09:00","11:00","13:00","15:00"]
Output: ["daniel"]
Explanation: "daniel" used the keycard 3 times in a one-hour period ("10:00","10:40", "11:00").

Example 2:

Input: keyName = ["alice","alice","alice","bob","bob","bob","bob"], keyTime = ["12:01","12:00","18:00","21:00","21:20","21:30","23:00"]
Output: ["bob"]
Explanation: "bob" used the keycard 3 times in a one-hour period ("21:00","21:20", "21:30").

 

Constraints:

  • 1 <= keyName.length, keyTime.length <= 105
  • keyName.length == keyTime.length
  • keyTime[i] is in the format "HH:MM".
  • [keyName[i], keyTime[i]] is unique.
  • 1 <= keyName[i].length <= 10
  • keyName[i] contains only lowercase English letters.

Approach Overview

Problem Overview: Given employee names and key-card usage times, detect employees who used their card three or more times within any one-hour window. Return the employee names that trigger the alert, sorted lexicographically.

Approach 1: Sliding Window with Minute Conversion (O(n log n) time, O(n) space)

Group all access times by employee using a hash table. Convert each HH:MM timestamp into total minutes (hour * 60 + minute) so time comparisons become simple integer differences. For every employee, sort their access times using sorting. Then scan the sorted list with a small sliding window: if times[i] - times[i-2] <= 60, three accesses occurred within one hour and the employee triggers an alert. This works because the sorted order ensures the smallest possible window for any three consecutive entries. The approach is efficient and easy to reason about during interviews.

Approach 2: Heap-Based Tracking (O(n log n) time, O(n) space)

Maintain a min-heap of timestamps per employee. As each access event is processed, convert the time to minutes and push it into that employee's heap. Continuously remove entries older than 60 minutes compared with the current time. If the heap size reaches three, the employee has used their card three times within the one-hour window and should be flagged. The heap structure keeps timestamps ordered automatically while discarding outdated entries efficiently. This approach is useful in streaming scenarios where events arrive chronologically rather than being processed in batches.

Recommended for interviews: The sliding window with minute conversion is the expected solution. It demonstrates good use of grouping, sorting, and window scanning. A brute-force comparison of every triplet would be inefficient, but the sorted sliding window reduces the check to constant work per element. Interviewers usually look for the insight that only three consecutive timestamps need to be compared after sorting.

Approach 1: Sliding Window Approach with Minute Conversion

This approach involves converting all the given times into minutes from the start of the day (00:00). This simplifies the comparison between times since it reduces the problem to integer comparisons. Once the times are converted, we can use a sliding window to check if there are three occurrences within any 60-minute window.

This solution uses a dictionary to group all the times by name and convert them to minutes. After that, for each person, it checks if any three consecutive accesses occur within a one-hour (60 minutes) window. We collect all such names and return a sorted list.

Code

PythonC++Java

Python

C++

Java

Complexity

Time Complexity: O(N log N) where N is the number of entries since we need to sort the times for each person.
Space Complexity: O(N) due to the storage of times in a dictionary.

Try this approach in the editor →

Approach 2: Heap-Based Approach

In this approach, we use a heap to keep track of times. As we iterate through each person's access times sorted by minutes, we push each time onto a min-heap and pop times off if they are outside of a rolling window of 60 minutes.

Here, the JavaScript solution inserts each access time in minutes into a priority queue (heap). For each unique name, it maintains at most the last three access times in sorted order and checks if these fall within a 60-minute window. If they do, we add the name to the results.

Code

JavaScriptC#

JavaScript

C#

Complexity

Time Complexity: O(N log A) where N is the number of logs and A is the average number of accesses per user since sorting and maintaining a heap can be costly.
Space Complexity: O(N) as each log entry needs to be stored.

Try this approach in the editor →

Approach 3: Hash Table + Sorting

First, we use a hash table d to record all the clock-in times of each employee.

Then we traverse the hash table. For each employee, we first check whether the number of clock-in times is greater than or equal to 3. If not, we skip this employee. Otherwise, we sort all the clock-in times of this employee in chronological order, and then traverse the sorted clock-in times to check whether the two times at a distance of 2 indices are within the same hour. If so, we add this employee to the answer array.

Finally, we sort the answer array in lexicographical order to get the answer.

The time complexity is O(n times log n), and the space complexity is O(n). Where n is the number of clock-in records.

Code

PythonJavaC++GoTypeScript

Python

Java

C++

Go

TypeScript

Try this approach in the editor →

Complexity Comparison

ApproachComplexity
Sliding Window Approach with Minute Conversion

Time Complexity: O(N log N) where N is the number of entries since we need to sort the times for each person.
Space Complexity: O(N) due to the storage of times in a dictionary.

Heap-Based Approach

Time Complexity: O(N log A) where N is the number of logs and A is the average number of accesses per user since sorting and maintaining a heap can be costly.
Space Complexity: O(N) as each log entry needs to be stored.

Hash Table + Sorting—

Detailed Complexity Analysis

ApproachTimeSpaceWhen to Use
Sliding Window with Minute ConversionO(n log n)O(n)Best general solution. Group times by employee, sort, and check 3-entry windows.
Heap-Based ApproachO(n log n)O(n)Useful when processing access events as a stream and maintaining a rolling 1-hour window.

Video Solution

LeetCode 1604. Alert Using Same Key-Card Three or More Times in a One Hour Period • Happy Coding • 1,513 views views

Watch 8 more video solutions →

Frequently Asked Questions

Is Alert Using Same Key-Card Three or More Times in a One Hour Period easy or hard?
The problem is rated Medium because it combines multiple concepts: time parsing, grouping with a hash map, sorting timestamps, and detecting a sliding window condition. The logic itself is straightforward once timestamps are converted to minutes.
Alert Using Same Key-Card Three or More Times in a One Hour Period Python/Java solution
A typical Python or Java implementation builds a map from employee name to a list of times converted to minutes. After sorting each list, iterate through it and check if the difference between the current time and the one two positions earlier is at most 60 minutes. If true, add the employee to the result set.
How to solve Alert Using Same Key-Card Three or More Times in a One Hour Period in O(n)?
Strict O(n) is difficult because timestamps per employee must be ordered for accurate comparison. After converting times to minutes, sorting the timestamps allows a simple sliding window check across consecutive entries. The resulting complexity is O(n log n), which is considered optimal for this problem.
What is the best approach for Alert Using Same Key-Card Three or More Times in a One Hour Period?
The most efficient solution groups access times by employee, converts each time to minutes, sorts them, and scans using a sliding window. Checking if times[i] - times[i-2] <= 60 detects three accesses within one hour. This approach runs in O(n log n) time due to sorting and uses O(n) space.
Is Alert Using Same Key-Card Three or More Times in a One Hour Period asked at Google/Amazon/Meta?
Problems involving time-window detection, event grouping, and log analysis frequently appear in interviews at companies like Amazon, Google, and Meta. Variants of this question test understanding of sorting, sliding window techniques, and hash-based grouping.
What data structure is used in Alert Using Same Key-Card Three or More Times in a One Hour Period?
The main data structure is a hash map that groups timestamps by employee name. Each employee's timestamps are stored in a list that gets sorted. Some implementations also use heaps to maintain a rolling one-hour window when processing events incrementally.
What is the time complexity of Alert Using Same Key-Card Three or More Times in a One Hour Period?
The optimal solution runs in O(n log n) time. The log factor comes from sorting each employee's access times, while the sliding window scan is linear. Space complexity is O(n) to store grouped timestamps.

Ready to solve this problem?

Practice Alert Using Same Key-Card Three or More Times in a One Hour Period with our built-in code editor and test cases.

Practice on FleetCode
Previous

Two Sum

Next

Median of Two Sorted Arrays