Sliding Window Mechanics: How Exponent's Mock

Patrick, the instructor behind the @pkodes1 channel, sat down with Exponent to record a nine-and-a-half minute mock interview on "Longest Substring Without Repeating Characters," and the video (published about 12 hours ago on youtube.com) does something most algorithm explainers skip: it narrates the failure modes, not just the solution.

The problem itself is LeetCode #3 and one of the most recycled questions in tech hiring. Given a string, find the length of the longest contiguous stretch of characters with no repeats. Input "abcbb" returns 3, because "abc" qualifies. codinginterview.com lists it in its 2026 FAANG preparation guide with a blunt justification: the question tests your ability to use sliding windows and manage state with hash sets. Translation: it is a pattern-recognition probe wearing an algorithm costume.

The Naive Path, and Why It Fails

Patrick starts where most candidates start: brute force. Check every substring. For input "abcbb" that means examining "a", "ab", "abc", "abcb", and so on, restarting from each index. The approach works on toy inputs and collapses at scale, running in O(n²) time. Patrick's phrasing in the transcript is unvarnished: "that will lead to a very bad time complexity of both of N squ which is just too slow to pass any interview for F."

The transcription garbles some of that, but the substance holds. Interviewers at large technology companies treat a brute-force-only answer as a screen-out. The O(n²) solution tells them the candidate can code; it doesn't tell them the candidate can recognize structure.

The Sliding Window Fix

The optimization Patrick walks through relies on two pointers and a hash set. The right pointer advances, adding each new character to the set. When the right pointer lands on a character already in the set, the left pointer advances, removing characters from the set until the window contains no duplicates again. The current window's length is right minus left plus one, because string indices are zero-based and the naive right-minus-left formula undercounts by one.

algo.monster describes the same mechanic in its written breakdown: the window grows to the right and slides its left edge in whenever a letter repeats. designgurus.io goes further, naming this problem a classic example in its list of top LeetCode patterns, arguing that most interview problems reduce to a handful of reusable shapes.

Patrick explains the linear runtime the way strong candidates should: both pointers only move forward, never backward, so each character gets added to the set once and removed from the set at most once. That is the amortized argument that justifies calling the whole thing O(n). Space complexity lands at O(k), where k is the size of the character set.

Where Candidates Actually Fall Apart

The most useful section of the video is the catalogue of mistakes, because these are the errors that turn a correct idea into a failed interview.

The first is the off-by-one in the length calculation. Patrick is explicit: "A lot of candidates will just use R minus L and then we lead to an off by one error. And if you don't find this off by one error, it can really set you back on passing the interview." Zero-based indexing is the culprit; forgetting the +1 produces a window that's one character short every single time.

The second mistake is subtler and, in my view, more diagnostic of how candidates actually think. Some use an if where they need a while when shrinking the window. They check the duplicate condition once, move the left pointer a single step, and then assume the window is clean. Patrick demonstrates the failure: on a substring like "abcb", the candidate moves the pointer once, never rechecks, and believes they've handled the duplicate when the duplicate is still in the window. The if version isn't a coding slip; it signals the candidate never fully modeled what the window contains at each moment.

geekshelp.org prescribes the same remedy in its FAANG question roundup: maintain a window [left, right], add characters as you go, and slide left when duplicates are found. The while-loop requirement is implicit in that phrasing and explicit in Patrick's walkthrough.

The Tiering Problem

Near the end of the video, Patrick ranks candidate performance in bands that reveal how interviewers actually calibrate. The top 10% write the O(n) solution cleanly with good variable names and solid reasoning. The top 1% explain to the interviewer why the solution guarantees O(n), specifically why the window only moves forward. The top 0.1% articulate the key insight that unlocks the jump from the naive approach to the linear one, and discuss the trade-offs in time and space between the two.

Patrick's exact words: "The top 1% of candidates will explain to the interviewer why this solution guarantees O of N, why the window always moves forward, never moves backwards." The distinction between bands is communication, not correctness. A candidate who writes the same code but never explains the amortized argument sits in a different tier than one who does.

This tiering deserves scrutiny. It implies the interview is testing pedagogy as much as implementation, and that the highest scores go to candidates who can narrate their own reasoning in real time. Whether that's a fair proxy for on-the-job ability is a live debate in the industry; the video treats it as settled fact and moves on.

The Ecosystem Around One Problem

It's worth zooming out. This is a nine-minute video about one LeetCode problem, embedded in a platform whose business model is interview preparation. Exponent describes itself as the fastest-growing tech interview prep platform, built by people from Google, Meta, Anthropic, OpenAI, and other major companies, offering courses across product management, software engineering, system design, and machine learning interviews. The video description links to a paid SWE prep course and closes with a call to action to practice "anything software engineering."

The prep-industrial complex around FAANG interviews has its own logic. Sites like algo.monster and designgurus.io organize hundreds of problems into patterns, on the theory that pattern recognition beats problem-by-problem memorization. Codinginterview.com's guide catalogues questions by company and topic. The result is a market where the questions are public, the optimal solutions are documented, and the differentiator between candidates becomes speed of recognition plus polish of explanation.

That has consequences. A candidate who has drilled the sliding-window pattern can solve "Longest Substring Without Repeating Characters" in under five minutes and spend the remaining interview time performing explanation. A candidate encountering the problem cold, even a strong engineer, may burn minutes rediscovering what the drilled candidate memorized. Interviewers know this dynamic exists. Whether they can compensate for it, or whether the signal has degraded past usefulness, is the argument running underneath every one of these prep videos.

Patrick's tiering system is, in that light, a description of preparation. The top 0.1% candidate is the one who has internalized not just the pattern but the meta-lesson: explain the amortized argument, discuss trade-offs, narrate the journey from naive to optimized. Those are learnable behaviors, teachable through courses, and exactly the behaviors a prep platform sells.

The sliding-window solution is correct, the common mistakes are common, and the communication advice matches what interviewers at major technology companies say they look for. The tension sits one layer up: a hiring process that rewards drilled pattern recognition and polished narration is measuring preparation intensity, and the industry has built a paid infrastructure to intensify preparation. Candidates without time, money, or awareness of that infrastructure compete on a tilted field.

The video ends, as prep content does, with a pitch to subscribe and check the linked courses. The algorithm is free to learn. The environment that turns knowing it into a job offer is not.

Dev Kapoor