Forem: Alex Mateo

Sliding Window & Two Pointers: The Decision Framework Nobody Teaches You

Alex Mateo — Thu, 14 May 2026 09:53:58 +0000

Most people learn sliding window and two pointers as two separate techniques, practice them in isolation, and then freeze when a new array problem appears because they can't tell which one applies.

The problem isn't that the techniques are hard. The problem is that nobody teaches the decision — the moment before you write code where you look at the problem and know, without guessing, which pattern fits.

This guide fixes that.

What sliding window actually solves

Sliding window is for problems where you need to find or optimize a contiguous subarray or substring that satisfies some condition. The word contiguous is the key. You're not picking elements from anywhere in the array — you need a connected segment.

The window metaphor is accurate: you have a left and right boundary, and you move them to expand or shrink a range while tracking something inside it (a sum, a character count, a frequency map).

The reason it works efficiently is that instead of recalculating from scratch every time the window changes, you update incrementally. Remove the leftmost element, add the new rightmost element, update your state. Most operations become O(1) per step, making the overall complexity O(n) instead of O(n²).

There are two variants and confusing them leads to buggy implementations:

Fixed-size window — the window size is given in the problem. Maximum sum subarray of size k. Average of every subarray of length k. Here you advance both pointers in lockstep, maintaining a constant distance between them.

Variable-size window — the window grows and shrinks based on a condition. Longest substring without repeating characters. Minimum window substring containing all target characters. Here the right pointer advances to expand, and the left pointer catches up when the condition is violated.

What two pointers actually solves

Two pointers is for problems where you need to find a pair, a triplet, or a partition based on a mathematical relationship — not a subarray, but a combination of elements.

The classic setup: a sorted array, find two numbers that sum to a target. You start with one pointer at the beginning and one at the end. If the sum is too small, move the left pointer right. If it's too large, move the right pointer left. You're using the sorted order to eliminate half the search space with each step.

This is fundamentally different from sliding window. You're not maintaining a window — you're navigating a relationship between two positions that can move independently, in opposite directions or the same direction, depending on the problem.

The non-obvious insight about two pointers is that it often applies to problems that don't immediately look like pair-finding. Container with most water. Trapping rain water. Removing duplicates in place. These look different on the surface but all follow the same logic: two positions scanning inward (or outward) based on a condition, using the array's structure to prune the search space.

The decision framework

When you see an array or string problem, two questions narrow the pattern almost instantly.

First question: are you looking for a contiguous subarray, or a combination of elements?

If the answer is contiguous — a substring, a subarray, a window — you're in sliding window territory. If the answer is a pair, triplet, partition, or two elements with a relationship, you're looking at two pointers.

Second question: does the array need to be sorted (or can it be sorted without losing information)?

Two pointers on an unsorted array usually doesn't work because you lose the ability to decide which pointer to move. If sorting is required and valid, two pointers is likely the right tool. If the problem specifies the order matters and you can't sort, you're probably in sliding window territory.

This table makes the decision explicit:

Signal in the problem	Pattern	Why
"Subarray", "substring", "contiguous"	Sliding window	Need to track a connected range
"Sum equals target", sorted input	Two pointers	Sort + inward scan eliminates search space
"Longest/shortest subarray with condition"	Sliding window (variable)	Shrink/grow window based on constraint
"Pair that satisfies X", sorted or sortable	Two pointers	Independent pointer movement
"Remove duplicates in place"	Two pointers	Read/write pointer separation
Fixed subarray size, rolling computation	Sliding window (fixed)	Incremental update O(1) per step

The single question that separates the two most clearly: "Do I need these elements to be adjacent in the original array?" If yes, sliding window. If no, two pointers.

The templates

Both patterns have clean templates that you should know cold. Not memorized — understood, so you can reconstruct them under pressure.

Fixed-size sliding window:

def fixed_window(arr, k):
    window_sum = sum(arr[:k])
    result = window_sum

    for i in range(k, len(arr)):
        window_sum += arr[i] - arr[i - k]
        result = max(result, window_sum)

    return result

The key line is arr[i] - arr[i - k]: you add the incoming element and subtract the one that just left. No recomputation.

