Algorithms YouTube Lecture Trace-Table Notes (Input, State, Invariant, Cost)
Algorithms lectures on YouTube are some of the best free teaching online — whole university courses on sorting, graphs, dynamic programming, and complexity. They are also easy to watch passively. The animation looks obvious, the pseudocode feels readable, and then on the exam you are asked to "show the state of the array after the third pass" and nothing comes.
The fix is to stop taking prose notes and start taking trace-table notes: for every algorithm, you run it by hand on a tiny input and record how its state changes. This guide shows a repeatable format for algorithms YouTube lecture trace-table notes, built around four questions: what is the input, how does the state change, what stays true, and what does it cost.
Why algorithms need traces, not summaries
A summary like "merge sort splits the array and merges sorted halves" is true and almost useless for an exam. Exams and coding interviews test whether you can execute the algorithm and reason about it.
| Prose summary | Trace-table note |
|---|---|
| Describes the idea | Shows each step on real values |
| Hard to check yourself against | Easy to self-test: re-run and compare |
| Hides off-by-one details | Exposes boundary cases |
| Says nothing about invariants | Makes the invariant visible per row |
The four-part card
For each algorithm in the lecture, build one card with four sections.
1. Input (tiny and deliberately awkward)
Pick an input small enough to trace by hand — four to seven elements for array algorithms, five or six nodes for graphs. Make it slightly awkward: include a duplicate, an already-sorted segment, or a node with no outgoing edges. Awkward inputs reveal edge cases.
2. State table
Columns are the variables the algorithm tracks; rows are steps. For insertion sort on [5, 2, 4, 2]:
| Step | i | key | Array after step | Note |
|---|---|---|---|---|
| start | – | – | 5 2 4 2 | |
| 1 | 1 | 2 | 2 5 4 2 | 5 shifted right |
| 2 | 2 | 4 | 2 4 5 2 | 5 shifted right |
| 3 | 3 | 2 | 2 2 4 5 | 5 and 4 shifted; stops at equal 2 (stable) |
That last note — "stops at equal 2" — is exactly the kind of detail that decides stability questions.
3. Invariant
Write one sentence that is true before and after every iteration. For insertion sort: "Before iteration i, the first i elements are sorted (relative to each other)." Then check it against each row of your table. If a row breaks it, either your trace or your invariant is wrong — both are worth finding out now, not during the exam.
4. Cost
Record best, worst, and typical running time, and — crucially — which input causes each. "Worst case O(n²) when the array is reverse-sorted" is far more useful than "O(n²)".
Add the timestamp where the lecturer derives or states the cost, so you can revisit the reasoning, not just the answer.
Watching workflow
Before the video (3 minutes)
Check the chapters or description for which algorithms are covered. Create an empty four-part card for each.
During the video
- Write the pseudocode in your own shorthand, with the timestamp.
- When the lecturer animates or traces an example, pause before each step and predict the next state. Then play and check.
- Note any invariant or correctness argument the lecturer gives, with a timestamp.
Pausing to predict feels slow, but it is the difference between watching an algorithm and learning one.
After the video (15–20 minutes)
- Close the video.
- Choose your own awkward input (not the lecturer's).
- Trace it from scratch into a fresh state table.
- Check the invariant against each row.
- Write the cost line with its triggering input.
- Only then reopen the video at the timestamps where you got stuck.
Adapting the table to algorithm families
| Family | Columns to track | Useful awkward input |
|---|---|---|
| Sorting | indices, key/pivot, array | duplicates, already sorted, reverse sorted |
| Binary search | low, high, mid, comparison | target absent, target at the edges |
| Graph traversal (BFS/DFS) | queue or stack, visited set, current node | disconnected node, cycle |
| Shortest paths | distance array, frontier, chosen node | two paths with equal cost |
| Dynamic programming | the table itself, cell being filled, recurrence used | smallest non-trivial size |
| Greedy | candidate set, choice made, reason | a case where a naive greedy rule fails |
For dynamic programming, the trace is the table. Fill it cell by cell and annotate which earlier cells each one depends on. That dependency arrow is usually what the exam is really testing.
Turning traces into exam practice
Trace cards create their own practice questions:
- "Show the state after step 3 on input X."
- "Which input makes this algorithm hit its worst case?"
- "State the invariant and explain why it holds after one iteration."
- "Modify the input so the algorithm behaves differently — what changes?"
Write two or three of these on the back of each card. In review, answer them on paper before checking your table.
Connecting traces to code
If your course involves implementation, add a fifth mini-section: a short test case. Use your awkward input as a unit test and your final state as the expected output. When your code fails, compare its intermediate states to your trace table. You have just built a debugging reference.
Common mistakes
- Tracing the lecturer's example only. You will remember the animation, not the algorithm. Always trace your own input.
- Inputs that are too large. Ten-element traces take forever and teach no more than five-element ones.
- Skipping the invariant. Correctness questions are common, and invariants are the standard tool for them.
- Writing complexity without the triggering case. "O(n log n)" alone does not tell you when quicksort degrades.
Find the trace moments faster
Long algorithms lectures can bury the key walkthrough at minute 47. SummarizAI is a Chrome extension that adds an on-page summary, chapters, chat, and Study flashcards to YouTube, so you can jump to the chapter where an algorithm is traced or ask the chat where the lecturer discussed the worst case. The free plan works as a student trial. The trace itself should still be yours — on paper, with your own awkward input.
Frequently asked questions
Do I need to trace every algorithm in the lecture?
Trace the ones likely to be examined or implemented. For minor variants, a single row noting what changes compared to the main algorithm is often enough.
How do I trace recursive algorithms like merge sort?
Use a small recursion tree instead of (or alongside) the table. Each node shows the sub-array and the result returned. Number the nodes in the order they finish.
Is this useful for coding interviews?
Yes. Interviewers often ask you to walk through your algorithm on an example. Practising traces builds exactly that skill.
What if the lecture never states an invariant?
Try to write one yourself, then check it in the textbook or course notes. If you cannot find one, ask in office hours or a course forum — it is a good question.
Should I memorise pseudocode?
Understand it well enough to rewrite it from the invariant and the trace. Pure memorisation tends to break under small changes to the question.
Related guides
- Machine Learning YouTube Lecture Intuition Notes (Claim, Model, Trap)
- Signals and Systems YouTube Lecture Transform Notes
- Control Systems YouTube Lecture Block-Diagram Notes
- CS Lecture YouTube Study Stack: Map, Code Claims, Practice
- Build a Question Bank From YouTube Lectures for Exams
- How to Take Notes From YouTube Lectures (A Workflow That Sticks)
Try SummarizAI on your next lecture
SummarizAI is a Chrome extension that adds a summary, chapters, and Study flashcards on the YouTube watch page. The free plan is a student trial—no need to leave the lecture tab.
Start the free student trial