Turn a college project into evidence a recruiter can check

If you are a student, your resume probably has a section called "Projects" with three lines in it. Each line names a project and a list of technologies. "E-commerce website — React, Node, MongoDB." "Attendance system — Python, OpenCV."

To a recruiter, those lines look almost identical to everyone else's. Not because your work was the same, but because the lines don't say what you did, or how well.

The good news: the evidence usually already exists. It is in your repository, your report, your demo video and your memory of the hard parts. It just hasn't been written down in a form someone else can check.

What makes evidence checkable

A line is checkable when a stranger could confirm it without taking your word for it. That usually needs three things:

1. What you did, in your own role, not the team's.
2. Something concrete, like a feature, a number, a decision, or a problem you solved.
3. Where to look: a link to the code, the live app, the report or the demo.

"Built an e-commerce website using React" fails on all three. Compare:

Built the cart and checkout in React for our 3-person final-year project; added a saved-cart feature so items survive a page refresh. Code and demo linked.

Nothing in that line is impressive on its own. But every part of it can be checked. That makes it more believable than a longer list of tools.

Step 1: Pick the projects that show different skills

You don't need every project. Pick two or three that, together, cover different kinds of work. For example, one where you built a user-facing feature, one where you worked with data, and one where you worked with a team or a real user.

Step 2: Write down what you personally did

Group projects are where most students undersell themselves, or oversell the team's work. Be precise:

• "I designed the database schema and wrote the API for bookings."
• "I did the user interviews and turned them into the first three screens."
• "I set up the deployment so the app stayed online during the demo."

If you are not sure, look at your commits or your part of the report. That is your evidence.

Step 3: Find one concrete detail per project

It does not need to be a big number. Good details include:

• a constraint you worked under ("ran on the college's shared server with 1 GB of memory")
• a problem you solved ("fixed the login loop that logged users out on refresh")
• a result you can show ("the attendance check now takes one photo instead of a roll call")
• a real user ("used by our hostel's mess committee for a semester")

Only use numbers you actually measured. If you didn't measure it, describe it instead. "Faster" with a reason is better than an invented "40% faster".

Step 4: Make it easy to look

Put the link right next to the line: GitHub, a deployed app, a Lovable project, a short demo video, or the PDF of your report. Make sure the repository's README says what the project is and what you did. Many recruiters will open one link. Make it the one that shows your best work.

Step 5: Connect it to the roles you want

Once you have three solid project lines, look at a posting for a role you want. Which requirements do your projects actually cover? Which are partly covered? Which are real gaps? (We wrote about reading a posting this way.)

You'll often find that your projects cover more than you thought, just not in the words the posting uses. That is a reason to describe your work clearly, not to copy the posting's words.

Where Tayyari helps

Tayyari reads your resume, your GitHub and any public link you share, like a portfolio or a Lovable project. It turns what it finds into a skill graph where every skill points back to the line that proves it. For students, that usually means seeing, for the first time, which of your projects already count as evidence, and which roles they get you closer to.

If you'd like to see your own projects that way, map your skills in the app. Seeing your gaps is free.