Variable-size sliding window:

def variable_window(arr):
    left = 0
    state = {}   # or a counter, sum, set — depends on the problem
    result = 0

    for right in range(len(arr)):
        # expand: include arr[right] in state
        # ...

        while condition_violated(state):
            # shrink: remove arr[left] from state
            left += 1

        result = max(result, right - left + 1)

    return result

The while loop is the core. The right pointer always moves forward. The left pointer only moves when the current window violates the constraint. The window size at any moment is right - left + 1.

Two pointers (sorted array, sum target):

def two_sum_sorted(arr, target):
    left, right = 0, len(arr) - 1

    while left < right:
        current = arr[left] + arr[right]
        if current == target:
            return [left, right]
        elif current < target:
            left += 1
        else:
            right -= 1

    return []

The invariant: at every step, you're narrowing the search space by one. left < right ensures you never check the same pair twice.

The problems that make these patterns click

There are specific problems that reveal the pattern clearly rather than hiding it behind complexity. These are the ones worth doing before jumping to harder variations.

For fixed-size sliding window, start with Maximum Average Subarray I (LeetCode 643) and Maximum Sum of Subarray of Size K. These problems make the incremental update concrete.

For variable-size sliding window, Longest Substring Without Repeating Characters (LeetCode 3) is the canonical example. The character frequency map and the shrinking left pointer are the template in its simplest form. After this, Minimum Window Substring (LeetCode 76) is the harder version that tests whether you understood the shrinking logic or just memorized it.

For two pointers, start with Two Sum II (LeetCode 167) — the sorted version. Then Container With Most Water (LeetCode 11), which uses the same inward-scanning logic but applied to a geometry problem. 3Sum (LeetCode 15) extends two pointers by adding an outer loop, and it's the most common two pointers problem in FAANG interviews.

The thing that connects all of these: solve them by tracing through a small example by hand first. Draw the array. Draw the pointers. Move them step by step. The visual trace makes the logic stable in a way that reading code never does.

What interviewers actually test

In a sliding window or two pointers interview, the algorithm itself is table stakes. What separates good candidates is everything around it.

Strong candidates articulate the contiguous vs. combination distinction before writing code. They say "I'm using sliding window because I need a subarray — the elements need to be adjacent" and that sentence shows the interviewer you're not pattern-matching on keywords.

They also handle the edge cases clearly: empty input, window larger than array, no valid window exists. These cases are easy to handle once the main logic is clean — but candidates who don't understand the pattern deeply always forget them.

The bug that appears most often in sliding window implementations is an off-by-one in the window size calculation. right - left + 1 is the window size, not right - left. Drawing the window on paper before coding eliminates this.

The bug that appears most often in two pointers is updating pointers incorrectly when the target is found — advancing only one pointer instead of both, which causes an infinite loop. The fix: when you find a match, do left += 1 and right -= 1 simultaneously.

How to study so these patterns transfer

The mistake most people make is solving twenty sliding window problems in isolation and then interleaving random LeetCode problems expecting the pattern to stick. It doesn't work that way.

What works is blocked practice followed by interleaving. Solve ten sliding window problems in a row — fixed window, then variable window, then mixed. Then solve ten two pointers problems. Then, and only then, mix them. The goal of the blocked phase is to build recognition. The goal of the interleaving phase is to test whether the recognition is real or superficial.

After each problem, write one sentence before closing the tab: "This was sliding window because ___" or "This was two pointers because ___". That sentence forces you to articulate the why, which is exactly what you'll need to do in the interview.

FAQ

What is the difference between sliding window and two pointers?

Sliding window is for contiguous subarrays or substrings where you maintain a connected range with left and right boundaries. Two pointers is for pair or partition problems where two positions scan the array independently, often from opposite ends. The key question: do the elements need to be adjacent?

When should I use sliding window vs two pointers in an interview?

Use sliding window when the problem asks for a subarray, substring, or contiguous section satisfying a condition. Use two pointers when the problem involves finding pairs, triplets, or requires sorting the input and scanning inward.

What is the time complexity of sliding window?

O(n) for both fixed and variable window. Each element is added to and removed from the window at most once, making the total operations linear regardless of window size.

