DEV Community: Jackson S

The 4 Caching Layers in Next.js App Router, in One Table

Jackson S — Sat, 17 Oct 2026 06:44:07 +0000

If you have ever asked "why is my Next.js page still showing old data?", the answer is almost always one of four caches. They live in different places, last for different lengths of time, and are cleared in different ways. Mixing them up is also one of the most common Next.js interview mistakes.

Layer	What it stores	Where	How long	How to invalidate
Request Memoization	Results of identical `fetch` / `React.cache` calls during one render	Server, in memory	One request	Nothing to do: it ends with the request
Data Cache	`fetch` responses	Server, persistent	Across requests (and, depending on your host, across deploys)	`revalidateTag`, `revalidatePath`, time-based `revalidate`
Full Route Cache	Rendered HTML + RSC payload of static routes	Server	Until revalidated or redeployed	Revalidating the data it depends on; dynamic APIs opt a route out
Router Cache	RSC payloads of visited and prefetched routes	Browser, in memory	The user's session, with time limits	`router.refresh()`, Server Actions that revalidate

How they work together

When a request hits a static route, Next.js first checks the Full Route Cache. If the page is there, it skips rendering entirely.

If not, it renders the Server Components. During that render, repeated identical fetch calls are deduplicated by Request Memoization, and each fetch checks the Data Cache before going to the network.

When your data changes, revalidateTag() purges the matching Data Cache entries, and the routes built from them are re-rendered on the next request.

On the client, the Router Cache keeps the RSC payloads of pages the user has already visited or prefetched, so back/forward and repeat navigation do not refetch them.

Three mistakes that come up in interviews

Confusing the Router Cache with the Full Route Cache. One lives in the browser, the other on the server. Clearing one does not clear the other.
Expecting revalidateTag() to update an already-open tab instantly. The server cache is fresh, but the open tab still has its Router Cache until the user navigates or you call router.refresh().
Assuming the Data Cache is wiped on every deploy. Depending on where you host, it can survive deploys, so stale data after a release is not always a build problem.

A version note

Defaults changed between Next.js 14 and 15. For example, fetch requests are no longer cached by default in 15. Check which version you are on before trusting any caching article, including this one.

I wrote a longer, interactive version of this (with code, a model interview answer and the common traps) as part of a free Next.js interview prep track I built: The Four Caching Layers in Next.js.

Kadane's algorithm: two lines in the wrong order return 0 for [-3, -1, -2]

Jackson S — Mon, 12 Oct 2026 04:30:00 +0000

Maximum subarray (LeetCode 53) is one of the most common interview warm-ups, and Kadane's algorithm solves it in one pass and constant space. It's also easy to write a version that passes the example in the problem statement and fails on an array of all-negative numbers. The difference is the order of two lines.

The idea

Walk the array while keeping a running sum of the subarray that ends at the current element. If that running sum ever drops below zero, throw it away: any later subarray is better off starting fresh than carrying a negative prefix. Along the way, remember the best sum you've seen.

The version that works

def max_subarray(nums):
    current = 0
    best = float('-inf')
    for x in nums:
        current += x
        best = max(best, current)   # 1. record the best
        if current < 0:             # 2. then discard a negative run
            current = 0
    return best

On [-2, 1, -3, 4, -1, 2, 1, -5, 4] it returns 6, from [4, -1, 2, 1]. On [-3, -1, -2] it returns -1, which is correct: the best subarray is the single element -1.

Two ways to break it

Reset before recording:

for x in nums:
    current += x
    if current < 0:
        current = 0
    best = max(best, current)       # sees 0, never the negative value

Start best at 0:

current, best = 0, 0

Both return 6 on the textbook example. Both return 0 on [-3, -1, -2] and on [-5]. There's no empty subarray to take, so 0 isn't an answer. Interviewers like all-negative input as a follow-up for exactly this reason.

The rule to remember: best has to see current before it's reset, and best has to start below any possible answer.

When Kadane isn't the right tool

Maximum product subarray (LeetCode 152). Two negatives multiply to a positive, so a negative running product can become the best one later. Discarding it is wrong; track both the running maximum and minimum product.
Circular arrays (LeetCode 918). The best subarray may wrap around. Take the larger of the ordinary maximum and total - minimum subarray, unless every element is negative.
A length limit. With "at most k elements", the reset rule no longer holds. Use prefix sums with a monotonic deque.

Seeing the two variables move

Most of Kadane's algorithm is in how current and best interact, and it's easier to see than to read. I built a free step-by-step Kadane's algorithm visualizer. You advance one element at a time and watch the running sum reset, with the matching code line highlighted in Python, Java, C++, JavaScript, TypeScript or C. Try an all-negative array and predict best before each step.

