← BlogGENERAL — 29 Apr 2026

The Concept I've 'Solved' Twice and Still Don't Fully Trust

I've solved every practice problem tied to this concept and I still wouldn't bet on myself to reproduce it cold. That gap is the actual subject of this post.

CategoryGeneral
Published29 Apr 2026
Reading time5 min
dsasliding-window

Next to my mistake log I keep a separate one for knowledge gaps — concepts, not incidents, each tagged Not Started, In Progress, or Filled. Filled has a real bar attached to it: two or three confident solves on problems that use the concept, not one lucky pass. Two entries have been sitting at "In Progress" for weeks now, and I keep expecting to close them out and haven't. This post is about both, and about what it means that I haven't.

Sliding window: the part that's still fuzzy

I opened this entry after "Minimum Size Subarray Sum," and then "Minimum Window Substring" came along and confirmed it needed to stay open. Both are solved — checked off, code passes, sitting in my repo as working solutions. What isn't solved is whether I could sit down cold with a new sliding-window problem and just know when to expand versus shrink, without groping around for a few minutes first. I also don't have a solid feel for tracking "is this window still valid" — I either recompute the whole thing every iteration, which feels wasteful, or try an incremental update and then spend a while unsure whether I actually got it right or just got lucky on the test cases. And I honestly couldn't tell you the real difference between a fixed-size window and a variable-size one beyond "one of them has a second pointer that moves on its own," which isn't really a definition, that's just a vibe.

The specific thing that trips me up, every time, is the order of operations when shrinking: do I check the validity condition before I decrement the window boundary, or after? It sounds like it shouldn't matter, until you're mid-problem and both orderings look equally plausible and you genuinely can't tell which one's right just by staring at it. "Minimum Window Substring" took roughly seven hints to get through. Seven. Not because I didn't understand the goal of the problem, but because I kept getting that one sequencing question backwards and not noticing until the output was wrong in a way that looked like a completely different bug.

Passing isn't the same as trusting yourself

Here's the part I want to be honest about instead of writing around: by the letter of my own log, sliding window doesn't get to be "Filled" on the strength of two solves, one of which needed seven hints. My own promotion rule says two or three confident solves, and neither of these was confident. I got there. That's different from being able to get there again without a search history and a lot of trial and error. There's a real gap between "I produced a working answer" and "I could reproduce the reasoning under pressure, on a problem shaped differently than the last one" — and pretending that gap doesn't exist just because the checkbox is technically checked kind of defeats the point of keeping this log at all, which is supposed to be telling myself the truth, not flattering myself.

K-sum: solving the problem without solving the pattern

The other open entry is the k-sum generalization — 3Sum extending to 4Sum, in theory extending to an arbitrary kSum. I opened it because 4Sum needed a lot of iterative debugging, most of it around duplicate-skipping logic that gets harder to reason about at every additional level of nesting. Skipping duplicates for the outer two loops of 4Sum isn't the same move repeated twice — it's a slightly different move each level down, and I never fully nailed down why it changes, just enough pattern-matching against my 3Sum code to get the test cases passing.

I did solve 4Sum. I also solved 3Sum Closest and 4Sum II. But 4Sum II is the one that actually proves my point here, in a bad way: I solved it with a hash-based approach — splitting the four arrays into two pairs, hashing sums of one pair, looking up complements from the other — that has basically nothing to do with the nested-loop-plus-two-pointer structure the rest of the k-sum family uses. It's a good solution. It's also me routing around the generalization question instead of answering it. "How do I extend this pattern to an arbitrary k" is exactly as open as it was before I solved 4Sum II, because 4Sum II never made me answer it.

What I'm actually going to do about it

I'm not going to force a tidy ending here, because there isn't one yet. What I'm actually planning: go back to "Longest Substring Without Repeating Characters," which is sitting in my log specifically as unfinished business for the sliding-window gap, and use it to try to nail down the expand/shrink sequencing without hints this time. And separately, deliberately re-attempt a kSum problem using the nested-two-pointer generalization on purpose — not the hash-based shortcut that happens to also work — because the point isn't getting a green checkmark, it's finding out whether I can actually derive the pattern for an arbitrary k or whether I'm still one level of nesting away from being lost. Neither of these is done. That's just the actual status right now, and it's why both entries are staying at "In Progress" instead of me bumping them up early because a finished-sounding ending would read better.

← My Most Frequent Bug Isn't a Bug, It's a TypoThe Macro That Took Five Tries to Even Compile →

Notes from readers

Comments — via GitHub