The Junior’s Dilemma in the AI Era
I left my company and have been coding alone for more than six months. The past six months were the fastest stretch of change I’ve ever lived through. Coding, especially, took the full impact of that change. If I had stayed at the company, I probably wouldn’t feel it as sharply yet. Building products with my own hands, hitting wall after wall, I came to feel the speed of AI’s progress in development exactly as it is.
People around me include mid-level engineers, but a fair number of juniors too. I used to mentor some of them, I still mentor some now, and once in a while one of them brings a resume and I give feedback. Their worries became mine. I kept turning the same questions over. In this brutal market, what should they do to land a job? In this AI era, can they actually get hired the old way, by prepping a portfolio, doing a bootcamp project, and blogging? How are they supposed to grow at all?
The Cold Reality of the Hiring Market
Why Junior Hiring Shrunk
In a stretch where tech moves this fast, the market froze just as fast and hiring collapsed. Junior hiring, especially, has all but dried up. Unlike three or four years ago, the IT industry has lived through layoffs, voluntary retirements, bankruptcies, failed pivots, and the companies that survived learned that if you don’t keep your wits about you, you go under. Even when the market loosens up and money starts flowing again, that lesson means they won’t go on a hiring spree the way they did three or four years ago.
The claim that AI is killing developers is, for now, a false statement. We can’t push back against the macroeconomic tide, and the job crunch is a global issue, not just a Korean one. Companies have tightened their belts, and on top of that, they barely pay anything for hires they have to grow and teach, which means people who can’t be put to work right away. You design a future when you can see tomorrow. When you’re just trying to survive today, all of that feels like waste. But cause and effect are real here: a global economic crunch is producing a job crunch, and AI is accelerating it.
Who Companies Actually Want
The roles posted most heavily right now are mid-level, roughly four to six years of experience. I often see people who slipped into the so-called developer boom three or four years ago hopping jobs relatively easily, even in this rough market. But people who are just starting to study development or who just took their first job, juniors and entry-level engineers, either can’t get hired and switch jobs at all, or they luck into a position and get no real chance to learn.
When companies hire heavily at the mid-level, they’re hiring people who can plug into the current project on day one. As a junior, you have basically zero experience building or running a real production project. So if a junior wants to be competitive in today’s hiring market, they need experience collaborating on a team project, deploying it to an environment with actual users, and operating it. It’s not easy for one developer to build something, ship it, and run it while also taking care of marketing and operations. It’s hard. And yet that’s the kind of person companies are hiring right now.
AI Is a Double-Edged Sword for Juniors
AI is a double-edged sword for juniors. It’s a tired metaphor, but it’s the kind of sword where the more you swing it, the more you cut yourself. Some people say that with AI you can ask anything, study anything, do anything easily, and that traditional education is over and anyone can do anything. In the development areas I know “well,” I can study that way too, and I do. I can’t even remember the last time I went to the developer book section of a bookstore. I used to drop by Kyobo Mungo and check what was new every time I was nearby. These days I almost never go.
How Do You Ask When You Don’t Know What You Don’t Know?
But if I want to study a brand new field, can I just lean on AI right away?
Recently I wanted to study Japanese, and I tried using AI to look up sentences and various things, and I ended up buying a textbook and a course. A complete beginner doesn’t even know what to ask. To borrow a machine-learning analogy, without some pre-training on a dataset, you can’t do anything.
So when I mentor juniors, I tell them to use AI agents like Claude Code as little as possible. Some people will hear that and call it obsolete advice. Fair enough. But when you don’t even know what you don’t know and you hand most of your work to an AI coding agent, you lose every chance to learn and grow. Thanks to AI, everyone can build something. Because of AI, no one is learning. That’s the era we’re in.
The Difference Between an AI Agent and Searching or Asking
The advice here isn’t aimed at non-developers building products through vibe coding (founders, basically). This is for people who want to grow into professional developers, and it isn’t only true for development. In any field where you want real expertise, handing everything to AI makes it hard to find the chance to grow properly. Searching and asking when you don’t know something, using AI for that, I recommend it. (What I’m saying not to use is the AI coding agent that does it all for you.)
Even back when AI didn’t exist, copying and pasting working code from Stack Overflow without understanding the cause was constant. The difference is whether I’m asking the AI directly about my own problem or not. And it matters more than you’d expect where the agency sits. If it sits with me, the learning from solving the problem stays with me. If it sits with the AI, that learning gets thrown out with the AI.
So How Should You Use AI?
Let me get specific. The standard a junior should hold to when using AI is this: did I try first? When an error happens, read the message first. Then form a hypothesis about why it’s happening. Then ask the AI. Not “how do I fix this error?” but “I think this error is happening because of A, is that right?” The difference is huge. Same when you write code. Type it yourself first. When you get stuck, figure out exactly where you got stuck and ask only about that part. Not “build me a login feature,” but “the session isn’t holding, is the logic in this part wrong?”
To sum it up:
Do this:
- Read the error message, form a hypothesis, then ask AI to verify
- Ask for feedback on code you wrote yourself
- Ask for explanations when a concept confuses you
- After you finish solving a problem, ask about other approaches
Avoid this:
- Throwing requirements at AI and asking for the whole thing
- Pasting an error without even reading it
- Only asking “why isn’t this working?”
- Copying AI’s code without understanding it
In the end, the agency has to sit with you. AI is a tool that helps you learn, not a thing that learns in your place.
What Juniors Should Be Building Now
I’m about to talk about literacy, real projects, and coding tests, and I can already hear the question, “so what should I do first?” Honestly, it depends on your situation. If you push me to rank them, here’s how:
- If you have an interview lined up: Coding tests and tidying up your projects come first. Literacy doesn’t go up overnight.
- If you have three months or more: Read and write in parallel while starting a real project. One coding test problem a day, steadily.
- If you’re prepping over six months or more: Build literacy first. It ends up setting the speed of every other kind of learning.
The key is that all three of these aren’t “things to do,” they have to become “habits.” This isn’t something you flash through during job-prep season and drop. Reading books, running projects, training problem-solving, those are things you keep doing the entire time you work as a developer. Starting now is fast.
Literacy: Reading and Writing
Looking back at the mentoring I’ve done recently, the biggest issue is literacy. In this AI era, the ability to read and write may have become more important than code. AI models these days dump enormous answers in response to a single question, and being able to actually read it, understand it, digest it, and apply the right solution to your case, that’s literacy too. Asking AI a good question is the same. Beyond communicating with AI, once you join an organization you’ll be communicating with people, and grasping the core of what someone is saying, digesting it, organizing your opinion, and speaking it, those are all abilities that grow out of literacy.
When someone preparing to land a developer job asks me what they should prepare, I tell them: read more books than you do projects or algorithms. Then take what you read, organize your thoughts about it, talk about it with other people, and write about it. That’s the fastest way to raise your literacy in the short run. In an era where every piece of content is short-form, the one edge you can take over everyone else is reading and writing. With that as a foundation, whether you’re aiming at being a developer or studying any other field, you’ll grow much faster.
People who read a lot don’t automatically succeed. But every successful founder I’ve watched was a heavy reader. The people who can step back and check their own thinking, read the current situation, learn, and pull action items quickly, they were all heavy readers too. Sometimes when I’d talk with them about books I’d read before, almost every one of them had read the same ones. The people whose growth stalled and who kept making the same mistakes were mostly the ones who had stopped reading.
When I tell people to read more, the next question is “what should I read?” If you really feel cut off from books, read anything. A shallow self-help book is fine. Whether it’s shallow is for you to decide after you read it. That said, if you want to raise your literacy quickly, read books you can write about. Read a novel and write your impressions, read a business book and organize your thoughts, read books that let you share your thinking with others. That’s what accelerates your growth. And if you read two or three books for self-improvement, it’s worth squeezing in one novel that someone recommends to you. Novels help you step back and check your own thinking, and they grow your empathy without you noticing.
Project Experience That’s Close to the Real Thing
No matter how deep your specialized knowledge gets, studying alone has limits. The throwaway one or two-month projects from a bootcamp or an academy don’t move the needle for companies. People who face the reality of what the market demands today, think hard about what counts as a project close to the real thing, and pile up that kind of experience are the ones who’ll stand out. Developers can at least lean on AI; in other fields, that kind of pre-employment experience is even rarer, so paradoxically, you should value it more.
Close to the real thing means you deployed even a small feature yourself, recruited users, took feedback from those users, and improved the feature. Most junior portfolios end at toy projects, so just having shipped to production and improved something already gives you a real edge, and on top of that, fixing bugs and working through user feedback is something to keep building on. Whatever stage you’re at, getting hired in this market takes patience, and instead of burning that time only on studying, scout for projects where you can build real-world experience, plan them, run them. Building something that even ten people use versus building a throwaway project will give you completely different growth opportunities.
Coding Tests: Training Problem-Solving, Not Memorization
Junior developers ask me a lot whether it still makes sense, in an era when AI does it all, to study coding tests. And in the actual workplace, people say algorithm coding tests were useless to begin with and now even more so.
There’s a part of this that’s true and a part that isn’t. If you ask whether algorithms are useful in themselves, well, while building APIs or implementing UI, we almost never use dynamic programming. (For typical SaaS or B2C services.) Reading lots of books, as I said above, has more direct relevance. (Meetings, documentation.) That said, if you treat dynamic programming as domain knowledge, the practice of figuring out how to solve the problem in front of you is, I think, an essential learning process for a developer.
In other words, prepping for coding tests by memorizing data structures and algorithm theory and solutions is no help at all. We can run into new customers and new requirements at any company, in any domain, in any project, so what we need isn’t algorithm theory as explicit knowledge but the tacit knowledge you pick up in the process of solving the problem. A problem is given, you organize how to solve it, you turn it into code. That’s why I think Big Tech still values algorithm interviews. It’s hard, in a portfolio project, to analyze and implement ten different customer requirements, but with algorithm problems, every problem lets you practice the problem-solving process in a fresh setting with fresh information. As long as you bring deliberate practice to it, algorithm coding tests can be a serious help. And if, after you finish your own solution, you ask AI for feedback to expand your knowledge and experience from different angles, even better.
Closing: Why People Are Still Needed
Someday, all our jobs may be replaced by AI. But for now, a person still has to drive. The market shrunk and hiring shrunk with it; that doesn’t mean hiring is gone. Even with tech moving this fast, companies are still hiring and still need people. When you’ve run an organization, you see that more often than the code itself, people are the opportunity and people are the problem. Other fields are probably the same.
If I were the hiring lead or the owner, who would I want to work with? Compared to that bar, what am I missing? Think it through and the things to prepare are clearer than you’d guess. A company invests 10 in its people and tries to get back 11, 20, or 100. Even after you get hired, you have to keep asking yourself whether you’re someone who can contribute to the whole organization’s growth.
The market is rough. At times like this, you walk your own path: do your utmost and leave the rest to heaven — what Koreans call jinin-sadaecheonmyeong (盡人事待天命). Instead of dropping a line about how AI is doing whatever, instead of staring at endless shorts, read a book and put your thoughts in order. Even if you’re not good at it, please keep at it. And don’t try to study; run projects the way you’d run work. And don’t try to memorize; practice coding tests the way you’d train a process.
You can’t fight the times. The individual human is fragile. People are easily swept up by their environment. When good results come, it’s usually because the environment cooperated. It feels like you got hired because you were good, but it might have been a good market (or good timing), and your results inside an organization usually rest on the organization’s systems. Anyone who’s done real work will agree. So you shouldn’t get smug when things go well, and you don’t need to spiral when things go badly. You can’t beat the times, but you can beat today. Look honestly at yourself and you already know what to do in this moment.
I roughly organized the thoughts that came up while mentoring junior developers. I hope this lands for someone trying to make it through.
댓글
댓글을 불러오는 중...
댓글 남기기
Legacy comments (Giscus)