Disclosure: FaangPrep is my site. This lesson and the other introductory lessons open with no account; the other visualizers are free with an account, and the pattern courses are paid. This post was drafted with AI assistance and reviewed before publishing.

x & (x - 1) and three other bit tricks, and the one that lies about negative numbers

Jackson S — Fri, 09 Oct 2026 04:30:00 +0000

Bit manipulation questions look like trivia until you see that almost all of them come from four facts. Here they are, why each one works, and the shortcut that gives the wrong answer on negative numbers.

1. `x & 1` tells you if a number is odd

The lowest bit is the 1s column. It's 1 for every odd number and 0 for every even one, so x & 1 is the parity without a division.

def is_odd(x):
    return (x & 1) == 1

2. `x & (x - 1)` clears the lowest set bit

Subtracting 1 flips the lowest 1 bit to 0 and every 0 below it to 1. ANDing with the original keeps everything above that bit and zeroes the rest:

x         = 1011 0100
x - 1     = 1011 0011
x & (x-1) = 1011 0000

Two classic questions fall straight out of it:

def is_power_of_two(x):
    return x > 0 and (x & (x - 1)) == 0   # a power of two has exactly one set bit

def count_set_bits(x):                     # LeetCode 191; loops once per set bit
    count = 0
    while x:
        x &= x - 1
        count += 1
    return count

The x > 0 guard matters. Without it, 0 passes the check, because 0 & -1 is 0.

3. `x ^ x == 0` finds the element without a pair

XOR is its own inverse, and order doesn't matter. XOR every element of an array where each value appears twice except one, and the pairs cancel:

from functools import reduce
from operator import xor

def single_number(nums):                   # LeetCode 136
    return reduce(xor, nums, 0)

4. Shifts multiply and divide by powers of two, mostly

x << k multiplies by 2^k and x >> k divides by 2^k. For non-negative numbers that's exactly true. For negative numbers the right shift rounds down, while integer division in Java, C and C++ rounds toward zero:

Expression	Result
`-7 >> 1`	`-4`
`-7 / 2` in Java, C, C++	`-3`
`-7 // 2` in Python	`-4`

So replacing / 2 with >> 1 "for speed" changes the answer on negative input in Java and C. Compilers already make that optimisation where it's safe, so writing it by hand saves nothing. In C, shifting a negative number right is technically implementation-defined; every mainstream compiler gives -4.

Recognising a bit manipulation question

The problem statement usually gives it away. Look for "single number", "number of 1 bits", "power of two", "subsets of a small set" (a bitmask of length n enumerates all 2ⁿ subsets), or a hard O(1) space limit on a counting problem.

Watching the columns

Bitwise operators are easiest to understand as a column-by-column rule, and that's easier to see than to read. I built a free bit manipulation visualizer that shows AND, OR, XOR and shifts on the binary representation step by step, with the code in Python, Java, C++, JavaScript, TypeScript and C.

BFS has one line people get wrong: where you mark a node visited

Jackson S — Wed, 07 Oct 2026 04:30:00 +0000

Breadth-first search is usually the second graph algorithm anyone learns, and it looks almost too simple: a queue, a loop, a visited set. Most BFS bugs I see come down to one decision in that loop: when you mark a node as visited.

The idea, without code

Drop a stone in a pond. The first ripple reaches everything one step away, the second ripple everything two steps away, and so on. BFS explores a graph the same way. It visits every neighbour of the start node, then every neighbour of those, one layer at a time.

The queue is what keeps the layers in order. It is first-in, first-out, so every node from layer 1 is processed before any node from layer 2 is even looked at. That ordering is also why BFS finds the shortest path in an unweighted graph: the first time it reaches a node is along the fewest possible edges.

The standard version

from collections import deque

def bfs(graph, start):
    visited = {start}          # mark the start as soon as it is queued
    queue = deque([start])
    order = []

    while queue:
        node = queue.popleft()
        order.append(node)
        for neighbour in graph[node]:
            if neighbour not in visited:
                visited.add(neighbour)   # mark on ENQUEUE
                queue.append(neighbour)
    return order

graph = {
    'A': ['B', 'C'],
    'B': ['A', 'D', 'E'],
    'C': ['A', 'E'],
    'D': ['B'],
    'E': ['B', 'C'],
}
print(bfs(graph, 'A'))  # ['A', 'B', 'C', 'D', 'E']

The bug: marking on dequeue

Here is the version that looks equivalent:

