A few months ago, a bunch of students approached me at a conference and asked, "Do you hire juniors?" We didn’t at that time. Then they asked, "What would you advise us to do to land our first job in software engineering?"
I have to admit, it wasn’t an easy question to answer.
That’s why I sat down and wrote this piece. It’s for junior engineers wannabe. But if you are an engineering leader who hasn’t touched code in the last few years, this one's for you too. Now’s a great time to (re)start your career and start building.
Early Days of My Professional Career
I’ve been building software for almost 20 years now. Yet I still remember how much I struggled in the first years of my career. Even though I made some money freelancing in HTML and PHP, it was hard for me to get a real job as a junior software engineer.
“Learn git”, “learn Java”, “do something in Eclipse” (a go-to IDE back then) - those were the answers I got when trying to get some help. Not saying this wasn’t useful, but it wasn’t enough to get started with my first real job. The reality is that Git at home was totally different from Git at work. Same with Java, developing projects in the IDE, and the way things are deployed to production.
What helped, though, was just building stuff. When I got my first Android phone, I started creating new apps - something I can see, touch, and use. It wasn’t an easy journey - learning and experimenting took me months. But along the way, I realized that mastering IDEs, programming languages, and Git wasn’t a thing on its own. It was a byproduct of the problems I faced over time.
--
A decade later, I ran multiple internship programs and faced this challenge from the opposite side. How do you hire fresh talent with the potential to grow but almost no professional experience?
Today I know each internship was very successful. Everyone who joined stayed with the company for many years, growing from junior to regular to senior roles. Today, each of them either leads teams of experts or is one of them.
For each of the internship, we got up to one hundred candidates, while we could hire two or three. What was the key for the selection back then? Programming language? Maybe the basics, to see if they knew the building blocks.
What mattered most was a builder-and-problem-solver mindset. We invited only those who did something practical, like building a side project or contributing to open source.
“What problems did you face?”, “Why this approach, not that?” What we validated wasn’t really code, but something higher-level. Do they understand application lifecycle? Do they decompose? What are the patterns they used - and why them (e.g., app-scope singleton vs. per-screen instance - both could be the right approach, but did they reason around that)? Do they use existing solutions or reinvent the wheel (like writing an HTTP client from scratch)?
The builder mindset was critical here. Technicalities are something we can catch up on along the journey, but the will to build something rather than just writing the code is an asset people do or don’t have.
Fast forward to today. Plain programming language, IDEs, code itself - It seems that none of these matters anymore. Even framework selection becomes secondary. Within 30 minutes, we can prototype an app without leaving the ChatGPT’s landing page. In a few hours, we will build a full-stack app in Claude Code without even opening an IDE.
And this isn’t just a vibe. Stanford’s Digital Economy Lab found that software developers aged 22 to 25 are down nearly 20% in employment from their late-2022 peak. Over the same window, developers 30 and up in the same AI-exposed roles grew 6 to 12%. The ladder isn’t shrinking. It’s being pulled up behind the people already standing on it.
A recent BairesDev survey of over 1,500 developers across 77 countries found that 54% of senior developers now agree AI is making the junior role less relevant. Not “different.” Less relevant.
It’s simple - a senior picks up a task that used to go to a junior, ships it faster with AI, and the sprint looks fine on the burndown chart. Nothing breaks. Except the junior who would have learned from that ticket was never in the room.
What does that say to everyone about to become a junior software engineer?
Developer Role is Gone
There is no more “Developer” role. Of course, for the next few years companies will keep it, as they did with QA Testers (mostly for legacy purposes). But technically, “Mobile Developer”, “Backend Developer,” or “Frontend Developer” are already deprecated terms.
Today, you build full-stack. Backend, frontend, or mobile can be your mastery when growing into senior roles. But that's mostly for a “system engineer” role rather than a “product engineer” (see here for the difference).
The Myth of “Mastering the Basics”
The mainstream advice today is that because AI writes the code, engineers must become elite computer scientists to validate the AI’s output. You are told to master the deepest nuances of operating systems and programming languages so you can catch the machine’s mistakes.
Let’s be pragmatic: expecting a junior engineer to possess the architectural intuition of a dev veteran is impossible. But that doesn’t matter either.
Today we review AI’s code because we are in the transition period. Systems that we developed in the last decade need human explanation mainly around shortcuts, workarounds, and “I’ll fix it later”. The truth is, if these solutions were developed to standard, half of the “human in the loop” wouldn’t exist.
Five years from now, we will stop doing Code Reviews. It’s too inefficient.
Instead of trying to read and mentally validate thousands of lines of generated code, you need to master repeatable validation. What no one told me during my early career is that building the first version of any software is far less important than the ability to iterate quickly.
Learn to Iterate
During my career, the holy grail was to push to production a few times a month or weekly. Today the standard is to push multiple times a day. This is exactly how your first side project should look.
When building your first app, learn to change it on demand. That is what CI/CD is all about. You don’t have to learn pipelines, workers, and deployment processes (at least not now). You can set up a free account on Vercel or Cloudflare (Google GCP or Amazon AWS are powerful, yet complex monsters that will eat all your mental capacity at the beginning).
Then quick setup: Cloudflare CLI, a full-stack framework of your choice (I use Next.js), Claude Code or Google Antigravity, a GitHub account and the CLI, and a prompt to build the first app. The key is understanding how it’s all wired together.
When you configure everything properly, the most likely flow will go like this:
You do some coding via Claude Code
Code is being pushed to your repository on GitHub
Cloudflare, which is wired together with the GitHub project, picks it up automatically
Build and deploy processes run on Cloudflare
A minute later, you see your app on the web
This is the baseline. Of course, you could avoid this complexity and build something in Lovable, Base44, or directly on chat.openai.com. But if you want to become a product engineer, you need to take control over the change process and iterations.
Learn to Validate
First iterations will be easy. Idea -> Claude code -> push to GitHub -> 2mins later it’s live on Cloudflare. Very quickly, the quality will deteriorate - things will stop working, and an intended change in one place will result in something unexpected in another place.
This is where testing and validation come in. This is also the first step where you do more than Lovable or other no-code platforms.
The pipeline steps we described above will start growing. You will either add some static analysis - unit testing, linters, compilers, build process, security checks, or more “intelligent” checks like agent skills.
You have to figure out the verification toolbox on your own. If you ask me, for my projects I use unit testing and basic linters + a few skills, mainly Addy’s code-review-and-quality and Impeccable for the UI.
No matter the tool, your goal is to keep iterations fast (multiple changes a day pushed to production) and keep regressions and failures to a minimum.
Hacker Mindset
Okay, quick iteration is great, but what should we build in the first place? This was one of the main questions I asked myself at the start of my career, and there is no good answer.
But.
It's never been easier to build at the intersection of different languages, frameworks, or full environments. A few years ago, you had to pick a lane: frontend, backend, or mobile. Today you can build an end-to-end product with a database, API, and some UI in a few-hour session in Claude Code.
You can connect your cloud apps to IoT hardware, or drop a 3D environment into a 2D web app using Three.js. You can build a native mobile app and cloud backend for it in just a few sessions with the coding agent. The possibilities are endless.
In tech companies, we're seeing a new trend: the beta is the specification. In the last decade, when you wanted to build something new, you’d write a multi-page Product Requirements Document (PRD), spend weeks shaping that in Figma, and then hand it off to developers to translate into code.
As noted in The Agentic Awakening, this process is dead. Instead of specs and mockups, Product Managers and Designers now hand off working prototype code directly to engineering.
If you want to impress a hiring manager today, do exactly this. Go to their company’s website, open the Chrome DevTools, review their HTTP traffic, spot a bottleneck or a UI quirk, and build a functional app that solves it. If you crack the right problem, you immediately prove your systemic value.
Here’s my story. My team was struggling with internal governance processes for a no-code platform because the original product lacked the functionality we needed. We spent months doing manual, tedious work on mapping our ~300 no-code apps to the ownership matrices, access controls, etc.
Instead of drafting a proposal for a new feature, I built a custom dashboard with an AI agent. I hooked directly into private API calls and built a UI around them. It wasn’t perfect, but it saved us weeks of manual effort (I wrote more about the technical details here).
That is the hacker mindset. Find friction, build a beta that bypasses it, and show it to the people who matter.
Build Agent-First Architecture
Software is no longer just consumed by humans clicking buttons on a screen. We are entering a “white label” era where we build systems that organizations can consume without leaving their own environments.
When you build your side project, assume an AI agent will consume your application first, and a human second. It must be highly standardized, fast to access, and well documented.
I recently built colorharmony.dev. It’s a platform where you can pick traditional Japanese color combinations based on Sanzo Wada’s dictionary. The primary version was to explore 300+ color harmonies with a simplified UI. But as it grew based on consumer feedback, the real value became exposing an API designed specifically for AI agents, allowing them to automatically reason about color theory, integrate the harmonies, and pick the best ones based on a user’s prompt.
If you walk into an interview and explain how you structured your project’s API to be directly consumable by LLMs, you instantly separate yourself from 99% of candidates still trying to build regular apps.
Look For A Job That Doesn’t Have a Job Descriptions Yet
Right now nobody agrees on what to call the new roles. In a single week you’ll see postings for AI Engineer, Agent Engineer, Context Engineer, Forward-Deployed Engineer, LLMOps Engineer.
That confusion isn’t noise but the signal. A role with a settled job description is already commoditized. A role nobody can agree on how to title yet is one where you can still define what it means to be good at it.
A few worth understanding even if you never see them phrased this way in a posting:
AI Evaluator. Someone who designs tests and metrics to stress-test AI systems before and after deployment — builds evaluation datasets, simulates real usage, hunts for failure modes. If that sounds a lot like the “repeatable validation” I described two sections ago, that’s because it is.
Forward-Deployed Engineer. The name is military slang — embedded on the front line, not back at headquarters. In practice, it means an engineer who sits inside a specific customer’s environment, watches how they actually work, and builds custom software against their real data and workflows — often solving a problem nobody wrote a spec for. No PM layer, no account manager translating between “what the client needs” and “what gets built.” One person owns discovering the problem and shipping the fix (use my Problem Solving Framework to help with that). It’s the internal governance dashboard I described two sections ago, formalized into a job title: instead of drafting a proposal and waiting for a vendor to build it, you sit with the actual mess and ship something custom, directly.
Agent Architect. Designs systems where multiple AI agents coordinate across a workflow instead of one model answering one prompt. Gartner expects 40% of enterprise apps to embed task-specific agents by the end of this year, up from under 5% two years ago — and there are barely any people with real hands-on experience doing this, because the discipline is maybe eighteen months old (source).
An Orchestration Example
Here’s what this looks like in practice. As a platform engineering leader, I’ve been experimenting with AI agents that do incident investigation. For my case a single agent with one skill wasn’t enough. When something breaks, the root cause is scattered across sources — code, logs, infra — and no single agent context-switches well across all three.
So I built an orchestrator instead. It takes the input — an alert, a page, whatever kicks things off — and fans it out to subagents that each own one domain. One digs through GitHub CLI: recent changes, open PRs, the exact lines that touched the failing path. Another queries the observability platform for logs and traces (the Coralogix CLI in my case). A third checks the cloud infra setup — service ownership, what shipped recently. Each comes back with its own evidence. The orchestrator merges all three into one executive summary and an action plan.
Most of alert triages I did resulted in a-few-lines-of-code fixes that were created as PRs, reviewed and pushed to the production code. So that the next step I’m building now: an agent that turns that plan into an actual hot-fix.
That’s the job. Not writing a clever prompt. Deciding which problem gets split into which subagents, what each one is responsible for, and how their outputs get reconciled into something a human can act on in under a minute.
You Are Not a Programmer (Anymore)
The people struggling to find junior roles right now are the ones trying to out-code AI. You will lose that race every time — the machine doesn’t get tired, doesn’t need sleep, and is getting better at exactly the thing you’re competing on.
So don’t compete on it. When you sit down for that interview, don’t reach for programmer analogies. Don’t call yourself a developer.
Remember those internship candidates I mentioned at the start — the ones we picked not for their code but for whether they could tell us why they built something one way and not another? That’s still the entire test. It was true before AI could write a for-loop, and it’s true now that AI can write your whole app. The code was always the byproduct. The judgment was always the job.
The tools changed. The test didn’t.