What I'd Tell a Junior Developer Starting Out Right Now

I’ve seen a few too many headlines this year about entry-level coding jobs disappearing, junior hiring softening, “the death of the entry-level developer” — pick your framing. I’m not going to pretend I know exactly how bad the junior job market is right now, because I’m not the one hiring, and I don’t want to add another confident hot take to a pile already written by people who also aren’t hiring. What I can actually do is look back honestly at my own path — Android dev, a stretch of fullstack freelance work, now a mixed bag of my own projects — and think about which parts of it still hold up, and what I’d genuinely tell someone starting from zero right now.

The part that hasn’t changed: nobody hires you for potential alone, they hire you for evidence. When I was breaking in, that evidence was a handful of small Android apps that actually worked, that I could talk through in detail, that showed I’d made real decisions and hit real problems. Not a portfolio full of tutorials I’d followed, but two or three things I’d built myself and could explain the ugly edge cases in, because I’d actually run into them. That requirement hasn’t gone away with AI tools around — if anything it’s gotten sharper, because now anyone can produce a portfolio that looks finished in a weekend with an agent doing most of the typing. The evidence that actually separates candidates now isn’t “did you build something,” it’s “can you explain why you built it this way, and what you’d change.” A much higher bar to fake than a working demo used to be.

What’s genuinely different: the first rung of the ladder is narrower. A lot of what used to be junior-level work — routine CRUD endpoints, wiring up a form, fixing well-scoped bugs off a ticket queue — is exactly the kind of well-defined, bounded task agentic tools already handle well with a senior directing them. That’s real, and I’m not going to pretend otherwise just to sound encouraging. If your plan for breaking in was “get hired to do the boring, repetitive tasks while I learn,” that specific on-ramp is narrower now, because a lot of that work has shifted to being the senior’s job to direct an agent through rather than a junior’s job to grind by hand.

What I’d actually tell someone starting now: don’t try to compete with the agent, learn to be the person directing it better than most seniors currently can. That sounds like consultant-speak, so let me make it concrete. Most of the mid-career and senior developers I know — myself included, some days — are still bad at using agentic tools well. We over-trust output that deserves a closer read, under-specify context and then blame the model for guessing wrong, don’t break work into chunks small enough to actually review. Someone starting fresh right now, with no ingrained habits from the pre-agent era, has a real shot at building good agent-collaboration habits from day one instead of unlearning bad ones later. Not a consolation prize for missing the old on-ramp — a genuinely different and valuable skill that most of the industry, senior people included, hasn’t actually built yet.

Two more things I think matter, neither of them new exactly, just more important now. First: build things that require you to own a decision, not just complete a task. A tutorial-following project proves you can follow instructions, which an agent can already do better than most juniors. A project where you had to decide the data model, pick between two reasonable architectures and justify it, or debug something with no clear tutorial answer — that proves you can reason about tradeoffs under uncertainty, the actual skill hiring managers are screening for even when a job posting can’t articulate it that clearly.

Second: get comfortable being the person who reads carefully, not just the person who ships fast. Everyone’s optimizing for velocity because the tools make velocity cheap. The junior developer who catches the subtle bug in a diff, who asks “wait, why did it do it this way” instead of accepting output at face value, who treats review as a real skill instead of a formality — that person is rare, valuable, and immediately useful on a team drowning in fast but unreviewed output. I didn’t fully appreciate this myself until I was the one getting called in to clean up codebases nobody had reviewed. I’d tell someone starting now to build that muscle on purpose, early, instead of learning it the hard way years in like I did.

One practical thing I’d also say: don’t skip the fundamentals just to move faster with tooling. I’ve talked to a couple of people breaking in right now who can produce a working feature with an agent’s help but genuinely can’t explain what the generated SQL query is doing, or why a particular React hook needed an entry in its dependency array. That’s a trap — it feels like progress, because you are shipping things — while quietly building a ceiling on how far you can go, since every layer you don’t understand is a layer you can’t debug, question, or improve later. I’m not saying learn everything the hard way before touching a tool. Use the tool, then actually read what it gave you until you could’ve written something close to it yourself. That habit alone would have saved me months when I was starting out, tools or no tools.

The honest answer to “is it harder to break in right now” is probably yes, specifically in the way the traditional lowest rung got narrower. But the skills that actually made me useful once I was in — owning decisions, reading carefully, being able to explain my choices under questioning — were never really about grinding junior tickets in the first place. Those skills are just as learnable now as when I started, maybe more visibly valuable, because so much of the industry is currently bad at exactly that.