To make a video explaining a computer science algorithm, pick a small concrete input, trace the algorithm on it by hand, and write one scene per state change: the variables before, the comparison made, the variables after. A binary search on 16 sorted numbers takes four or five scenes of search plus an opening and a closing, about two minutes of narration. Draw the data structure once and keep it in the same place on screen so only the pointers and highlights move. Finish with one scene on cost (why it is logarithmic) and one on the edge case people get wrong. Then check every value in every scene against your hand trace, because a drawing that shows the wrong midpoint teaches the wrong algorithm.

Trace, do not describe

Most algorithm explanations fail the same way. They say "binary search repeatedly halves the search space until it finds the target", which is true, and which a viewer can repeat without being able to run the algorithm on paper. Exams and interviews ask you to run it on paper.

The fix is a trace: a table of the algorithm's variables at every step, on one specific input. The trace is the explanation. The narration is the trace read aloud with a reason attached to each row, and the drawing is the trace made visible. If you write the trace first, the script and the scene list almost write themselves.

This is the same idea behind revising CS theory by tracing state, covered in how to revise computer science theory. Here the trace becomes something you hand in or post.

Worked example: binary search on 16 numbers

Take this sorted array, indexed from 0 to 15:

[3, 8, 11, 15, 19, 22, 27, 31, 37, 42, 46, 53, 58, 64, 71, 80]

Search for 37. Keep two pointers, lo and hi, and compute mid = (lo + hi) // 2 (integer division).

Four comparisons for sixteen numbers. Now search for 40, which is not there. Steps 1 to 3 are the same, with 42 still greater than 40. Step 4 compares 37, which is less than 40, so lo becomes 9. Now lo is 9 and hi is 8, the pointers have crossed, and the search stops: not found. That fifth row is the one students forget, and it deserves its own scene.

The scene list

1. The problem. A sorted array of 16 numbers and a target. Checking one by one could take 16 looks.
2. The setup. lo under index 0, hi under index 15.
3. Step 1. Midpoint 7 lights up, value 31. Too small, so everything from 0 to 7 greys out.
4. Step 2. Midpoint 11, value 53. Too big, 11 to 15 grey out.
5. Step 3. Midpoint 9, value 42. Too big, 9 and 10 grey out.
6. Step 4. One cell left, index 8, value 37. Found.
7. The miss. The same search for 40, ending with the pointers crossing.
8. The cost. Each step halves what is left: 16, 8, 4, 2, 1. That is why it takes at most 5 comparisons for 16 items and at most 20 for a million.
9. The catch. The array must be sorted. On unsorted data, binary search returns wrong answers without any error.

Here is the narration for scene 3, in full:

"We start in the middle. Index seven holds thirty-one. Thirty-one is smaller than thirty-seven, and because the array is sorted, everything to the left of it is smaller too. So we can throw away indexes zero to seven in one move. lo jumps to eight."

That is 45 words, about 20 seconds. It states the value, the comparison, the reason the discard is safe, and the new state. Every step scene follows the same four beats, and the repetition is a feature: by step 3 the viewer is predicting the next move, which is the point at which they understand the algorithm.

The same method on a graph: Dijkstra in four rows

Trace-first works for any algorithm. Here is Dijkstra's shortest paths on a four-node graph, starting from A. Edges: A to B costs 4, A to C costs 1, C to B costs 2, B to D costs 1, C to D costs 5.

The interesting scene is row three: B's distance drops from 4 to 3 because a longer-looking route with two cheap edges beats one expensive edge. That is the moment the algorithm earns its name, so the drawing should cross out the 4 and write the 3 beside B, visibly.

What to draw for each kind of algorithm

The rule in every row is the same: the structure stays still and only state changes. A video where the array is redrawn in a new place every scene forces the viewer to re-find everything, and they stop following by scene four. There is more on building one diagram up across scenes in how to make a diagram animate step by step.

The edge cases that make it a good video

A video that only shows the happy path is a demo. The scenes that show understanding are the edges.

• Not found. For binary search, the pointers crossing.
• Off by one. hi = mid - 1 versus hi = mid. Pick the version your course uses and say why the other one can loop forever.
• Overflow. In languages with fixed-size integers, (lo + hi) / 2 can overflow on huge arrays, which is why many libraries write lo + (hi - lo) / 2. A bug of exactly this kind sat in Java's standard library binary search for years before it was reported in 2006.
• Negative edges. Dijkstra gives wrong answers with negative edge weights. One scene with a small counterexample is worth a paragraph of warning.

Make it

1. 1

   Choose a small input and trace it by hand

   Pick 8 to 16 items, or 4 to 6 graph nodes. Write the full state table on paper, including one case that fails or does not find the target.

2. 2

   Write one paragraph per row of the trace

   Each paragraph gives the current state, the comparison, the reason for the decision, and the new state. Say every value aloud.

3. 3

   Add the cost and the edge case

   One paragraph on why the running time is what it is, using your actual numbers, and one on the case that breaks a careless version.

4. 4

   Paste it into openCanviz and keep your wording

   Choose Keep my wording so the narration says exactly your numbers, set a length of two to four minutes, and pick whiteboard so the structure is drawn once and marked up as the steps go.

5. 5

   Check every scene against your trace

   Pause on each scene and compare pointers, highlighted cells and distance labels with your table. One wrong midpoint ruins the explanation. Fix it in the editor.

6. 6

   Watch it and predict

   Pause before each step and say what happens next. If you can, the video works. If a classmate can, it really works.

Handing it in

If the video is coursework, say what you used to make it and check the policy on AI tools. The trace and the script are your work and show your understanding; a tool drawing and narrating them is closer to using a diagram editor. If your assignment is to explain your own implementation rather than a textbook algorithm, the approach is different and is in how to make a video explaining your code for a class submission.

Common questions

Should I show the code? Briefly, at the end, once the viewer has seen the algorithm run. Code first means the viewer reads syntax instead of watching logic. Five to ten lines on one scene is plenty; point at each line as you mention it.

How large should the example be? Big enough that the algorithm does at least three meaningful steps, small enough that every value fits legibly on screen. Sixteen cells for an array, four to six nodes for a graph.

How long should an algorithm video be? Two to four minutes for one algorithm. At 150 spoken words a minute, that is 300 to 600 words, enough for a full trace, the cost and one edge case.

Do I need Big-O notation? Use it once, after the viewer has seen the halving. "Each step halves what is left, so the number of steps grows with log of n" lands better than starting with O(log n).

Can the same video work for interview prep? Yes, though interview practice needs you to produce the trace without the video. The approach for that is in how to study for a coding interview with animated patterns.