• 1 <= k <= nums.length <= 10⁵
• nums contains integers (positive and negative both allowed)
• Return the maximum window sum, not the subarray itself

Read the problem slowly. You have a frame that is exactly k numbers wide. You slide it across the array, one position at a time, and among all the spots the frame can sit, you want the one where the numbers under it add up to the most. The frame never grows or shrinks — it is always k wide. That fixed width turns out to be the whole story.

The first idea anyone has: go to every possible starting spot, add up the k numbers sitting there, and keep the biggest total you have seen.

def brute_force(nums, k):
    best = float('-inf')
    for i in range(len(nums) - k + 1):
        window_sum = sum(nums[i:i+k])   # re-adds k numbers, every single time
        best = max(best, window_sum)
    return best

There are about N starting spots, and at each one we add up k numbers, so the work is roughly N × k additions. If N and k are both large — say 100,000 each — that is billions of steps. Something is being wasted. Look closely at what sum(nums[i:i+k]) does on two turns in a row.

Put two neighbouring frames side by side on [2, 1, 5, 1, 3, 2] with k = 3:

They share the 1 and the 5. And that is not a coincidence — any two side-by-side frames overlap in all but two numbers. When the frame steps right by one, the leftmost number drops out, exactly one new number joins on the right, and everything in between is untouched. The brute force ignores that and re-adds the shared middle from scratch every time.

Once you know the sum of one frame, you can get the next frame's sum with two tiny fixes: subtract the number that just left on the left, add the number that just arrived on the right. However big k is, moving the frame one step now costs one subtraction and one addition — a fixed, tiny amount of work.

def max_sum_subarray(nums, k):
    window_sum = sum(nums[:k])   # build the FIRST frame once, in full
    best = window_sum
    for i in range(k, len(nums)):
        window_sum += nums[i] - nums[i - k]   # + incoming, - outgoing
        best = max(best, window_sum)
    return best

Now a case that catches lazy code — all negatives, nums = [-1, -2, -3, -4], k = 2. First frame [-1, -2] = −3, so best = −3. Slide: add −3, drop −1, giving −3 + (−3 − (−1)) = −5, frame [-2, -3], best stays −3. Slide again: add −4, drop −2, giving −5 + (−4 − (−2)) = −7, best still −3. Answer −3. This is exactly why best is seeded with the first frame's real sum (or −∞) and never with 0 — a 0 start would beat every negative frame and hand back a sum that no real window has.

That trick — carry one small summary of a fixed-width frame and patch it one-in, one-out as it glides — is the Fixed Sliding Window. It is the base shape for a whole family of problems, so it is worth pinning down exactly why it works.

Two conditions make it legal:
1. the frame's width is fixed and known up front (here it is k);
2. the thing you track about the frame can be repaired in O(1) when one element enters and one leaves. A running sum qualifies: add the newcomer, subtract the leaver, done.

The invariant you protect: at every step, window_sum equals the sum of exactly the k elements currently under the frame — never more, never fewer. You keep it true by always pairing one add with one matching remove. Break that pairing and the total quietly stops meaning anything.

The reusable skeleton, with the slots that change per problem:

build the state for the first window (indices 0 .. k-1)
record its answer
for each new right edge i from k to n-1:
    fold nums[i] into the state       # incoming
    fold nums[i-k] out of the state   # outgoing
    record / update the answer from the state

Solving a new fixed-window problem is just filling four slots: (a) the width, (b) what "state" you keep, (c) how to fold one element in and out of it, (d) what you record. Here: width k, state a running sum, fold is +/−, record is the max so far. The next two problems keep this exact skeleton and only swap the state.

Signals that should make you reach for it in an unseen question:
- the words "contiguous", "subarray", or "substring" together with a fixed, given size — "of size k", "exactly k long", "every window of length L";
- you want the best / whether-any / a count of something over all those equal-size blocks;
- N is large (10⁵ or more), so an O(N·k) re-scan is too slow and a single linear pass is clearly the intended answer.

And where it stops working, so you don't force it: if the size is not fixed — "the longest subarray whose sum stays under S" — the frame must grow and shrink, and you need the variable sliding window that comes next (Longest Substring Without Repeating Characters). Even with a fixed size, if the tracked quantity cannot be repaired in O(1) — the maximum inside the frame is the classic case, because when the current max slides out you have no idea what the next-biggest is — the plain rolling trick fails and you need extra machinery like a monotonic deque (that is Sliding Window Maximum). The frame idea survives in both; only the bookkeeping gets heavier.