Preparing for a Project Interview
A demo video is a screen-recorded, narrated video of about two minutes.
The Reviewer's One Question
Imagine someone reviewing a project you say you built. They usually arrive with one main question in mind: does this actually work? A written description of the project cannot fully answer that question, and neither can a list of features. You may have written the most accurate description in the world, but the reviewer still has to take your word for it. A demo video is one direct way to answer the question, because it lets the reviewer watch the project run.
This article follows one idea from start to finish: a demo video is a short, narrated screen recording whose job is to show a real input going into your project and a real output coming out. Once you see that chain clearly, planning the recording becomes a matter of deciding what to show and in what order.
What a Demo Video Is
A demo video is a screen-recorded, narrated video of about two minutes. It must show your system handling a real input and producing a real output.
Each part of that definition does real work. The recording is made from the screen, so the viewer sees the project itself operating rather than a slide describing it. The narration is your voice, so the viewer hears you explain what is happening while it happens. The length of about two minutes is a deliberate limit. The content is a single chain: something real goes in, and something real comes out.
The phrase real input and real output is the center of the requirement. The reviewer needs to see the system take in something and return something that it genuinely computed.
Following One Input Through the System
The source describes the requirement as a chain. Picture the project as a box that receives something, does its work, and hands back a result. The recording must make both ends of that chain visible: the input entering the system, and the output coming out of it. If either end is hidden, the viewer has less reason to believe the project works. The diagram below shows the chain in its simplest form.
Tracing the chain for a small text tool
Suppose your project is a small tool that counts the words in a paragraph. Show how the recording makes the chain visible.
- 1Show the real input
On screen, paste a paragraph you actually wrote into the tool. The viewer sees the input entering the system, not a prepared description of it.
- 2Let the system run
Trigger the tool so it processes that exact paragraph. Keep the recording continuous enough that the viewer can see the action happen.
- 3Show the real output
Display the word count the tool returned for that paragraph. The number on screen should be the result of the processing you just showed.
- 4Narrate the link
Explain in your own voice that the number came from the paragraph you pasted. This ties both ends of the chain together.
The viewer has watched something real go in and something real come out, which is the chain the source requires.
Why a Hiring Manager Values the Recording
The source names two purposes for the video. Both explain why a short recording is worth making, and both shape what you should put into it.
Planning the Two Minutes
The length of about two minutes is a deliberate limit, and it forces choices. The source's requirement is narrow: a real input handled and a real output produced. Everything else in the video serves that chain. The example does not need a long history of how the project was designed, and it does not need to cover every feature. The timing below is a suggested plan of our own, not a figure from the source, but it shows one way to spend the two minutes while keeping the chain at the center.
- 1Open with one sentence naming the project and what it does, so the viewer knows what to expect.
- 2Bring the real input onto the screen and narrate where it came from.
- 3Let the system process that input while you explain what is happening.
- 4Display the real output and point to the part of it that answers the input.
- 5Close by restating the chain in one or two sentences.
Mistakes That Weaken a Demo
A weak demo usually fails the same test the source sets: the viewer cannot see the system take in something real and return something it computed. The comparison below contrasts a weak demo with a strong one.
Common mistake Using prepared data the system never processed in the recording
What it looks likePlaying a clip where the output is already sitting on screen before anything runs.
Why it failsThe source says a demo that quietly uses prepared data does not match the requirement, because the reviewer needs to see genuine computation.
Do this insteadEnter a real input during the recording and let the system produce the output while the camera is running.
Common mistake Reading a feature list instead of running the project
What it looks likeNarrating a list of what the project can do while the screen shows only a menu.
Why it failsThe source states that a list of features cannot settle whether the project works.
Do this insteadSpend the limited time on the single input-to-output chain and let the running system carry the explanation.
Common mistake Hiding either end of the chain
What it looks likeShowing the output but not the input it came from.
Common mistake Spending the two minutes on design history
Why it failsThe source's requirement is narrow, and history does not show the chain working.
Plan Your Own Demo
Choose a project you have built, or imagine one. Write down the single real input your demo will show entering the system, and the single real output the viewer will see produced. Then sketch the two-minute sequence in five segments, checking that the input and output both appear on screen and that nothing outside the chain takes more time than it needs.
Hints
- Name the input in concrete terms, such as a specific paragraph, file, or value you will actually enter.
- Ask whether the viewer could explain the output using only what they saw on screen.
- If a segment does not help the chain, shorten it or remove it.
Key Takeaways
- A demo video is a screen-recorded, narrated video of about two minutes that shows your system handling a real input and producing a real output.
- The reviewer's core question is whether the project works, and a demo answers it by letting them watch the project run.
- The recording must make both ends of the input-to-output chain visible, and prepared data the system never processed does not satisfy the requirement.
- A demo builds confidence that the project runs, that you built it, and that you can present it, and it can serve as the opening of the interview.
- Keep the two minutes focused on the single chain, because history and feature lists do not show the project working.