Three Patterns, No Gaps

Two Pointers · Sliding Window · Binary Search — a complete, prerequisite-ordered path through 35 sub-variants, with verified Java 21 templates, failure-mode tables, a recognition guide, and per-sub-variant mastery gates.

Calibration: written for an advanced backend engineer doing FAANG prep in Java 21, LeetCode-numbered. The document is tiered rather than pitched at a single level: the ★ core path is the minimum sufficient set (a strong beginner can follow it linearly), ○ marks optional depth, and Extra Reps are pure repetition — skip them if the starred problem went clean the first time.

Total core: 78 problems. Everything else is explicitly labelled optional. Nothing here is padding; if a problem is listed, there is exactly one thing it teaches that no earlier problem taught.

All code templates in this document were compiled and executed against the listed test cases before being written down.

How to read the tables#

Problems within a sub-variant are in strict prerequisite order. Sub-variants themselves are in prerequisite order.

4 — RECOGNITION GUIDE#

4.1 The decision procedure#

Run these in order. Stop at the first match.

Step 0 — Read the output type. Does the answer reference original indices? If yes, you may not sort. That kills two pointers and index-based binary search immediately (LC 1 vs LC 167). If the answer is a set of values or a count or a length, sorting is on the table.

Step 1 — Is the answer a contiguous subarray/substring? If no → not sliding window. Subsequence problems are DP or greedy+binary search, never a window. ("Subsequence" and "subarray" being one letter apart in a problem statement has cost more interviews than any algorithm.) If yes → go to Step 2.

Step 2 — The monotonicity test. Do this on paper, always. Write down the validity predicate V(l, r) and answer one of these:

• Maximizing length: if [l,r] is valid, is every sub-window valid? (shrink-monotone)
• Minimizing length / counting: if [l,r] is satisfying, is every super-window satisfying? (grow-monotone)

Step 3 — Is the answer a number in a large range, with a cheap feasibility check? Signals, in rough order of reliability:

• The phrase "minimum possible maximum", "maximum possible minimum", "minimize the largest", "smallest X such that", "minimum time/speed/capacity/days to..."
• n <= 10^5 but the answer range is up to 10^9 — the intended complexity is O(n log(range)), and the log has nowhere else to come from.
• You can write a function feasible(x) in O(n) or O(n log n) that answers "is x good enough?" without needing to know the optimum.
• Greedy gets you a check but not a construction.

→ Binary search on the answer. Then decide direction: if bigger x makes life easier, it's first-true (§3.G). If bigger x makes life harder, it's last-true (§3.H).

Step 4 — Is there sorted (or rotated-sorted, or unimodal) structure over an index range? → Binary search on indices (§3.A–F). If you need the k-th smallest of a collection you cannot materialize, search the value range with a counting predicate (§3.I).

Step 5 — Sorted data, and the answer is a pair/triple/relationship between elements? → Two pointers. Converging if the target relationship has a direction (§1.A/B/C). Same-direction if you're comparing two sequences or compacting in place (§1.D/E/F).

Step 6 — Constant extra space demanded on an array of n values in range [1, n]? → Cyclic sort or sign-marking (§1.J).

Step 7 — Cycle, repetition, or "find the duplicate in O(1) space"? → Floyd on the implicit functional graph (§1.G).

4.2 Signal → pattern cheat table#

4.3 Trap cases — where the obvious pattern is wrong#

5 — MASTERY CHECKPOINTS#

Each gate is pass/fail, no partial credit. Gate conditions are things you do without an IDE, without hints, and without looking at your own notes. A gate you "mostly" pass is a gate you failed.

5.1 Two Pointers#

5.2 Sliding Window#

5.3 Binary Search#

5.4 Revisit rule for ★ problems#

Log every starred problem with an outcome the moment you finish it. The interval depends only on how you solved it, never on how you felt about it.

Additional rules that matter more than the intervals:

1. Blind template first. On every revisit, write the sub-variant's template from memory before opening the problem. If the template is wrong, that alone downgrades the attempt to Hinted regardless of how the problem goes.
2. Two strikes → step back. Any starred problem that fails to reach Clean on two consecutive revisits: stop, go back one sub-variant, and re-solve its last two starred problems. The failure is almost always upstream.
3. Failure-mode tagging. When a revisit isn't clean, tag it with the row number from the relevant §*.4 Failure Modes table. After ten problems you will have two or three dominant tags — those are your actual weaknesses, and they're worth more than any problem count.
4. The sub-variant transfer test. Once per sub-variant, take an unseen problem from the Extra Reps list and solve it cold. If the sub-variant's core problems are clean but the transfer fails, you learned the problems, not the pattern.
5. Never revisit an unstarred problem unless it's serving as a transfer test. Optional problems have no spaced-repetition schedule; that is what makes them optional.
6. Cap the queue at 12 due items. If more than 12 come due, do the oldest 12 and push the rest. A backlog you avoid is worse than an interval you stretch.

Appendix — Coverage summary#

The five ⚠︎ problems are the highest-value items in the document. They are the only ones that teach you when not to reach for the pattern, which is the difference between someone who has done 500 problems and someone who can solve an unseen one.