Your company built an in-house calendar tool called HiCal. You want to add a feature to see the times in a day when everyone is available.
To do this, you’ll need to know when any team is having a meeting. In HiCal, a meeting is stored as objects with integer properties startTime and endTime. These integers represent the number of 30-minute blocks past 9:00am.
For example:
Write a function mergeRanges that takes an array of multiple meeting time ranges and returns an array of condensed ranges.
For example, given:
your function would return:
Do not assume the meetings are in order. The meeting times are coming from multiple teams.
Write a solution that's efficient even when we can't put a nice upper bound on the numbers representing our time ranges. Here we've simplified our times down to the number of 30-minute slots past 9:00 am. But we want the function to work even for very large numbers, like Unix timestamps. In any case, the spirit of the challenge is to merge meetings where startTime and endTime don't have an upper bound.
Look at this case:
These meetings should probably be merged, although they don't exactly "overlap"—they just "touch." Does your function do this?
Look at this case:
Notice that although the second meeting starts later, it ends before the first meeting ends. Does your function correctly handle the case where a later meeting is "subsumed by" an earlier meeting?
Look at this case:
Here all of our meetings should be merged together into just { startTime: 1, endTime: 10 }. We need keep in mind that after we've merged the first two we're not done with the result—the result of that merge may itself need to be merged into other meetings as well.
Make sure that your function won't "leave out" the last meeting.
We can do this in time.
What if we only had two ranges? Let's take:
These meetings clearly overlap, so we should merge them to give:
But how did we know that these meetings overlap?
We could tell the meetings overlapped because the end time of the first one was after the start time of the second one! But our ideas of "first" and "second" are important here—this only works after we ensure that we treat the meeting that starts earlier as the "first" one.
How would we formalize this as an algorithm? Be sure to consider these edge cases:
Here's a formal algorithm:
So, we could compare every meeting to every other meeting in this way, merging them or leaving them separate.
Comparing all pairs of meetings would take time. We can do better!
If we're going to beat time, maybe we're going to get time? Is there a way to do this in one pass?
It'd be great if, for each meeting, we could just try to merge it with the next meeting. But that's definitely not sufficient, because the ordering of our meetings is random. There might be a non-next meeting that the current meeting could be merged with.
What if we sorted our array of meetings by start time?
Then any meetings that could be merged would always be adjacent!
So we could sort our meetings, then walk through the sorted array and see if each meeting can be merged with the one after it.
Sorting takes time in the worst case. If we can then do the merging in one pass, that's another time, for overall. That's not as good as , but it's better than .
First, we sort our input array of meetings by start time so any meetings that might need to be merged are now next to each other.
Then we walk through our sorted meetings from left to right. At each step, either:
time and space.
Even though we only walk through our array of meetings once to merge them, we sort all the meetings first, giving us a runtime of . It's worth noting that if our input were sorted, we could skip the sort and do this in time!
We create a new array of merged meeting times. In the worst case, none of the meetings overlap, giving us an array identical to the input array. Thus we have a worst-case space cost of .
This one arguably uses a greedy approach as well, except this time we had to sort the array first.
How did we figure that out?
We started off trying to solve the problem in one pass, and we noticed that it wouldn't work. We then noticed the reason it wouldn't work: to see if a given meeting can be merged, we have to look at all the other meetings! That's because the order of the meetings is random.
That's what got us thinking: what if the array were sorted? We saw that then a greedy approach would work. We had to spend time on sorting the array, but it was better than our initial brute force approach, which cost us time!
Reset editor
Powered by qualified.io