Given a list of meetings with start and end times, tell me the minimum number of rooms needed to hold all of them.

Rooms are maximum concurrency, not total overlap

The first move is to restate the question in a form that suggests an algorithm. You need one room per meeting that is running simultaneously with the others, so the number of rooms required is the greatest number of meetings that are ever in progress at the same instant. Nothing about which meeting occupies which room matters to the count.

That restatement rules out a family of wrong approaches at once. Counting overlapping pairs is not the answer, because three mutually overlapping meetings produce three pairs and need three rooms while a chain of three where each overlaps only its neighbour produces two pairs and needs two rooms. Merging the intervals is not the answer either: merging tells you which spans of the day are busy at all, and it collapses ten concurrent meetings and one lone meeting into indistinguishable blocks. Both are natural instincts for anyone who has just done a merge-intervals question, and both are visibly wrong once concurrency is the stated quantity.

Sweeping the endpoints, and why they can be sorted apart

The count of meetings in progress changes only at a start or an end. Walk time forwards, add one at each start, subtract one at each end, and record the largest value the counter reaches. That maximum is the answer.

The implementation that surprises people is that you can put all the start times in one array, all the end times in another, sort each independently, and walk the two with a pair of indices, taking whichever next event is earlier. It looks as though you have thrown away the pairing between a meeting's start and its end, and you have. It does not matter, because the counter only ever needs to know how many starts and how many ends have gone by, never which start goes with which end. Being able to say that in one sentence is the difference between having memorised the two-array trick and understanding it.

int minRooms(int[][] meetings) {
    int n = meetings.length;
    int[] starts = new int[n];
    int[] ends = new int[n];
    for (int i = 0; i < n; i++) {
        starts[i] = meetings[i][0];
        ends[i] = meetings[i][1];
    }
    Arrays.sort(starts);
    Arrays.sort(ends);          // deliberately unpaired from starts

    int rooms = 0, peak = 0, e = 0;
    for (int s = 0; s < n; s++) {
        while (ends[e] <= starts[s]) {   // half-open: an end at 10 frees the room at 10
            rooms--;
            e++;
        }
        rooms++;
        peak = Math.max(peak, rooms);
    }
    return peak;
}

The meeting that ends exactly when the next begins

The comparison inside that inner loop is the whole correctness of the solution and it is one character wide. Ask the interviewer whether a meeting from 9 to 10 conflicts with one from 10 to 11.

Under the half-open convention that calendars use, it does not: the first room is free at 10 and the second meeting takes it. The release test must therefore be that the end is less than or equal to the next start. If you write strictly less than, the room is not released, and on the input consisting of exactly those two meetings you report two rooms where one suffices.

This case almost never appears in randomly generated tests, because two randomly chosen timestamps rarely coincide, and it appears constantly in real calendar data, because meetings are scheduled on the hour and back to back. State which convention you assumed and put it in the comment, so that a reviewer reading the comparison later knows it was a decision rather than an accident. If the interviewer says the closed convention applies, meaning a meeting occupies the instant it ends, the only change is the operator.

The heap formulation, and what each version gives you

The other standard solution keeps a min-heap of the end times of the meetings currently in progress. Sort the meetings by start time, and for each one, pop every end time that is not after this start, then push this meeting's end. The heap's size after each push is the number of rooms in use, and the answer is the largest size it reaches.

Both are O of n log n time, dominated by the sort in either case, and O of n space. The reason to be able to produce both is that they answer slightly different questions. The two-array sweep gives you the count and nothing else, at the lowest constant factor, because it does no allocation beyond two integer arrays. The heap version knows, at every moment, exactly which rooms are occupied and until when, so it extends directly to the follow-up that asks which room each meeting is assigned: pop the earliest-ending room and reuse its identifier. If the interviewer's next question is likely to be about assignment rather than counting, the heap is the version to write first.

Where the counting stops being enough

Two variants change the problem rather than the implementation, and recognising which is which is worth saying.

Asking for the busiest window rather than the peak count is the same sweep with the event times retained: the answer is the span between the event that pushed the counter to its maximum and the next event that reduced it. Asking to assign meetings to rooms is the heap version with identifiers attached, and the count it produces is still optimal, which is worth noting because greedy assignment is not obviously optimal until you observe that the peak concurrency is a lower bound no assignment can beat.

Adding capacities to rooms and sizes to meetings is a different problem altogether, and no amount of sweeping solves it: fitting meetings into rooms whose capacities differ is a matching problem, and the peak-concurrency count is then only a lower bound rather than the answer. Saying that plainly, instead of trying to extend the sweep, is the right response.