To make a coding interview prep video for yourself, start from a problem you got wrong, not from a pattern you already understand. Write down three things: the cue in the problem statement that should have told you which approach to use, the invariant that makes the approach correct, and the specific bug or wrong turn you made. Turn that into a two to three minute video with one chapter per step of a small worked trace, then rewatch it a few days later and solve a fresh problem of the same type before the narration gives the answer. A library of ten or fifteen of these, all built from your own mistakes, is worth more than hours of other people's walkthroughs.

Why your own mistakes, not someone else's walkthrough

There are thousands of good walkthrough videos of popular problems. They explain the solution clearly, in the order the solution makes sense. That is not the order you will meet the problem in an interview.

In the interview you start with a statement and a blank editor. What you need is the step that almost no walkthrough spends time on: noticing which pattern applies. And the specific way you go wrong is personal. One person always starts with a hash map when the array is sorted. Another gets the two pointers right but moves the wrong one. Another writes while left <= right when the problem needs left < right, and counts the middle element twice.

A walkthrough cannot fix your particular habit because it does not know about it. A video you make from your own wrong attempt can, because the whole video is about that habit.

This is a different job from studying patterns in general. If you are building a study plan around recognising the main patterns from scratch, how to study for a coding interview with animated patterns covers that. This post is about the repair work after you have started practising and the same mistakes keep coming back.

Keep a mistake log first

The video is built from a log entry, so the log comes first. After any problem you failed, or solved slowly, or solved only after looking at a hint, write one entry.

The "cue I missed" and "my bug" rows are the valuable ones. Everything else you could find online.

Worked example: two pointers, from a real mistake

Here is how that log entry turns into a short video. The pattern is two pointers on a sorted array: one pointer at each end, move them inward based on a comparison, stop when they meet.

The chapters, about two and a half minutes in total:

1. The cue. The statement says the array is sorted and asks for a pair. Drawn: the sentence with "sorted" and "pair" circled.
2. The setup. Array [2, 7, 11, 15], target 9. Left pointer on 2, right pointer on 15.
3. First comparison. 2 + 15 = 17, too big. Only moving right inward can make it smaller. Drawn: the right arrow sliding to 11.
4. Keep going. 2 + 11 = 13, still too big. Right moves to 7. 2 + 7 = 9, found.
5. The invariant. Why it is safe to throw away 15: it was too big even with the smallest number left, so it is too big with every number.
6. My bug. When the sum was too small I moved the right pointer. That makes the sum smaller still. Drawn: the wrong arrow, crossed out.
7. The test. "Container With Most Water: which pointer moves, and why?" Then a pause before the answer.

And the narration for chapters 5 and 6, written as you would say it to yourself:

Fifteen plus the smallest number left was still too big. So fifteen plus anything else is too big too. That is why we can drop it and never look back.

Here is what I did wrong. The sum was too small and I moved the right pointer. Moving right inward always makes the sum smaller. Too small means move left. Say it before the next problem.

Note that it uses "I". This is a video for you, and saying it in your own voice about your own mistake is what makes it stick. Nobody else needs to watch it.

Keep each video short and narrow

The temptation is to make one long video called "Two pointers" that covers every variant. Resist it. A long general video is what you can already find online.

One mistake, one video, two to three minutes, about 300 to 450 spoken words at 150 words a minute. If two problems share a pattern but you made different mistakes on them, they are two videos. You will rewatch a three minute video the morning of an interview. You will not rewatch a twenty minute one.

Make it

1. 1

   Pick one failed problem from your log

   Choose one you got wrong recently and would probably get wrong again. Fill in the cue you missed, the invariant, and your exact bug before you write anything else.

2. 2

   Write a tiny trace

   Use the smallest input that shows the idea, four to six elements. One sentence per pointer move or state change. Include the step where you went wrong, drawn as the wrong move.

3. 3

   Paste it into openCanviz with Keep my wording

   Set a target of two to three minutes and choose Keep my wording so the narration is your own sentences. Whiteboard style works well because each pointer move is drawn as it is said.

4. 4

   Check every number and arrow

   Pause on each scene and compare it with your trace. An arrow on the wrong index or a sum that does not add up teaches you the wrong thing. Fix it in the editor.

5. 5

   Swap in your own voice if you want

   The generated voice is fine, but you can replace it with your own recording. Hearing yourself say 'too small means move left' is oddly effective.

6. 6

   Rewatch, then solve the fresh problem

   Three or four days later, watch it once, pause at the final test chapter, and solve the fresh problem from your log with no hints. If you get it, the video has done its job.

What the videos will not do

They will not give you fluency at typing correct code under time. That only comes from solving problems in a plain editor with a timer running and no autocomplete, then reviewing what broke. The videos make sure the right idea arrives quickly; the typing still needs practice.

They also do not replace saying your reasoning aloud. Interviewers score communication as well as correctness, so practise narrating your approach to a friend or to an empty room. The habit of writing narration for these videos helps here, because you are already putting your reasoning into short spoken sentences.

If you are also revising the theory behind the data structures, such as what actually happens inside a hash map when it resizes, see how to revise computer science theory.

Common questions

How many of these should I make? Ten to fifteen covers most people's recurring mistakes. If you are making more than that, you are probably making them for problems you only got wrong once. Save videos for mistakes that repeat.

Should I include the code in the video? A few key lines at most, such as the loop condition and the pointer update. Full code on screen while narration reads it is hard to follow. Keep the full solution in your log.

Can I make these for system design too? Yes, the same idea works: one video per design you got stuck on, showing the component you forgot and why it was needed. The format is the same: the cue, the fix, the test.

Is it worth it compared to just solving more problems? For mistakes that repeat, yes. Solving more problems helps until you keep failing the same way, and then you need to fix the habit directly. A video takes about twenty minutes to make from a good log entry.

Do I need a clean export? No. Free videos carry a watermark, which does not matter for videos only you will watch.