What interviewers see in a tutorial repository
Interviewers who look at graduate GitHub profiles recognise the usual tutorial projects quickly: the to-do app, the weather app, the chat clone, the movie list from a public API. Having them is not a problem. Everyone learns this way, and nobody expects a student to have invented a product.
The problem is that a pure follow-along gives the interviewer nothing to question. Every decision in it was made by the tutorial's author. When they ask "why did you structure the state like this?", the only true answer is "the video did", and the conversation ends there. A GitHub portfolio is useful in an interview only if it contains choices you made and can defend.
So the aim is not more polish or more repositories. It is one side project with a decision inside it. Coursework faces the same test, and the coursework-project page shows how to find the decisions inside an assignment brief.
Extend in a direction that forces a decision
Choose the extension by asking what the tutorial avoided. Tutorials keep things simple on purpose, and the simplifications are where real engineering starts. Some common examples follow.
| Tutorial version | Extension | Decision it forces |
|---|
| To-do list in browser storage | Store tasks on a server with a database | What happens when two tabs edit the same task |
| Weather app calling an API on every search | Add caching | How long a cached reading stays valid |
| Chat app for one room | Add private rooms | Who can read which messages, and where that is checked |
| Movie list loading every result | Add search and paging | Page numbers or a cursor, and what happens when data changes |
Each of these has more than one reasonable answer. That is the point. When the interviewer asks about the two-tab case, you can say: "I used last-write-wins first, then lost an edit in testing, so I added a version number and rejected stale updates." That is a real decision, a failure and a fix, from a project that started as a tutorial.
Keep the extension small enough to finish. A finished side project with one hard decision beats an abandoned rewrite.
A README that tells the truth
The README is the first thing an interviewer opens, and for a side project it does most of the explaining. Keep it short and specific.
# Task Board
Started from <tutorial name and link>. The original stored tasks in the browser.
## What I changed
- Moved storage to a small API with SQLite.
- Added a version number to each task so concurrent edits are rejected, not lost.
## Decisions
- Chose SQLite over a hosted database: one user per instance, nothing to run.
## Known limits
- No authentication. Anyone with the URL can edit.
## Running it
npm install, then npm start; tests with npm test.
The "Known limits" section matters more than it looks. It shows you know where your project stops, which is a judgement interviewers look for in graduates.
Crediting the tutorial is what makes the rest believable
The tempting move is to hide where the project came from: rename it, delete the attribution, maybe squash the history so it looks original. That is the mistake that separates a weak answer from a strong one.
Interviewers who browse a GitHub portfolio often recognise the tutorial anyway. If you have hidden it, the discovery turns a learning project into a credibility problem, and every other claim on your resume becomes doubtful. If you have credited it, the same recognition helps you, because the interviewer can see exactly which part is yours and question you on it.
Naming the source also makes your extension clearer. "The tutorial ended here; everything after this commit is mine" gives the interviewer a boundary, and a boundary is what lets them believe the claims inside it.
Tests and history around your own code
Add tests for the part you wrote, not the whole app. Three tests around the version check are worth more than thirty generated ones, because you can explain each one: this test proves a stale update is rejected, this one proves a fresh one succeeds.
Commit as you work rather than in one large upload at the end. A history showing the extension built over several sessions, with a commit where you fixed the lost-edit bug, is evidence that the work is yours. Do not rewrite it to look tidier.
Finally, pin the project on your GitHub profile and link it from your resume. Leave the other tutorial repositories public if you like. In a GitHub portfolio they show you practise, and the pinned one shows you can go further.
A tutorial project becomes worth discussing at the first decision the tutorial did not make for you. Credit the source, show that decision, and the interviewer has something real to ask about.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).