Is two pointers O(n)?

Yes for the standard sorted-array variant. Each pointer moves at most n steps in total, giving O(n) after the initial sort (which is O(n log n), making the overall complexity O(n log n) when sorting is required).

I built Expora to make exactly this kind of pattern recognition visual. The sliding window debugger shows the left and right boundaries moving in real time, the window contents updating with each step, and the state (sum, frequency map, etc.) changing incrementally. Seeing it run on your own code makes the template feel obvious rather than arbitrary.

Originally published at tryexpora.com/blog/sliding-window-two-pointers

Graph Algorithms for Coding Interviews: When to Use BFS, DFS, or Dijkstra

Alex Mateo — Thu, 23 Apr 2026 08:12:38 +0000

Graphs are the most feared topic in coding interviews — not because they're impossible, but because most people learn BFS, DFS, and Dijkstra in isolation without understanding when to use each one.

This guide gives you the decision framework that turns graph problems from guesswork into a systematic process.

The three algorithms every interviewer expects you to know

BFS — Breadth-First Search

Data structure: Queue (FIFO)
Complexity: O(V + E) time, O(V) space

Use when:

You need the shortest path in an unweighted graph
You need the minimum number of steps to reach a target
You need to explore nodes level by level

Don't use when: the graph has weighted edges — BFS treats all edges as equal cost.

Classic problems: Binary Tree Level Order Traversal, Rotting Oranges, Word Ladder, Shortest Path in Binary Matrix.

Interview tip: Always say explicitly: "I'm using BFS because I need the shortest path in terms of edges, and BFS guarantees the first time I reach a node it's via the shortest path." That sentence shows you understand the why, not just the how.

DFS — Depth-First Search

Data structure: Stack (implicit via recursion, or explicit)
Complexity: O(V + E) time, O(V) space

Use when:

You need to detect cycles
You need to find all paths (not just shortest)
You need to check connectivity or count connected components
You need topological sort

Don't use when: you need the shortest path — DFS doesn't guarantee it.

Classic problems: Number of Islands, Course Schedule, Clone Graph, Pacific Atlantic Water Flow.

Interview tip: The most common DFS bug is forgetting to mark nodes as visited before recursing. Always set visited[node] = true at the start, before processing neighbors.

Dijkstra's Algorithm

Data structure: Min-heap (priority queue)
Complexity: O((V + E) log V) time, O(V) space

Use when:

The graph has weighted edges with non-negative weights
You need the shortest distance from source to target (or all nodes)

Don't use when: the graph has negative edge weights — use Bellman-Ford instead.

Classic problems: Network Delay Time, Path With Minimum Effort, Cheapest Flights Within K Stops.

Interview tip: The Dijkstra pattern is always the same: push (cost, node) to the heap → pop cheapest → skip if visited → process neighbors. Know O((V+E) log V) and be able to explain why.

The decision framework

When you see a graph problem, run through this before writing a single line of code:

Signal	Algorithm	Reason
Unweighted graph, need shortest path	BFS	Expands level by level — first reach = shortest
Minimum number of steps / hops	BFS	"Steps" = edges = unweighted
Weighted graph, all weights ≥ 0	Dijkstra	Greedy expansion via min-heap
Weighted graph with negative edges	Bellman-Ford	Dijkstra's greedy assumption breaks
Cycle detection	DFS	Track visited + in-stack state
All paths, not just shortest	DFS + backtracking	BFS doesn't enumerate all paths
Connected components / flood fill	DFS or BFS	Either works — DFS simpler recursively
Topological sort	DFS or Kahn's BFS	DFS post-order = reverse topological order

The single question to ask first: "Does the graph have weights?"

No → choose between BFS (shortest path) and DFS (full exploration)
Yes → Dijkstra (non-negative) or Bellman-Ford (negative weights)

That question narrows the decision from three options to two in almost every case.

What interviewers actually look for

Senior interviewers rarely test whether you can implement BFS from scratch. They test whether you can reason about graph problems systematically.

What separates strong candidates:

