Read the article
Begin by finding out how much of the project you can explain without looking. Open the code, pick any file, and explain it aloud as if to an interviewer. Where you can only say 'this came with the tutorial', mark it. Most students find the marked parts are the setup, the configuration and the library calls. Those are exactly the parts interviewers like to ask about, because they show whether you understand the tools or only the steps.
Then change something real. Not the colours or the title, but a behaviour. Add a feature the tutorial did not have. Handle an error it ignored. Replace its sample data with data from a real source and deal with what breaks. The change does not need to be large. It needs to be yours, so that when the interviewer asks what you did, you have a clear answer: 'The tutorial stored everything in memory. I added a database and had to work out how to handle two users editing the same record.'
Test it with data the tutorial never used. Tutorials are written so that everything works. Real input is messier: empty fields, very long names, a thousand rows instead of ten, a slow network. Try these. Write down what failed and how you fixed it. This gives you the best kind of interview story, one about a problem you found and solved yourself.
Know every file you would show. If your repository is on your resume, an interviewer may open it. Remove what you do not use. Write a short README that says what the project does, how to run it, and what you added. If the project started from a tutorial or another repository, say so in the README with a link. That is normal practice among developers and it protects you from looking as though you hid it.
When you are asked in the interview, answer plainly. 'I started from a course tutorial to learn the framework. Then I changed it to use real data from our college library and added search, which the tutorial did not have.' The follow-up questions will go to the search and the data, which are the parts you know best.
One caution. Colleges have rules about outside material in submitted academic work, and those rules are separate from what employers expect. Follow your college's rules for anything you submit, and ask your guide if you are unsure. For interviews, the principle is simple: say where it came from, and show what you understand and what you added.