def bfs_buggy(graph, start):
    visited = set()
    queue = deque([start])
    order = []

    while queue:
        node = queue.popleft()
        if node in visited:
            continue
        visited.add(node)            # mark on DEQUEUE
        order.append(node)
        for neighbour in graph[node]:
            if neighbour not in visited:
                queue.append(neighbour)
    return order

It returns the same order, so tests pass. Now trace the queue on the graph above.

A is dequeued. B and C are enqueued. Queue: B, C
B is dequeued. D and E are enqueued. Queue: C, D, E
C is dequeued. E isn't visited yet, because it's still waiting in the queue, so it's enqueued again. Queue: D, E, E

E is now in the queue twice. On this graph that costs one wasted loop. On a dense graph a node can be queued once for every edge leading into it. The queue grows toward O(E) instead of O(V), and on a large grid problem that's the difference between passing and a memory or time-limit failure.

The fix is the first version: mark a node visited the moment you put it in the queue, not when you take it out. At that point you've already committed to visiting it, and nothing else should queue it again.

Shortest path is the same loop with a distance map

Once the visited set is right, shortest path in an unweighted graph is a small change. Store each node's distance when you first enqueue it:

def shortest_path_length(graph, start, target):
    dist = {start: 0}
    queue = deque([start])
    while queue:
        node = queue.popleft()
        if node == target:
            return dist[node]
        for neighbour in graph[node]:
            if neighbour not in dist:        # dist doubles as the visited set
                dist[neighbour] = dist[node] + 1
                queue.append(neighbour)
    return -1

Because the first time BFS reaches a node is along the fewest edges, that distance is final the moment it's written.

When BFS is the wrong tool

Weighted edges. "Fewest edges" is no longer "cheapest path". Use Dijkstra's algorithm.
Very wide graphs. BFS holds an entire layer in memory. If a layer can be enormous and you only need to know whether a path exists, depth-first search uses less memory.

The quick recognition rule for interviews: if a problem asks for the shortest path, the fewest steps or the nearest something, and every step costs the same, it's almost always BFS.

Watching it run

The buggy version is easier to see than to read. I built a free step-by-step BFS visualizer. You advance one queue operation at a time, and the matching code line is highlighted in Python, Java, C++, JavaScript, TypeScript or C. Try predicting the queue contents before each step, especially where two nodes share a neighbour.

Disclosure: FaangPrep is my site. The BFS lesson and the other introductory lessons open with no account; the other visualizers are free with an account, and the pattern courses are paid. This post was drafted with AI assistance and reviewed before publishing.

How resume keyword matching actually works (and a free tool to check yours)

Jackson S — Mon, 05 Oct 2026 15:13:38 +0000

Most "your resume will be rejected by the ATS" advice is fear dressed up as fact. Here is what is actually going on, and what you can usefully check before you apply.

What a keyword match is

When a recruiter searches their applicant tracking system, they usually search for skills: Kubernetes, TypeScript, system design. Your resume shows up only if those words are in it. Whether a given company ranks or filters on them depends on how that company set its system up, and no outside tool can know that.

What you can control is simple: if the job description asks for Kafka and you have used Kafka, the word Kafka should be on your resume, spelled the way the posting spells it.

Three things that trip people up

Synonyms you assume count. "Built containerised services" does not contain the word Docker. A human might connect them; a keyword search will not.
Close-but-different terms. JavaScript is not TypeScript, and accessible UI is not accessibility. If the posting uses a specific term and you have the skill, use the term.
Repeated domain words. If a posting says "payments" five times, it matters to them. It is not a skill keyword, but if you have worked on payments, say so.

How to check a resume against a posting

By hand: list every technical term in the job description, then search your resume for each one. That is tedious, so I built a small checker that does it:

👉 Free resume keyword check

Paste your resume text and the job description. It shows:

the posting's technical keywords your resume already contains;
the ones it is missing;
a coverage percentage;
words the posting repeats that your resume never uses.

It runs entirely in your browser, so nothing is uploaded, and it needs no sign-up. It is honest about its limits: it matches keywords, and it does not judge layout or writing or predict any company's ATS.

One rule: only add skills you actually have. A keyword you cannot talk about in the interview is worse than a missing one.

If you want to go further

The same page has an AI tailoring step, which rewrites a resume against a specific job description. You approve every edit as a diff and see the match before and after. The first run is free with an account. Beyond that it is ₹30 per PDF download, or ₹299 for a month of unlimited use, with no auto-renewal.

Disclosure: FaangPrep is my site. The keyword check is free with no account. This post was drafted with AI assistance and reviewed before publishing.