Meeting Schedule Ii - JS Solution

Editorial

Editorial solutions and visualizations are prepared with care, but we do not guarantee 100% accuracy or completeness. Please use your own judgment to verify results. Visucodize is not responsible for decisions made based on this content.

const CURRENT = 'current', CURRENT_COLOR = 'blue';

function visMainFunction(inputIntervals) {
    initClassProperties();
    inputInconsistencyWarning();
    explanationAndColorSchemaNotifications();

    if (!inputIntervals.length) {
        notification(`✅ No meetings provided. Zero days needed.`);
        return 0;
    }

    startPartialBatch();
    notification(`
        📌 <b>Step 1: Sort all meetings by start time.</b><br>
        We sort so that meetings are handled in the order they begin. After sorting,
        we can schedule meetings one by one from earliest to latest, and at each step
        the ${makeColoredSpan('current meeting', CURRENT_COLOR)} is simply the meeting we are currently working to place on a day.
    `);
    startBatch();
    const intervals = new VisArray(...inputIntervals).options({ labelExtractionPolicy: (i) => `[${i[0]}, ${i[1]}]` });
    intervals.sort((a, b) => a[0] - b[0]);
    endBatch();
    endBatch();

    startPartialBatch();
    const heap = new VisMinPriorityQueue().options({ label: "Meeting End Times" });
    heap.enqueue(intervals[0][1]);

    let index = 1;
    makeVisVariable(index).registerAsIndexPointer(intervals, CURRENT);

    notification(`
        ✅ <b>Sorting complete.</b><br><br>
        📌 <b>Step 2: Initialize the MinHeap and start iterating from the second meeting.</b><br>
        We first add the end time of the initial meeting <code>[${intervals[0][0]}, ${intervals[0][1]}]</code> 
        to the heap — meaning one day is now occupied until that time.<br><br>
        The heap stores the <b>end times</b> of the latest meetings scheduled on each allocated day.
        Its front (smallest) value always represents <b>the earliest available day</b> among all allocated ones.<br><br>
        Starting from <b>index 1</b> (the ${makeColoredSpan('current meeting', CURRENT_COLOR)}),
        we’ll go through each meeting in sorted order and decide:
        <ul>
            <li>♻️ If the earliest day (heap’s minimum) is free before the new meeting starts → reuse it.</li>
            <li>🆕 Otherwise → we need to use an additional day at the same time and keep both in the heap.</li>
        </ul>
    `);
    endBatch();

    while (index < intervals.length) {
        startPartialBatch();
        const [start, end] = intervals[index];

        notification(`
            📌 <b>Processing ${makeColoredSpan('current meeting', CURRENT_COLOR)}:</b> [${start}, ${end}]<br>
            We'll check if an existing day is available, or if we must allocate a new day.
        `);

        // NOTE: In MinPriorityQueue version used by neetcode heap.front() should be used instead of heap.front().element
        if (heap.front().element <= start) {
            notification(`
                ♻️ A day is available and reused.<br>
                We check the <b>earliest-ending meeting</b> by looking at the <b>front of the heap</b> — it ends at ${heap.front().element}, which is ≤ ${start}.<br><br>
                This means one meeting finishes before the ${makeColoredSpan('current meeting', CURRENT_COLOR)} starts,
                so we remove that end time from the heap (by <b>dequeuing</b>) to <b>free up that day</b>.<br>
                We then <b>reuse the same day</b> for the current meeting, which will now be occupied until ${end} (by <b>enqueueing</b> this new end time).
            `);
            heap.dequeue();
        } else {
            notification(`
                🆕 No day is available.<br>
                We check the <b>earliest-ending meeting</b> by looking at the <b>front of the heap</b> — it ends at ${heap.front().element}, which is still after ${start}.<br><br>
                This means all existing days are still busy when the ${makeColoredSpan('current meeting', CURRENT_COLOR)} starts,
                so we <b>allocate a new day</b> and record it in the heap (by <b>enqueueing</b> its end time ${end}), meaning this new day will be occupied until that time.
            `);
        }

        heap.enqueue(end);
        index += 1;
        endBatch();
    }

    notification(`
        🏁 <b>Done!</b><br>
        The size of the <code>heap</code> at the end — <b>${heap.size()}</b> — represents the total number of 
        <b>distinct days ever allocated</b>.<br><br>
        That number is exactly the <b>minimum number of days required</b> 
        to schedule all meetings without any overlaps on the same day.
    `);
    return heap.size();
}

function initClassProperties() {
    setClassProperties(CURRENT, {
        backgroundColor: CURRENT_COLOR
    });
}

function explanationAndColorSchemaNotifications() {
    explanationNotification();
    notification(`
        🎨 <b>Color Schema</b><br><br>
        🟦 <b>${makeColoredSpan('Current meeting', CURRENT_COLOR)}</b> — the interval (meeting) currently being processed.
    `);
}