Clarifying the graph structure before coding. Directed or undirected? Weighted or unweighted? Can there be cycles? These change the algorithm — asking shows you're not pattern-matching blindly.
Explaining why you chose the algorithm. "I'm using BFS because the graph is unweighted and I need minimum steps" is a complete answer. "I'll use BFS" is not.
Recognizing implicit graphs. Many problems don't say "graph" — they present a grid, a word transformation, a dependency list. Rotting Oranges is multi-source BFS. Word Ladder is shortest path on an implicit graph.
Knowing complexity without being asked. O(V + E) for BFS and DFS, O((V + E) log V) for Dijkstra. Being able to derive these (not just recite them) is the difference at top companies.

How to study so graph algorithms actually stick

Most resources explain algorithms in isolation — here's how BFS works, here's DFS — without building the mental model of when to use each one.

What actually works:

1. Watch execution before writing code. For BFS, watch the queue grow and shrink level by level. For Dijkstra, watch the min-heap pop nodes in cost order and the distance table update. This visual step makes implementation feel natural.

2. Implement on the same graph. Take a 5-node, 7-edge graph. Run BFS, then DFS, then Dijkstra (with weights). Seeing three different traversal orders on the same graph makes the differences concrete.

3. Practice on grid problems. A 2D grid is a graph where each cell is a node and adjacent cells are edges. Grid problems are the most common disguised graph problems in interviews — the pattern transfers directly.

4. Build the decision reflex. After solving, write one sentence: "This is BFS because the graph is unweighted and I need shortest path." Train the recognition, not just the implementation.

FAQ

When should I use BFS vs DFS in a coding interview?

Use BFS when you need the shortest path in an unweighted graph or the minimum number of steps. Use DFS when you need all paths, cycle detection, or connectivity. If shortest path isn't required, both work — DFS is simpler to implement recursively.

What is the difference between BFS and Dijkstra?

BFS finds shortest path by number of edges (unweighted, every edge = cost 1). Dijkstra finds shortest path by total weight (weighted, uses min-heap). BFS for "minimum hops", Dijkstra for "minimum cost."

Can DFS find the shortest path?

No. DFS finds a path, not necessarily the shortest. Use BFS for unweighted shortest path, Dijkstra for weighted.

I built Expora to solve exactly this — the gap between knowing how an algorithm works and knowing when to use it. Expora's visual debuggers show BFS, DFS, and Dijkstra executing step by step on real graphs, so you build the decision intuition that interviewers test, not just the ability to implement from memory.

Originally published at tryexpora.com/blog/graph-algorithms-coding-interview

Why LeetCode is So Hard — and Why Grinding More Problems Won't Help

Alex Mateo — Tue, 21 Apr 2026 08:23:18 +0000

Here's why grinding leads to memorization, not understanding, and what to do instead.

You've solved 150 problems. You read the editorial. You watched the NeetCode video.

And then a slightly different problem appears in the interview and you blank.

It's not you. It's what you've been practicing.

The real reason LeetCode feels impossible

When developers say LeetCode is hard, they usually mean the problems are tricky or
they can't figure out the right approach. But there's a third reason nobody talks
about — LeetCode only shows you the answer, not the thinking.

Submit a solution. Green checkmark. Move on.

What the platform doesn't show you is what happened inside the algorithm: which
variable changed, why a pointer moved, what the data structure looked like at step 3.
You only ever see the output.

This matters because coding interviews don't test if you know the answer.
They test if you can explain the reasoning.

When an interviewer asks "why did you use a hashmap here?", the correct answer
isn't the solution — it's the thought process behind it. LeetCode trains you to
produce solutions. It doesn't train you to understand them.

What LeetCode shows you	What you actually need
✗ Input and output	✓ What the algorithm does at each step
✗ Runtime and memory stats	✓ Why a specific data structure was chosen
✗ Green or red checkmark	✓ How the state changes with each decision
✗ The accepted solution (after you fail)	✓ The intuition that transfers to new problems

That gap between "submitting a solution" and "understanding an algorithm" is why
LeetCode feels hard even after hundreds of problems.

What grinding actually does to your brain

The conventional advice is: do more problems. Grind 75, then 150, then 300.
The theory is that pattern recognition emerges from volume.

