### You only have free questions left (including this one).

But it doesn't have to end here! Sign up for the 7-day coding interview crash course and you'll get a free Interview Cake problem every week.

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 an object of a Meeting class with integer variables startTime and endTime. These integers represent the number of 30-minute blocks past 9:00am.

public class Meeting { private int startTime; private int endTime; public Meeting(int startTime, int endTime) { // number of 30 min blocks past 9:00 am this.startTime = startTime; this.endTime = endTime; } public int getStartTime() { return startTime; } public void setStartTime(int startTime) { this.startTime = startTime; } public int getEndTime() { return endTime; } public void setEndTime(int endTime) { this.endTime = endTime; } }

For example:

new Meeting(2, 3); // meeting from 10:00 – 10:30 am new Meeting(6, 9); // meeting from 12:00 – 1:30 pm

Write a method mergeRanges that takes a list of multiple meeting time ranges and returns a list of condensed ranges.

For example, given:

[Meeting(0, 1), Meeting(3, 5), Meeting(4, 8), Meeting(10, 12), Meeting(9, 10)]

[Meeting(0, 1), Meeting(3, 8), Meeting(9, 12)]

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 method 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:

[Meeting(1, 2), Meeting(2, 3)]

These meetings should probably be merged, although they don't exactly "overlap"—they just "touch." Does your method do this?

Look at this case:

[Meeting(1, 5), Meeting(2, 3)]

Notice that although the second meeting starts later, it ends before the first meeting ends. Does your method correctly handle the case where a later meeting is "subsumed by" an earlier meeting?

Look at this case:

[Meeting(1, 10), Meeting(2, 6), Meeting(3, 5), Meeting(7, 9)]

Here all of our meetings should be merged together into just Meeting(1, 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 method won't "leave out" the last meeting.

We can do this in time.

Actually, we don't support password-based login. Never have. Just the OAuth methods above. Why?

1. It's easy and quick. No "reset password" flow. No password to forget.
2. It lets us avoid storing passwords that hackers could access and use to try to log into our users' email or bank accounts.
3. It makes it harder for one person to share a paid Interview Cake account with multiple people.

Actually, we don't support password-based login. Never have. Just the OAuth methods above. Why?

1. It's easy and quick. No "reset password" flow. No password to forget.
2. It lets us avoid storing passwords that hackers could access and use to try to log into our users' email or bank accounts.
3. It makes it harder for one person to share a paid Interview Cake account with multiple people.

time and space.

Even though we only walk through our list 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 list of merged meeting times. In the worst case, none of the meetings overlap, giving us a list identical to the input list. Thus we have a worst-case space cost of .

1. What if we did have an upper bound on the input values? Could we improve our runtime? Would it cost us memory?
2. Could we do this "in place" on the input list and save some space? What are the pros and cons of doing this in place?