When someone applies at our company and I review them, I don't start with the resume.

I open their GitHub. Then I look for anything they have live.

The resume comes later. Sometimes much later.

The resume can't tell me much

Not because resumes don't matter. Because for someone early in their career, a resume is mostly claims I can't check. "Proficient in React." "Built a full-stack application." Okay. So did everyone else in the pile.

Every fresher resume lists the same stack, the same college projects, and the same skill bars saying someone is 80% JavaScript, which is not a unit anything is measured in.

That isn't the candidate's fault. When you don't have much experience, there isn't much to write. But it means the resume can't tell me who you are.

A link can.

What I actually look at

The first thing I want is something live. A URL I can open and use.

That one link already tells me a lot. You got it working somewhere other than your laptop. You dealt with env variables, a database, a deploy. And most importantly, you finished something. Plenty of people start projects. Far fewer ship them. A working link puts you ahead of most of the pile before I've read a single line of your code.

Then I read the code. I'm not looking for perfect code. Nobody's side project is perfect, mine definitely aren't. I'm looking for code that looks like you understood it, not a tutorial you followed and never touched again. It's usually obvious which one I'm looking at.

What I'm not doing is counting things. Thirty repos, most of them forks and half-finished starts, tell me less than two you actually care about. A wall of green squares can be one meaningless commit a day. Stars are nice, nobody expects them.

The projects that stand out are almost never another todo app or another clone. They're the weird specific ones. Something built because your college Wi-Fi was bad, or because a tool you use every day annoyed you, or because you wanted to understand how something works. Those come with real decisions, and real decisions are what I actually want to talk about in an interview.

Where to spend your time

So if you're early in your career, here's my honest answer: not on the resume template.

Pick one or two projects. Finish them. Deploy them. Write a README that explains what it is and why it exists. Pin them on your profile so they're the first thing anyone sees, and put the links at the top of your resume so whoever reviews you doesn't have to go looking.

The resume gets you looked at. The links decide what the person looking actually thinks.