Longest Repeating Character Replacement:
6 Bugs to a Clean Solution

Runs without crashing and looks reasonable — but only ever compares s[j] against the single character s[i], never tracking which character is actually most frequent in the window.

The validity condition for this problem is windowLength − (count of the MOST FREQUENT character in the window) ≤ k. This code instead checks s[i]===s[j] — a single fixed anchor character — and resets the window almost every time a different character shows up, even when the window would still be valid against its true majority character. Because the window resets on every mismatch, it can never grow past size 2.

characterReplacement("AABABBA", 1)
i=0,j=1: s[i]="A" === s[j]="A" → max_count=1, j=2
i=0,j=2: "A" !== "B" → max_count=2, temp_count hits 0 → reset i=1,j=2
i=1,j=2 ... i=2,j=3 ... i=3,j=4: same pattern repeats, resetting almost every step
Window never grows past size 2 because it only ever compares against s[i]
Returns 2   (WRONG — expected 4)

Good instinct switching to a frequency map, but three issues at once: the validity check compares against count[s[right]] (the newest character only) instead of the true window max, delete wipes an entire count instead of decrementing it, and right = left resets the window instead of sliding it.

delete count[s[left]] removes the key entirely — if that character appeared 3 times in the window, deleting it forgets all 3, not just the one leaving. Combined with windowSize - count[s[right]] (checking only the newest character, not the true max across the whole map) and right = left throwing the window back to size 1 on every shrink, the counts get corrupted and inflate over time instead of shrinking correctly.

characterReplacement("AABABBA", 1)
right=2: count={A:2,B:1}. Check compares windowSize(3) against count["B"](1), not the true max(2)
3 - 1 = 2 > k → shrink: delete count["A"] wipes BOTH A's, not one → count={B:1}
right jumps back to left (right=left), discarding the window instead of sliding it
Corruption compounds on every later shrink as counts get deleted instead of decremented
Returns 5   (WRONG — expected 4, larger than any single character's true frequency allows)

count[s[left]]-- is a real fix. But maxFreq is now being set to windowSize itself on every valid step — not the actual count of the most frequent character — and right never advances when the window is invalid.

Setting maxFreq = Math.max(maxFreq, windowSize) conflates two different concepts: the window's SIZE and the true frequency of its most common character. Those aren't the same number. Worse, in the else branch only left++ runs — right stays exactly where it was, so the very next loop iteration runs count[s[right]]++ again for that same index, double-counting a character that never actually re-entered the window.

characterReplacement("AABABBA", 1)
right=3: window "AABA" is genuinely valid (4-3=1≤k) but maxFreq gets set to windowSize(4), not the true char count(3)
right=4: window invalid — only left++ runs, right stays put, so count[s[right]]++ re-adds the same character next iteration
Stale, inflated maxFreq plus double-counted characters compound with every further step
Returns 7   (WRONG — expected 4, and impossible: no valid window this large exists for k=1)

Moving right++ into both branches correctly stops the double-counting bug. But the new line computing the window's true max frequency has two separate JavaScript mistakes.

Object.keys(count) returns the CHARACTERS ('A', 'B'), not their counts (3, 2) — so the reduce is comparing letters, not numbers. On top of that, the callback (max, obj) => max > obj returns a boolean (true/false), which is not a valid accumulator value for reduce. The very first Math.max(0, 'A') call coerces 'A' to NaN, and NaN propagates through every comparison for the rest of the run.

characterReplacement("AABABBA", 1)
right=0: count={A:1}. Object.keys(count) = ["A"] — the CHARACTER, not its count
.reduce((max, obj) => max > obj) returns a boolean on its first comparison, not a number
maxFreq = Math.max(0, "A") → NaN (a string cannot be compared numerically)
Every check after this involves NaN, which is never ≤ k
Returns NaN   (WRONG — expected 4, not even a valid number)

Object.values(count).reduce((max, val) => Math.max(max, val), 0) correctly computes the window's true max frequency. But it's computed INSIDE the if-block — after the validity check has already run against the OLD maxFreq from the previous iteration.

At the moment the if-condition is evaluated, count[s[right]] has already been incremented for the character just added — but maxFreq hasn't caught up yet. The check compares windowSize against a number that doesn't reflect the character that was just added, so a genuinely valid window can get rejected simply because the freshest data hasn't been folded into maxFreq yet.

characterReplacement("AABABBA", 1)
right=3: count becomes {A:3, B:1} after the increment — the true max frequency is now 3
But the if-check runs FIRST, still comparing against last iteration's maxFreq (2), not the fresh 3
4 - 2 = 2 > k → window "AABA" (which IS valid: 4-3=1≤1) gets incorrectly rejected and shrunk
maxFreq never gets the chance to update to 3 or higher again for the rest of the string
Returns 2   (WRONG — expected 4)

Moving the frequency recalculation above the if-check was the missing piece — the validity logic is now fully correct. The last bug is simpler: the function returns maxFreq, but maxFreq is not the answer.

maxFreq tracks 'the highest count of any single character seen in a window so far' — a helper value used only to decide whether to grow or slide. The actual answer is the longest valid WINDOW LENGTH. Because the window's size (right − left) never decreases in this loop — it only grows (valid branch) or holds steady (invalid branch, both pointers advance) — the final value of right − left after the loop equals the largest window size ever proven valid, which is exactly the answer.

characterReplacement("AABABBA", 1)
right=3: currMaxFreq correctly computed as 3 BEFORE the check — window "AABA" is validated correctly this time
maxFreq settles at 3 for the rest of the loop (the true max character frequency ever found)
But the function returns maxFreq (3) — a helper value — instead of right - left (which ends at 7-3=4)
Returns 3   (WRONG — expected 4; the validity logic is now fully correct, only the return value is wrong)