Your degree got you the interview. This is why it isn't getting you the job.

I'm in a lot of Facebook groups. Dev groups, IT groups, job groups, here in the Philippines. And there's one post I see more than any other. It goes like this:

BSIT graduate. Certificates in [list]. Looking for work. Willing to learn. Please DM.

Hundreds of them. Good people. Nobody replies.

If that's you, this isn't a post telling you off. Nobody told you this part, and it isn't your fault that they didn't. So here it is.

What the degree actually proved

Your degree proves you can learn. That's real, and it's why you got the interview.

But the person hiring isn't asking "can this person learn?" They're asking "can this person do the job on Monday?" For that, they want evidence of experience. They will take a small amount of real experience over a long list of credentials, every time.

"But I'm a fresh grad, how am I supposed to have experience?"

This is the part nobody explained. Experience doesn't mean years. It means something much more specific.

What "experience" actually means

Experience means you've been inside a project at the moment it stopped working because of something you did, and you got it working again.

That's it. That's the thing. Not the years. Not the stack. The moment.

Somebody who has had that moment a few times is someone I can put on a real codebase. Someone who hasn't is someone I have to protect the codebase from, no matter how good their grades were. That's not a judgment of the person. It's the job.

Why tutorials don't give you that

Your portfolio probably has projects in it. A todo app. An e-commerce clone. A weather dashboard. You followed the tutorial, it worked, you pushed it to GitHub.

Here's the problem: in a tutorial, every problem is already solved. Someone chose the data model so it wouldn't need to change. They picked the examples so nothing surprising would happen. You typed along and it worked, and at no point did you have to think, because the thinking was done before you arrived.

That's not a criticism of you. That's what tutorials are for. They're training wheels. But nobody takes the training wheels off, and then you're 24 with a degree and six projects that all prove the same thing: you can follow instructions.

Companies already know you can follow instructions. That's what the degree said.

The day you become hireable

Let me describe it, because I think most graduates have never been allowed to have it.

You're building something real. Not a clone. Something uncommon, where nobody has written the tutorial. You're about halfway through. And you realise the data model is wrong. A thing you thought was one-to-one is actually one-to-many. Or you need a field you didn't plan for. Or the whole shape of one table has to change.

So you write the migration. You change the schema. You run it.

And half the site stops working.

Pages that have nothing to do with the thing you changed are throwing errors. Something that worked yesterday doesn't. You don't know why. There's no video to rewind. You're going to spend the next two days reading your own code, reading error messages properly for the first time, learning what a foreign key actually does when you delete the thing it points at, and figuring out exactly what you did wrong.

When you come out the other side (and you will) you have something no tutorial can give you. You've been in the hard middle of a project and you got yourself out.

That's the day. That's the experience they mean. Everything after it is easier.

What a project like that looks like

You don't need something huge. You need something with a few specific properties:

1. Uncommon. Pick a domain where you can't find a step-by-step. A scheduling tool for your aunt's salon. An inventory system for a sari-sari store. A tracker for something you actually care about. If the tutorial exists, pick something else.
2. Real data. Not three sample rows. Enough that when you change the shape of it, it hurts a little.
3. A mid-project change. Don't plan it perfectly. You can't. Part way through, you will need to change the data model. Let that happen. Write the migration. Break it. Fix it.
4. The boring parts. Login. Deployment. Error states. A README. The last 10% is where most portfolios quietly stop, and it's exactly the 10% an employer checks.
5. One real user. Your aunt. The store. You, for a month. Somebody who will tell you it's broken.

And then: finish it. Smaller and finishable beats big and abandoned. Cut scope until it can be done by Thursday. Imperfect ships; broken doesn't.

What to put on the application instead

Stop leading with the certificate list. Lead with:

• The link. It's deployed. It works. Anyone can click it.
• The README. What it is, what it's built with, how to run it.
• Two paragraphs about what broke. What you changed, what fell over, how you found it, what you'd do differently. This is the part that gets you the interview and then gets you the job. It's the evidence that you've had the day.

An honest write-up of one hard thing you fixed is worth more than ten tutorial repos. I promise you that from the hiring side of the table.

You don't have to do this alone

That hard middle is also the part where most people quit, because at 11pm with half your site broken and no one to ask, it feels like proof you're not cut out for this. It isn't. It's the job. It just helps enormously to have someone in the room who's been there.

That's why I'm starting The Work Behind the Luck — a practical community for learning, building, and creating opportunity, with weekly Build Nights in Pampanga and online access. You bring the project. One short practical lesson, then an hour of building with people around who can unblock you when it breaks, then demos and a next step before you leave. It's free. It's not a course, and there's nothing to buy.

If you've got a half-built project and a job search that's gone quiet, you're exactly who it's for.

**Reserve a seat at the next Build Night → theworkbehindtheluck.com

And if you're further along — if you've had the day I described, more than once — your experience belongs in the room too: theworkbehindtheluck.com/get-involved

People may call the outcome luck. We focus on the work behind it.

— Mat

Mat Mozer leads a platform engineering team, builds products on the side, and interviews a lot of engineers. He founded The Work Behind the Luck to close the gap between the degree and the job.