Six months ago I had $0 in the bank earmarked for this, no computer science degree, and a browser tab open on "how to become a developer." Last week I signed my first dev job offer.
I'm not writing this to sell you a bootcamp or a course — I bought neither. I'm writing it because almost everything I was told about how to get that first job turned out to be a distraction from the one thing that actually worked.
The thing that worked wasn't learning more. It was shipping.
What I thought the job was (and what it actually is)
For the first six weeks I did what everyone tells you to do. I watched courses. I did the exercises. I rewrote the todo app four times in four frameworks. I started — and this is the part that stings — a LeetCode streak, because someone on a forum said that's what "real" developers grind.
I was busy every single day and I was getting nowhere. Here's why, and it took me embarrassingly long to see it:
The rule: tutorials teach you to follow. The job is to decide. You can finish a hundred tutorials and still have never once made a real decision — what to build, what to cut, what to do when the thing just breaks and there's no "next lesson" button.
Everything in a course is scoped so you can't fail. The requirements are fixed, the answer exists, and the happy path is paved. None of that is true on the job. The job is ambiguous requirements, a half-working API, and a user doing something you never imagined. I had spent six weeks practicing a game that nobody actually hires for.
So I quit the tutorials and made a rule: I only build things a stranger could use.
The portfolio that got me hired (and the one that didn't)
My first "portfolio" was three repos: the todo app, a weather dashboard, and a half-finished clone of a site everyone clones. Standard. Dead on arrival. No recruiter has ever once opened a weather app clone and felt anything.
The portfolio that got me interviews was three completely different things:
- A small booking tool for my cousin's salon — real bookings, real customers, real "it broke on Saturday and I had to fix it before they opened."
- An inventory tracker for a local shop that was running on a paper notebook.
- A tiny invoicing app I built for myself and then three freelancers started using.
None of them are impressive as code. What made them work in interviews is that every one of them had a user who was not me, and a story about something going wrong in production and me fixing it.
The rule: nobody hiring a junior asks what you've learned. They ask what you've shipped that a stranger actually used. One of those is checkable. The other is a vibe.
The first time I said "a real customer double-booked because of a race condition in my code and here's how I found it and fixed it," I watched the interviewer's posture change. That sentence did more than my entire "skills" list. It's the difference between I studied this and this happened to me.
How I shipped real apps without a team (the uncomfortable part)
Here's the part some people won't like, and I'd rather say it straight than hide it: I could not have shipped three real, running apps in six months by hand-writing every line while also learning the fundamentals. There aren't enough hours.
What let me move at that pace was treating "building the app" and "understanding the app" as two separate jobs. I'd get a working, deployed version standing up fast — real database, real users, real URL — and then I'd go read it, break it, and rebuild the parts I didn't understand. Shipping first, understanding second, is backwards from how courses teach it, and it's the only order that kept me motivated, because a thing that's live is a thing you can't lie to yourself about.
The rule: a deployed app with one real user teaches you more in a week than a tutorial does in a month — because the user does the thing you swore nobody would do, and now it's your problem, not the instructor's.
The point was never "don't learn the fundamentals." I learned more fundamentals debugging a live booking race than I ever did in a course. The point is the live app was the curriculum, and it set its own syllabus in the exact order I needed it.
The six months, honestly (the shape, not fake precision)
I won't hand you a fake day-by-day plan, because mine wasn't clean and yours won't be either. The shape is the lesson:
- Weeks 1–6: tutorials and LeetCode. Felt productive. Was not. This is the part I'd delete if I could.
- Weeks 7–14: first real app (the booking tool). Shipped it ugly, broke it constantly, fixed it in public. Learned more here than everywhere else combined.
- Weeks 15–20: two more real apps, each faster than the last, each with a real user I could point an interviewer at.
- Weeks 21–26: applied. Got rejected plenty. But every callback traced back to the same thing — a real app with a real user and a real war story, not a certificate.
I counted later: the interviews I got came almost entirely from the three real apps. The tutorials, the streak, the certificates I'd half-collected — not one of them ever came up in a room where someone decided whether to hire me.
The rule: a portfolio of three real apps with real users beats a shelf of certificates in the room where they actually decide. The certificate says you attended. The shipped app says you can finish.
If you're where I was six months ago
You don't need my exact path. You need to stop doing the thing that only feels like progress and start doing the thing that's checkable:
- Pick something one real person actually needs. Not a clone. Your aunt's bookings, your own invoices, your team's spreadsheet that should be an app. The smaller and more real, the better.
- Ship it before it's good. A live URL with one user beats a perfect repo with none. Deploy embarrassingly early.
- Then go understand what you shipped. Break it on purpose. Read your own code like a stranger wrote it. That's where the fundamentals finally stick.
- Keep the war stories. Every "it broke and I fixed it" is a sentence that will out-perform your entire skills list in an interview.
The degree gets you past some filters. I won't pretend otherwise. But the thing that gets you hired — the thing in the room when a human decides — is evidence that you can take something ambiguous and make it real and keep it running when it breaks.
The rule: the fastest way to look like a senior while you're still a junior is to have already shipped something that survived contact with a real user. You can't fake that, and you don't need a degree to have it.
Top comments (1)
The "every callback traced back to the real apps" part is the whole lesson here.
From the resume side, this is exactly what I see too: "Built a salon booking tool used by a real business — fixed a double-booking race condition" beats a list of 15 frameworks every time. Real users + one real problem you solved = the strongest bullet you can have.
Saving this for anyone who asks me "which course should I take?"