Here's the problem: pattern recognition requires understanding, not repetition.

You can't recognize that a problem needs a sliding window if you only know that a
previous problem that looked similar used a sliding window. That's memorization.

It breaks the moment the problem is phrased differently.

The grinding trap: You solve problem #47 and feel like you understand
two pointers. Three weeks later, a different two-pointer problem appears and
you can't start it. You go back and re-solve problem #47. The cycle repeats.
You're not building understanding — you're fighting the Ebbinghaus forgetting
curve with repetition instead of comprehension.

The developers who pass FAANG interviews typically haven't solved more problems
than the ones who fail. They've understood fewer problems more deeply.

The difference between memorizing and understanding

Here's a concrete example. Most developers who have done LeetCode know Two Sum.

Ask them to solve it: they'll write a hashmap solution in two minutes.

Now ask them: "If the input array is sorted, which approach is better?"

Many will still reach for the hashmap — because that's what they practiced.
They memorized the solution, not the reasoning behind choosing it.

Understanding means being able to trace through the algorithm at each step:

nums = [2, 7, 11, 15], target = 9

Step 1: L=0, R=3 → sum = 2+15 = 17 > 9
        → Too large. Move R left.
        → WHY: sorted array, moving R left always decreases sum.

Step 2: L=0, R=2 → sum = 2+11 = 13 > 9
        → Still too large. Move R left again.

Step 3: L=0, R=1 → sum = 2+7 = 9 ✓
        → Found it.

Key insight: sorted input makes two pointers strictly better than hashmap.
O(n) time, O(1) space vs O(n) space. The code is almost identical —
the understanding is completely different.

The difference isn't the code. It's being able to explain why the approach
changes when the input is sorted.

Understanding an algorithm means answering 3 questions at any step

What is the current state? Where are the pointers, what's in the queue,
what does the data structure look like right now?
Why did the last step happen? What condition triggered this move,
this push, this comparison?
What will happen next? Given the current state, can you predict the
algorithm's next decision before it happens?

You can't answer any of these by reading the accepted solution. You need to
see the algorithm run.

What to do instead of grinding

1. Learn patterns, not solutions

Most coding interview problems are variations of 7-10 core patterns: Sliding Window,
Two Pointers, BFS, DFS, Binary Search, DP, and Dijkstra. Learn them at the
pattern level — not the problem level. When you recognize the pattern, the
solution follows.

2. See execution, not just code

Before writing anything, trace through the algorithm manually. Watch the state
change. Understand why each step happens. Only then write the code.

3. Solve fewer problems, more deeply

One deeply understood problem — where you can explain every step, every decision,
every tradeoff — is worth more than 10 memorized solutions.

4. Practice explaining out loud

After solving, close the editor and explain the solution as if talking to an
interviewer. If you can't explain why each line exists, you memorized it.

FAQ

Is LeetCode worth it?

LeetCode is worth it if you use it to build understanding, not just to accumulate
solved problems. Used correctly — slowly, with deliberate tracing — it's a useful
problem bank. Used as a grinding machine, it builds recall that breaks under
interview pressure.

How many LeetCode problems do I need for Google or Meta?

There's no magic number. Being able to trace 50 algorithms step by step and explain
every decision beats having memorized 300 solutions. Interviewers evaluate your
reasoning, not your problem count.

What is grinding LeetCode?

Grinding LeetCode means solving a high volume of problems (150-300+) with the goal
that pattern recognition emerges from volume. It's the dominant prep approach, but
it fails when problems are phrased differently or when interviewers ask you to
explain your reasoning.

I built Expora specifically because I was that developer —
I had Grokking Algorithms, the algorithm bible, three courses, and 200 LeetCode
problems solved. I still froze in interviews because I was memorizing, not
understanding.

Expora's visual debuggers let you step through algorithms one operation at a time —
watching the graph update, the queue fill, the dp table populate — with your own
code. It's the difference between reading about an algorithm and watching it think.

If you've ever felt like grinding isn't working, you're probably right.
The problem isn't your intelligence — it's the feedback loop you're practicing in.

Originally published at tryexpora.com/blog/why-leetcode-is-hard