Checkr surveyed 3,000 US hiring managers in 2025 and found something that should change how you present your work: 35 percent confirmed that someone other than the listed applicant had taken part in a virtual interview, 31 percent said they had personally interviewed a candidate using a fake identity, and the single most-cited form of deception was AI-generated fake work samples and portfolios. Read that last one twice, because it is aimed squarely at you. The artefact you were told to build — the GitHub profile, the deployed demo, the portfolio site — is now the artefact employers trust least. The fastest way to get that trust back is to be on camera, in your own voice, explaining your own code.
Key takeaways
- A repository link proves a repository exists. It no longer proves you wrote it — 6 in 10 managers now suspect candidates of misrepresenting themselves with AI.
- A walkthrough is a code walkthrough, not a product demo. Showing the app running proves less than explaining one decision inside it.
- Five to eight minutes, one take, screen recording plus your voice. Editing is not the point and polish can hurt you.
- The question that carries the most weight is the one almost nobody answers on camera: what did you try first, and why did you throw it away?
Why your proof stopped working
For a decade the advice was consistent and correct: don’t tell them, show them. Build things, put them on GitHub, link the repo. That advice worked because the artefact was expensive to fake. It isn’t any more. When a tool can generate a plausible project, a README and a commit history in an afternoon, the artefact stops being evidence and becomes a claim like any other line on a CV.
The people reading your application already know this. HackerRank’s 2025 Developer Skills Report, built on a global survey of more than 13,000 developers and engineering managers alongside platform data, found that 74 percent of developers were struggling to land jobs even while hiring was up — a gap the report attributes not to demand but to how companies evaluate. Employers are not short of candidates. They are short of ways to tell candidates apart. Every filter they used to rely on has been commoditised at roughly the same moment.
What a walkthrough proves that a repo cannot
Three things, in order of how much they matter.
Authorship. Someone who wrote the code can scroll to any file and say what it does and why it is there. Someone who did not will describe the feature rather than the file. This difference is obvious within ninety seconds to anyone who has written software, and it cannot be faked by a person who is reading rather than remembering.
Judgement. Working code shows the decision you settled on. It never shows the three you rejected, and the rejected ones are where your engineering judgement actually lives. “I used Postgres” is a fact. “I started with Mongo because the tutorial did, then hit a bill-splitting bug that needed a transaction, so I moved” is a demonstration of how you think — and it is the part of the recording a founder will remember an hour later.
Communication. A remote internship is mostly writing and talking about work that other people cannot see you doing. A hiring manager who watches you explain a module for six minutes has directly observed the skill they are most worried about, rather than inferring it from a bullet point that says “strong communication skills”.
The mistake almost everyone makes
Asked for a walkthrough, most students record a product demo: here is the login page, here is the dashboard, here is the settings screen. It feels like the safe choice because nothing can go wrong — you are describing what is on screen.
That is exactly the problem. A demo is a tour of an interface — the part of your project a screenshot already communicates — and it is the one format an impostor can deliver perfectly, because it requires no knowledge of the code underneath.
Open the editor instead. Scroll through the files you wrote. Stop on the one that was hard and explain what made it hard. Thirty seconds of the app running, at the start or the end, is plenty of context — the other five minutes belong to the code.
The six-minute playbook
- Pick the project you can defend, not the biggest one. A small tool you wrote every line of beats a large group project where you owned two files.
- Open with one sentence of what and who. “This splits hostel mess bills for about 240 students across two hostels.” No background, no course context, no thanking anyone.
- Show it running for thirty seconds. Just enough that the code has a shape to attach to.
- Go to the hard part and stay there. One file, one function, one problem. Depth on a single decision reads as competence; a tour of ten files reads as a tour.
- Say what you tried first and why you abandoned it. This is the highest-signal sentence in the entire recording, and it is the one almost nobody says out loud.
- Name what is still broken. “There is no retry on the payment webhook and I know it will bite” builds more trust than any claim of completeness, because it proves you can assess your own work.
- Say plainly what you wrote and what you didn’t. If a library, a teammate or an AI tool did a section, say so and say what you changed. Volunteering it costs you nothing; being caught omitting it costs you everything.
- Record once, upload unlisted, move on. One take with a stumble beats a fourth attempt that sounds recited. Put the link on your profile where an employer will actually find it.
Why this is worth an evening
The asymmetry is what makes this worth an evening. Almost every student applying alongside you has a GitHub link; almost none has a recording of themselves explaining a design decision. You are competing on whether a founder, halfway down a long list, finds six minutes of evidence that you are real and that you think.
We have written the other half of this argument from the employer’s side — why engineering leaders now find skills harder to assess, and what a short walkthrough replaces. It is the same thesis pointed the other way: the people hiring you have lost their old filters and are actively looking for a new one. Handing them the artefact they are missing is the cheapest advantage available to a student right now.
FAQ
How long should a project walkthrough video be?
Five to eight minutes for one project. Long enough to open the code, explain a real decision and show the thing running; short enough that a founder screening a list will finish it. If you cannot do it in eight minutes, you are usually describing everything you built rather than the one part that was hard.
Should I demo the product or walk through the code?
The code. A demo shows that something runs, which a screenshot also shows. A code walkthrough shows how you think — why this data model, why this library, what you threw away. Show the running app briefly for context, then spend the time in the editor.
Does it need editing or good production quality?
No. Screen recording plus your voice is the whole format. Nobody is scoring your lighting, and heavy editing can work against you — the point is to sound like a person reasoning in real time, not reciting a script.
Tierones matches students from IITs, NITs and IIITs with startups that hire on proof of work rather than CVs. Create your profile with your .ac.in email, add your GitHub, and put your walkthrough link where an employer will see it.