I got my first job offer by talking about my users, not React. Here's what I'd check before accepting one now.

I graduated in September 2025, and on 29 September I got my first job offer. It didn't come from knowing React better than anyone else. It came from having built things that real people used. And the company that made the offer, small and still in its early stages, turned out to matter far more than the salary did.

That's one company and one year, so treat this as one data point. It's a specific one, though.

After graduation, I applied everywhere. LinkedIn, Indeed, whichever platform had a jobs page. Once you graduate, there's a clock running. Part of it is your own, and part of it is your parents asking what comes next.

The application that worked was the least planned one I sent. One night I was about to sleep when I got a sudden urge to apply for something. I opened LinkedIn Jobs and applied to the first post I saw. I didn't even read the description. All I noticed was the title: mid-level software engineer. I was a fresh graduate.

About a week later, the same company messaged me. I said yes to the interview straight away, without researching the company at all. My only preparation was going back over everything I'd built so far and revising my core concepts, because I assumed that's what they'd test.

What did the interview actually ask about?

I expected React, Node.js, and Next.js questions. Definitions, the kind of thing you can revise the night before. That isn't what happened.

They asked about my real projects, the ones that were live and had actual users. Why I'd built them. How I decided what to build. What users said once they started using them, and what I did about it.

It was clear the textbook definitions weren't the point. Anyone can read those. What they wanted was someone who understood how real users want things to work and what real feedback looks like. For them, that experience counted for more than anything else I could have said.

Looking back, it makes sense for a company at their stage. A small team doesn't have room for someone who needs every requirement spelled out. They needed someone who had already seen what happens when a product meets its users.

Why did live users count for more than definitions?

I'm not saying core concepts don't matter. I revised them for that interview, and I'd do it again. But they're the part you can pick up quickly. What takes longer is understanding problems.

During university, I did part-time jobs alongside my degree and built products that went live. That's where I learned the things no course taught me:

• How to work out what a user actually wants, which isn't always what they say.
• How to research a problem I'd never seen before and find a way through it.
• How to resolve issues when real people are waiting on the fix.
• How to make the experience better for the people actually using it.

None of that fits on a CV as a single line. It shows up in an interview when someone asks "and then what happened?" and you have a real answer. That's what landed me the job. Not a certificate or a list of frameworks, but the experience from those part-time jobs and the products I'd built that were live.

Ahmad wrote about the same thing from the interviewer's chair in " Why capable candidates got turned down. The ones who struggled had claimed experience they couldn't talk through. Real users give you something real to talk through.

Should you accept your first job offer within a week?

I did, more or less without thinking. Once the company reached out, the whole process moved fast, and I didn't slow it down. The pay was reasonable for the market at the time, and I wanted to start working.

It worked out. I'd be lying if I called that judgement, though. It was luck, and trust in Allah. I ended up somewhere flexible, with good people, right at the start of my career.

I wouldn't count on that luck twice. Before accepting an offer now, I'd look properly at the culture first. In a toxic culture you might not get much out of your first job, however good the pay looks. Before signing, I'd want to know:

1. Who I'd actually be working with day to day, and whether I could talk to them first.
2. How the team treats mistakes, especially a junior's.
3. What "flexible" really means there, rather than taking the word on trust.

None of these need a formal meeting. Asking them in the interview is fine. How they answer tells you almost as much as what they say.

What did the first year turn into?

Exactly one year after joining, my salary was double what it was on the day I started. Same company, same people who took a chance on a fresh graduate who'd applied to a mid-level post half asleep.

A first job is important. With some luck and the right people around you, you can grow a lot in it. Mine became far more useful to me than I expected when I clicked apply that night.

I'll be clear about the limits of this. I only have one first job to compare against, and I don't know what a bigger, better-known company would have given me, because I didn't take that path. What I can say is that a company I'd never heard of, still in its early stages, was a good place to start.

What would I tell someone graduating this year?

• Build something real people use. Live users teach you things a tutorial project can't, and they give an interviewer something to dig into. If you haven't built anything yet, start with one small project.
• Don't filter yourself out by title. I applied to a mid-level role as a fresh graduate, and it got me an interview.
• Revise your concepts, but prepare to talk about decisions. Why you built something, who used it, and what you changed after they told you what was wrong.
• Don't dismiss a company because you haven't heard of it. Mine wasn't big or famous, and it was the right place for me to start.
• Check the culture before you sign. A good first job offer is about the people as much as the pay.