DSA Handwritten Notes: How to Make Notes You Actually Revise

Searches for "DSA handwritten notes" keep growing, and for a good reason. When you have solved two hundred problems and the interview is next week, you cannot re-solve them all. You need something you can revise from in an evening, and a long book or a folder of bookmarked videos is not it.

Good handwritten notes are that something. This guide explains why they work, what belongs on each page, two sample pages you can copy, and a six-week plan for building and revising your own set.

Why handwritten notes work for DSA

• Writing forces you to compress. You cannot copy a whole editorial by hand, so you write the idea that makes the problem click. That idea is what you need to recall in an interview.
• Diagrams are faster by hand. A linked-list reversal, a recursion tree or a sliding window is three seconds of drawing and a paragraph of text.
• Revision gets fast. A page per topic means the whole of DSA fits in 40 to 60 pages, which you can flip through in an hour before an interview.
• Recognition beats memorisation. Interviews rarely repeat a problem exactly. Notes organised by pattern train you to see "this is a sliding window" in a problem you have never seen.

Handwritten does not have to mean paper. A tablet with a stylus works just as well, as long as you are writing and drawing rather than pasting.

What goes on one page

Use the same layout for every topic, so your eye knows where to look when you revise:

• When to use it. The signals in a problem statement: "sorted array", "longest substring", "top K", "minimum number of steps".
• The core idea in one or two sentences.
• A template – ten lines of code at most, with the tricky lines marked.
• A diagram of the template running on a tiny example.
• Complexity – time and space.
• Traps – the off-by-one errors and edge cases you actually made.
• Three problems you solved with it, each with the one-line insight.

Sample page 1: sliding window

When to use it: a contiguous subarray or substring, with words like "longest", "shortest" or "at most K".

Core idea: grow the window from the right; while it breaks the rule, shrink it from the left. Each element enters and leaves once, so the whole scan is O(n).

// Longest substring without repeating characters
int longest(String s) {
    Map<Character, Integer> count = new HashMap<>();
    int best = 0;
    for (int left = 0, right = 0; right < s.length(); right++) {
        char c = s.charAt(right);
        count.merge(c, 1, Integer::sum);
        while (count.get(c) > 1) {               // window breaks the rule: shrink
            count.merge(s.charAt(left++), -1, Integer::sum);
        }
        best = Math.max(best, right - left + 1);
    }
    return best;
}

Complexity: O(n) time; O(k) space for k distinct characters.

Traps: the window length is right - left + 1, not right - left; update the answer after shrinking, not before.

Problems: longest substring without repeating characters; minimum size subarray sum (shrink while the sum is at least the target); longest repeating character replacement (window length minus the most frequent count must stay at most K).

Sample page 2: binary search on the answer

When to use it: "find the minimum X such that…" or "the maximum X such that…", where a bigger X never turns a yes into a no.

Core idea: you are not searching an array; you are searching the range of possible answers for the point where a check flips from false to true.

// Koko eating bananas: smallest speed that finishes all piles within h hours
int minSpeed(int[] piles, int h) {
    int lo = 1, hi = Arrays.stream(piles).max().getAsInt();
    while (lo < hi) {
        int mid = lo + (hi - lo) / 2;
        if (hoursAt(piles, mid) <= h) hi = mid;   // fast enough: try slower
        else lo = mid + 1;                         // too slow: must go faster
    }
    return lo;
}

long hoursAt(int[] piles, int speed) {
    long hours = 0;
    for (int p : piles) hours += (p + speed - 1) / speed;   // ceiling division
    return hours;
}

Complexity: O(n log M), where M is the largest pile.

Traps: pick lo and hi so the answer is always inside the range; use lo < hi with hi = mid, or the loop never ends; sum in a long to avoid overflow.

Problems: Koko eating bananas; capacity to ship packages within D days; split array largest sum.

The topics your notes should cover

About one page each, two for the big ones. This is the set that covers almost every interview problem:

• Complexity analysis and the Big-O of common operations
• Arrays, strings and prefix sums
• Hashing: maps, sets and counting
• Two pointers and sliding window
• Linked lists: reversal, slow and fast pointers, dummy head
• Stacks, queues and the monotonic stack
• Binary search, including binary search on the answer
• Sorting: merge sort, quicksort and when stability matters
• Recursion and backtracking
• Trees: traversals, BST properties, lowest common ancestor
• Heaps and top-K problems
• Graphs: BFS, DFS, topological sort, Dijkstra, union-find
• Dynamic programming: 1D, 2D, knapsack, subsequences
• Greedy algorithms and intervals
• Bit manipulation basics

Not sure what each topic involves? Our guide to common data structures and algorithms interview questions walks through every one with the questions interviewers ask.

A six-week plan to build and revise them

• Week 1 – Foundations. Complexity, arrays, strings, hashing, prefix sums. Five problems per topic, one page each.
• Week 2 – Pointer patterns. Two pointers, sliding window, linked lists, stacks and queues.
• Week 3 – Searching and sorting. Binary search (both kinds), sorting, intervals, heaps.
• Week 4 – Trees and graphs. Traversals, BST, BFS, DFS, topological sort.
• Week 5 – Recursion and DP. Backtracking first, then dynamic programming, from 1D up to 2D.
• Week 6 – Revise and mock. Flip through all your pages every second day, re-solve one problem per page from a blank file, and do at least two timed mock interviews.

After week 6, keep the notes and revise them the evening before each interview. That is where the time you spent writing them pays off.

Mistakes that make notes useless

• Copying full solutions. If a page looks like a code listing, you will not read it again. Keep the template and the insight.
• Organising by problem number. "Problem 76" means nothing in an interview. Organise by pattern.
• Never revisiting. Notes you read once are a diary. Schedule the revision.
• Skipping your own mistakes. The traps section is the most valuable part of the page. Write down every bug you made.

Short on time? Start from ours

Building the full set takes weeks. If your interview is sooner, our handwritten DSA notes cover arrays, linked lists, stacks and queues, trees and graphs, sorting and searching, dynamic programming, greedy algorithms, recursion, backtracking and hashing, with flowcharts and diagrams, made for revision before product-company interviews. Use them as a base and add your own traps in the margins.

Preparing for a Java role? Pair your DSA practice with the 30-day Java interview roadmap.