function inputInconsistencyWarning() {
    notification(`
        <p style="color: #d9534f;">
            ⚠️ <b>Note:</b> In the NeetCode problem UI, intervals are entered as <code>[(0, 40), (5, 10), (15, 20)]</code> 
            and the parameter passed to their function is an array of objects like <code>[{start: 0, end: 40}, …]</code>.<br>
            In this solution, we instead use a simpler array format <code>[[0, 40], [5, 10], [15, 20]]</code> 
            consistently in both the input UI and code for clarity and simplicity.
        </p>
    `);
}

Approach

⚠️ Note: In the NeetCode problem UI, intervals are entered as [(0, 40), (5, 10), (15, 20)] and the parameter passed to their function is an array of objects like [{start: 0, end: 40}, …].
In this solution, we instead use a simpler array format [[0, 40], [5, 10], [15, 20]] consistently in both the input UI and code for clarity and simplicity.

We want to find the minimum number of days needed to schedule all the given meetings, where a single day can host multiple meetings as long as their times do not overlap.

The core idea is: as we go through meetings in chronological order, we try to reuse an existing day whenever possible. If no existing day is free for the next meeting, we must allocate a new day in parallel.

Handling Empty Input

Before performing any operations, the algorithm first checks if the input list of intervals is empty.

If there are no intervals provided, there is nothing to schedule — meaning no days are needed. In this case, the algorithm immediately returns 0 and exits early.

This small edge case check keeps the logic clean and efficient.

Step 1: Sort meetings by start time

We first sort all meetings by their start time. After sorting, we handle meetings in the order they begin — from earliest start time to latest.

This ordering lets us “schedule” meetings one by one. At any point, the “current meeting” is simply the next meeting we’re trying to place on some day.

Because we’re going in start-time order, we can always ask: Can this meeting fit onto any existing day from earlier, or do we need a new day?

Step 2: Track active days using a MinHeap of end times

We maintain a MinHeap of meeting end times. Each entry in the heap corresponds to a day that has been allocated so far, and the value we store for that day is the time when the last meeting scheduled on that day ends. Therefore, the front of the heap always tells us the earliest available day among all allocated ones.

Concretely:

If a day currently has a meeting that ends at time T, then T goes into the heap.
The smallest end time at the top of the heap is the day that will be free the soonest.

Before we start iterating, we take the first meeting (the earliest start after sorting) and add its end time to the heap. This means: we’re currently using 1 day, and that day is “busy until” that first meeting’s end time.

Step 3: For each next meeting, either reuse a day or allocate a new one

Now we walk through the remaining meetings in sorted order. For each current meeting [start, end], we do the following:

Check the earliest available day:
We check the front of the heap to find the smallest end time — the meeting that finishes first on some day.
This tells us: “What is the soonest any existing day becomes free?”
If that earliest end time ≤ current meeting’s start:
That means some day finishes its last meeting before (or exactly when) this meeting begins. So we can reuse that same day for the current meeting.

Operationally:
- We remove that earliest end time from the heap — this represents freeing that day.
- We then schedule the current meeting on that same day, and push this meeting’s end time into the heap as the new “busy until…” time for that day.
Intuition: We didn’t need an extra day because one just became available in time.
Otherwise (earliest end time > current start):
That means even the day that frees up the earliest is still busy when this meeting wants to start. In other words: no existing day is available yet.

So we must allocate a new day in parallel for this meeting. We do this by just adding this meeting’s end time as an additional entry in the heap.

Why the heap size answers the question

The heap contains one entry for each day that has been allocated so far — regardless of whether that day is currently occupied or has become available again for reuse.

As a result, the heap size always represents the total number of distinct days ever allocated. That number is exactly the minimum number of days required to schedule all meetings without any overlaps on the same day.

Time Complexity

The overall time complexity is O(N log N), where N is the number of meetings:

Sorting all meetings by their start times takes O(N log N).
For each meeting, we may perform one enqueue and possibly one dequeue operation on the MinHeap, each costing O(log N).
Across all meetings, the total heap operations also sum up to O(N log N).

Therefore, the total time complexity remains O(N log N).

Space Complexity

The heap stores at most one end time for each allocated day. In the worst case — when all meetings overlap and none can share a day — the heap can grow to size N, giving a space complexity of O(N), where N is the total number of meetings.

Additionally, sorting the meetings may require up to O(N) extra space depending on the underlying sorting implementation. Since both are at most O(N), the overall space complexity remains O(N).

Input-1

Meeting Schedule Ii - JS Solution

Solution code

Solution explanation

Solution explanation

Approach

Handling Empty Input

Step 1: Sort meetings by start time

Step 2: Track active days using a MinHeap of end times

Step 3: For each next meeting, either reuse a day or allocate a new one

Why the heap size answers the question

Time Complexity

Space Complexity