How to get programming experience when you can’t find a job?
Question
Answer
Hello Torb,
I keep getting versions of your question in my inbox: “No one hires juniors, what do I do?” Some days it feels true, other days I see three new boot-camp grads land roles in a week. Markets swing, regions differ, visa rules bite — so if things look grim where you are, that doesn’t mean it’s universal (or permanent). I can’t promise miracles, but I can share what’s worked — and where I’ve face-planted — over the past fifteen-odd years.
First trick: give yourself a job for the next six months. Not a cute weekend hack, a proper full-time gig. Clock in at 9, clock out whenever your brain melts. The mandate is simple: build, break, fix, repeat. Every crash you hunt down is worth +1 XP. Will six months be enough? Maybe, maybe not (I needed closer to two years before anyone paid me to code). But the structure helps; drifting rarely does.
Pick a project with teeth. A money-tracking SaaS, a multiplayer game lobby, an inventory system for your friend’s bike shop — anything that forces you into databases, auth, error handling, the works. That said, don’t disappear into a solo mega-build for half a year and expect recruiters to faint from admiration. Plenty of companies care more about teamwork and self-motivation than a thousand-line side project. So mix in collaboration: open a PR on a library you already use; join a weekend hackathon; grab a “good first issue” in an established repo. The ability to discuss code reviews and merge conflicts sometimes trumps a slick demo.
While you’re coding, treat GitHub as the classroom. Read the source of every dependency you import (well, at least skim — some packages are rabbit holes). Ask why the maintainer chose that pattern, then experiment by changing it locally. I still remember the first time I swapped out a function in Express.js and broke half the middleware — painful, yes, but the internal model I built that day stuck far longer than any tutorial.
Keep notes. Two bullet points per day is enough: what you tried, what exploded, what finally clicked. Future-you will thank present-you during interviews. Plus, that running log exposes gaps — if you’ve written “figure out SQL indexes” four days in a row, it’s time for a deep dive. (I could be wrong, but I suspect most junior devs underestimate how often seniors stop and RTFM.)
🏄 Keep your algorithms and data structures knowledge fresh. Watch some youtube videos about practical use of the concepts that you learned as part of your CS degree.
Once the first app ships — ships meaning an actual user can log in and click around without the server catching fire — start another. Harder scope, unfamiliar stack. Or (my preference) grab a small paid contract, even if it barely covers coffee. External deadlines and grumpy customers surface edge-cases side projects never do. Bug-bounty programs work, too; nothing sharpens security chops like a real CVE staring back at you.
Open source is the obvious parallel track. I’ve tossed more than a few half-baked libraries into the void, and the feedback has been brutal in the best way. Strangers pointing out your lazy null checks will teach you defensive coding faster than any course. You also pick up the social layer: asynchronous discussions, issue triage, the art of disagreeing without a flame-war (still working on that one).
All of this — projects, logs, tiny PRs, paid scraps of work — compounds. You’re not just padding a portfolio; you’re wiring the reflexes that let you debug production at 3 AM. Will a single recruiter see every commit? Probably not. But you will, and the confidence that comes from knowing you’ve wrestled real problems is hard to fake.
Quick story before I sign off: I spent an entire summer with three different C textbooks open on my desk. Nothing compiled. I rewrote the same pointer arithmetic until the pages curled. On week twelve — I wish this were a cleaner Hollywood moment, but it was more of a shrug — the code finally built, though it didn’t fully fix things. That grind taught me more about persistence than any success story I could give you now.
Collect those +1’s. They add up.
Cheers,
Vadim
More questions from users:
Worried your codebase might be full of AI slop?
I've been reviewing code for 15 years. Let me take a look at yours and tell you honestly what's built to last and what isn't.
Learn about the AI Audit →No-Bullshit CTO Guide
268 pages of practical advice for CTOs and tech leads. Everything I know about building teams, scaling technology, and being a good technical founder — compiled into a printable PDF.
Get the guide →
2 Comments
When I started, I threw myself into building complex stuff. It was tough but taught me a lot. Along the way, I made sure to meet other devs at meetups and online forums. Those connections got me my first job and helped me learn even faster.
Building real-world projects early on shaped my skills more than anything. I explored new libraries on GitHub, understanding their workings. This hands-on approach enriched my problem-solving abilities. Sharing my progress on a personal site made interviews more engaging, allowing me to present concrete evidence of my growth. New developers should consider this strategy to enhance their visibility and appeal to potential employers.