To revise computer science theory, stop rereading definitions and start tracing state. Most CS theory questions, in data structures, operating systems, networking and databases, give you an input and ask what happens to it: where the key lands, which process runs next, which packet is sent, which row is locked. So revise each topic by drawing its state, applying one operation at a time, and redrawing. Sort your topics first into mechanisms, definitions, proofs and calculations, because each needs a different method. Then test yourself on worked traces with the notes closed. A short drawn video of each mechanism helps with the structure, but the tracing is what passes the exam.

Sort the syllabus by question type

A CS theory syllabus looks like a list of nouns: hash tables, AVL trees, paging, deadlock, TCP, normal forms. The nouns hide the fact that the questions about them come in four quite different shapes, and you revise each shape differently.

Most students revise everything as if it were a definition: highlight, reread, move on. Mechanisms are usually the largest share of marks, and they are the type rereading helps least with, because recognising a description of linear probing is nothing like doing it to five keys under time.

Mechanisms: trace the state, never describe it

A mechanism question is won by the student who can draw the state at each step. So revise mechanisms the same way.

Take one small input. Draw the structure. Apply one operation. Draw it again. Keep every intermediate picture, not just the final one, because the marks are in the intermediate steps and so are your mistakes.

This works across the syllabus:

• Data structures. Insert 5, 3, 8, 1, 4 into a binary search tree, then delete 3. Draw the tree after every operation.
• Operating systems. Run four processes through round robin with a quantum of 2 and draw the Gantt chart. Then do the same queue with shortest job first and compare waiting times.
• Memory. Run a page reference string through FIFO and LRU with three frames and mark every fault.
• Networking. Draw the three-way handshake as two vertical lines with SYN, SYN-ACK and ACK crossing between them, then add what happens when the second packet is lost.
• Databases. Take an unnormalised table and show it at first, second and third normal form, with the dependency that each step removes.

The pattern is the same each time: a picture of state, an operation, a new picture. That is also exactly what a drawn explainer video is good at, which is the one reason video earns a place in CS revision at all.

Worked example: how a hash map works

Hash maps come up in data structures modules, in algorithms courses and in nearly every coding interview, so they are worth getting cold. Here is a revision script for a video of about four minutes, written as one chapter per state change.

And three lines of narration from chapters 3 and 8, written to be spoken:

The hash function gives us a big number. We only have eight slots, so we take that number modulo eight, and the remainder is the slot.

When the table gets too full, collisions become common and lookups slow down. So the table doubles in size.

Every key has to be rehashed, because the slot depends on the size of the array. Change the size, and every key may move.

That last line is the one students miss in exams. They know a hash map resizes, but not that every entry has to be placed again, which is why a single insert can occasionally be slow.

Check your course's specifics against your notes. Java's HashMap, for example, resizes when it is 75% full by default and turns long chains into small trees, while Python's dict uses open addressing. Your module will tell you which version you are being examined on.

What a drawn video looks like for CS

Here is the hash map example above as a two minute whiteboard video made with openCanviz. It covers the put operation, the modulo step, collisions, load factor and rehashing, but not the two collision fixes side by side, so it is the four chapter short version of the nine chapter plan.

And a second example, a different kind of mechanism: a short whiteboard explainer of a classic networking question, what happens when you type a URL into a browser, which is a mechanism question with a browser, a DNS lookup, a server and a response, each drawn as it is named.

The useful thing about this format for CS is that the picture changes when the state changes. The less useful thing is that it plays at its own pace, so for revision you will pause it far more often than you watch it straight through.

Make it

1. 1

   List the mechanisms on your syllabus

   Go through the module outline and mark every topic where a question could say 'show the state after each step'. Those are your video topics. Definitions and calculations go on flashcards and past papers instead.

2. 2

   Write one small worked trace per mechanism

   Pick an input small enough to trace by hand, five keys or four processes. Write one sentence per state change, the way you would say it at a whiteboard.

3. 3

   Paste the trace into openCanviz

   Set a short target length, three to five minutes per mechanism. Use Keep my wording if you want the exact sentences you checked, and whiteboard style so each state is drawn as the narration reaches it.

4. 4

   Check every number and arrow

   Pause on each scene and compare it with your own hand trace. A drafted drawing can put a key in the wrong slot or an arrow the wrong way, and in CS that is the whole answer.

5. 5

   Test yourself on a different input

   After watching, close it and trace a new input from scratch: different keys, different processes. If you can only reproduce the example you watched, you have learned the example, not the mechanism.

The honest limit

Watching someone else trace an algorithm feels like understanding it, and it is not the same thing. You can follow a video of Dijkstra's algorithm perfectly and still freeze when handed a graph with six nodes in the exam.

So the video is the first pass, never the last. Use it to get the shape of the mechanism into your head, then put a pen in your hand and do it yourself on a new input. If you want a full protocol for that second step, see how to study from video instead of rereading your notes. If your CS course is heavy on diagrams like state machines and network stacks, how to study a diagram-heavy subject covers redrawing from memory in more detail.

Common questions

How do I revise Big O without memorising a table? Derive it from the trace. Count how many times the loop in your traced example runs as the input doubles. If you can explain why binary search halves the problem each time, you will not need the table.

Should I revise from lecture slides or the textbook? Slides for what is examinable, the textbook for the traces it works through. Slides rarely show every intermediate state, and that is what you need to practise.

What about theory of computation, automata and proofs? Automata are mechanisms: draw the machine and run a string through it one symbol at a time. Proofs are arguments: write each one from memory as five or six numbered steps and check it against the source.

Is a video worth making for every topic? No. Make them for mechanisms you find hard, usually five to ten topics per module. Definitions are faster on flashcards.

Can I use these videos for interview prep too? The data structures ones, yes. For interviews the bigger win is recording the patterns you got wrong, covered in how to make a coding interview prep video for yourself.