You have built the entire toolkit: fixed windows, variable expand/shrink, frequency maps, while-vs-if shrinking, the atMost(K) trick, monotonic deques.

The hardest part is not using the tools. It is knowing when to reach for them.

In an interview, you get a problem statement and maybe 30 seconds of silence before the interviewer expects you to say something intelligent about your approach. In that silence, your brain needs to pattern-match: is this a sliding window problem? A two-pointer problem? A prefix sum problem? Dynamic programming?

The wrong classification is expensive. Picture this: you read “find two numbers in the array that sum to a target” and think “sliding window” because it mentions a target sum. You spend 8 minutes trying to make a window work before realizing the elements are not contiguous --- it is a hash map problem. Or you read “longest substring with at most K distinct characters” and think “dynamic programming” because it says “longest.” You build a state table before realizing a simple two-pointer scan does it in O(n).

These misclassifications are not random. They happen because the surface language of problems overlaps across techniques. “Longest” appears in DP problems and sliding window problems. “Sum” appears in prefix sum problems and sliding window problems. “Subarray” appears in divide-and-conquer problems and sliding window problems. The words lie. The structure doesn't.

The difference between a strong candidate and a struggling one is not how fast they code --- it is how quickly they identify which tool to reach for. What you need is a classification framework. A set of binary signals you can check in under 30 seconds that tell you “yes, sliding window” or “no, try something else.”

Can you do that classification on gut instinct alone? Let's find out.

Six problems are about to appear, one at a time. Some are classic sliding window. Some look like sliding window but aren't. Some don't look like sliding window but are.

For each one, you will make a call: sliding window or not? And if it is sliding window, which variant --- fixed-size, variable expand/shrink, frequency map, monotonic deque, or the atMost(K) subtraction trick?

Don't try to solve the problems. Don't think about implementation. You are doing pure pattern recognition --- the same 30-second classification that separates strong interview candidates from the ones who spend 10 minutes going down dead ends.

Read the problem statement, check for the signals (contiguous range? window constraint? monotonic?), and commit to an answer. No hedging. Some of these are deliberately tricky --- problems that trigger a sliding window instinct but violate one of the signals, or problems that look like something else entirely but satisfy all three.

Trust whatever intuition you have built from the previous screens. The gaps between your gut and reality are exactly where the framework in the next section will help.

The pattern recognition skill is not about memorizing which problems are sliding window. It is three signals checked in under 30 seconds:

Signal 1: Contiguous range? The problem asks about a subarray or substring, not a subsequence. This is the first and fastest check. Subsequences can skip elements, which breaks the window model entirely --- if you can skip elements, there is no “window” to slide.

Example pass: “Find the longest substring with at most K distinct characters.” Substring = contiguous. Pass.

Example fail: “Find the longest increasing subsequence.” Subsequence = elements can be non-adjacent. Fail immediately.

Signal 2: Window constraint? There is a condition on the contents of the window, not just its endpoints. The constraint defines what makes a window “valid” --- and you can test validity by examining only the elements inside the window.

Example pass: “Sum of the window >= target.” The sum depends only on what is inside. Pass.

Example fail: “Find two elements in the array that sum to target.” This depends on two specific elements, not a contiguous range of elements. Fail --- this is a hash map / two-pointer problem.

Signal 3: Monotonic constraint? Adding more elements to the window can only make the constraint harder to satisfy (or at least no easier). This is the subtlest signal and the one most people skip --- which is why they waste time trying to apply sliding window to problems where it cannot work.

Example pass: “At most K distinct characters.” Adding a character can only increase distinct count (or keep it the same). Making the window bigger can only make the constraint harder. Pass.

Example fail: “Subarray with sum exactly equal to K, where elements can be negative.” Adding a negative number can decrease the sum, meaning a larger window might actually be more valid than a smaller one. The constraint is not monotonic. Fail --- use prefix sums + hash map instead.

Kill signals --- any one of these means stop considering sliding window immediately:

• The problem says "subsequence" (not contiguous)
• Elements can be negative and the constraint involves exact sums (monotonicity breaks)
• There is no validity threshold (nothing to shrink toward)
• The constraint depends on element positions rather than values

Here is how the framework maps to your toolkit:

Test the framework on a tricky edge case:

Practice this on every new problem for a week. Within 30 seconds of reading the problem statement, run the three signals. The classification becomes automatic faster than you expect --- and once it is automatic, you spend your interview time on implementation instead of exploration.

You now have the complete sliding window toolkit: the mechanics, the variants, and the meta-skill to know when to use them.