What Actually Changes in Your First Two Years as an Engineer

Junior software engineer tips for the two years nobody prepares you for

You spent months preparing for data structures questions and maybe some system design. Then you arrive, and the first fortnight goes on getting the project to build, reading code nobody has explained, and sitting in meetings about a system you have never seen. If you are looking for junior software engineer tips, the most useful one is this: that gap is normal, and it is not a sign you were hired by mistake.

Interviews test the small part of the job that is easy to test. The rest is learned on site. I am a Lead Full Stack Engineer and I have onboarded and worked alongside a lot of new engineers, and the ones who do well in their first two years are rarely the ones with the best interview scores. They are the ones who learn to read code, ask good questions, ship small, use code review, and make their work visible. This post covers each of those, plus what actually gets people promoted from junior to mid level.

Your first year as a software engineer: the job is not what the interview implied

This is not a bait and switch, and it is not only you. When Microsoft Research shadowed new graduates in their first months on the job, the resulting paper, Novice Software Developers, All Over Again, found that their biggest struggles were not technical. They were communication, collaboration and knowing how to operate inside a large team: when to ask, who to ask, and how to find work that mattered.

That matches what I see. University trained you to write code into empty files, alone, against a clear specification, and to be graded on the result. Work asks you to change code other people wrote, in a team, against a specification that is often vague, and nobody grades you directly. I wrote more about this shift in why professional software development feels different from university.

Knowing that in advance saves a lot of anxiety in month one. Here is what actually determines how the first two years go.

Reading code is now the main skill

At work you will spend most of your time reading code written by people who left before you arrived, under deadlines nobody remembers, for reasons nobody wrote down. A large field study of professional developers that tracked 78 engineers over 3,148 working hours found they spent roughly 58% of their time on program comprehension. Reading is the job.

It is trainable, and almost nobody trains it deliberately. What helps:

• Follow one request end to end. Pick something small the product does, find where it enters the system, and trace it through to the database and back. One trace teaches you more about a codebase than a week of browsing.
• Use the version history. When code looks wrong, check who changed it and why. The commit message and the linked ticket often explain a decision that looks arbitrary. If Git still feels like magic, read Git: the model behind the commands.
• Run it and break it. Change a value, add a log line, run the tests. Code you have poked is code you understand.
• Accept partial understanding. You do not need to understand the whole system. You need to understand the part you are changing and its edges. Waiting for full comprehension means never starting.

My longer answer on how to read and understand a large codebase goes step by step, and Working Effectively with Legacy Code is the classic book on changing code you did not write.

How to ask questions at work without looking lost

New engineers reliably wait too long to ask, out of fear of looking incompetent. The calculation is backwards: two days stuck on something a colleague could have explained in five minutes is far more visible than the question would have been.

There is a way to ask that costs almost nothing:

I am trying to do X. I expected Y and got Z. I have already checked A and B. My best guess is C. Where should I look next?

That shows you tried, respects their time, and is easy to answer. Compare it with "this does not work, any ideas?", which asks them to do the whole investigation.

A reasonable rule for the first year: try for thirty minutes, then ask. Not two days. Not two minutes. I expand on this in how to ask for help without looking incompetent, and if the person you need to ask is much more senior and intimidating, afraid to contribute around a much more experienced teammate is for you.

Ship small changes, not impressive ones

The instinct in a new job is to prove yourself with something impressive. The result is usually a large pull request, opened in week three, touching thirty files, that nobody wants to review and that conflicts with everything.

Ship something tiny in your first week instead, even a typo fix. It gets you through the deployment pipeline once, which is where the real institutional knowledge lives, and it establishes you as someone whose work arrives. What actually happens between your pull request and production explains that pipeline if it is new to you.

Then keep changes small permanently. Google's public engineering guide on small changes lists the reasons: small changes are reviewed more quickly and more thoroughly, are less likely to introduce bugs, waste less work if rejected, are easier to merge and simpler to roll back. It even notes that reviewers can reject a change purely for being too large. A small pull request gets reviewed in an hour; a large one sits for three days, and that difference compounds into how fast you appear to work.

Code review is the fastest teaching you will get

Review will feel like criticism for a while. Reframe it quickly, because it is the highest bandwidth teaching you are going to get in your first software engineering job.

When you receive review:

• Separate the code from yourself. Easier said than done, and it gets easier with practice.
• Ask why when a comment is unclear. Do not comply silently. The answer is usually a piece of context you did not have.
• Disagree with reasons, then commit. If you disagree, say so and explain. If the decision goes against you, accept it and move on.

When you give review, and start giving it early even as a junior:

• Label your comments. Say which are broken, which are genuine improvements, and which are your preference.
• Approve things that improve the codebase even when they are not what you would have written.
• Watch your tone. Reviews turn hostile almost entirely through tone, almost never through content.

Reviewing other people's code is also one of the fastest ways to learn a codebase, and my answer on how to give code review feedback without creating conflict covers the wording.

Learn the domain, not just the stack

The engineers who become valuable fastest are not usually the ones who learned the framework fastest. They are the ones who understood what the business actually does.

If you work on payments, learn how settlement works. If you work on logistics, learn what a route actually costs. If you work at a services company, learn what the client is really trying to achieve, not just what the ticket says. This knowledge does not transfer to your next job, which is why people undervalue it, and it is exactly what lets you notice that a requirement makes no sense before three weeks are spent building it.

A good way in is the data model. Spend an afternoon with the database schema and ask what each table represents in the real world. If schemas still feel abstract, Grokking Relational Database Design and Modeling builds that intuition properly.

That noticing is the difference between an engineer who implements tickets and one whose opinion gets asked for.

Write things down where other people can see them

Your work is invisible unless someone writes about it, and if you do not, the account of what happened will be someone else's.

None of this needs to be elaborate:

• Notes in the ticket about why an approach was abandoned.
• A short doc before a non trivial change, describing the options and the choice.
• A summary after an incident.
• A comment above the strange looking function explaining why it has to be that way.
• Clear commit messages. How to Write a Git Commit Message is a ten minute read that pays off for years.

Two things happen. Your thinking gets sharper, because writing exposes reasoning that sounded fine in your head. And your contribution becomes legible to people who were not in the room, which is who decides promotions.

Keep a record of what you did

Once a week, one line: what you shipped, what broke and how you fixed it, what you learned, and anything someone thanked you for.

This takes two minutes and solves a problem that arrives predictably. At your first performance review, or the first time you update your CV, you will be asked what you achieved and you will remember the last three weeks. Julia Evans calls this a brag document, and her point is that your manager forgets your work too, yet they are the one who has to argue for your promotion. The people with specific examples are not more accomplished. They wrote it down.

Junior software engineer tips for year one vs year two

The first two years are not one block. The focus shifts, and knowing that helps you spend your energy well.

Year two is also when design starts to matter. You will be asked to shape features, not just build them, and a basic grasp of how systems fit together makes that far less stressful. My answer on how to learn system design as a junior developer explains how to start without getting lost, and Grokking System Design Fundamentals is a structured introduction to the building blocks.

What actually gets junior software engineers promoted

Not being the strongest programmer on the team. The pattern is consistent enough to state plainly:

• Reliability. Work that arrives when you said, or an early warning when it will not. This is rarer than it should be and it is the foundation of everything else.
• Scope taken without being asked. Noticing the flaky test everyone works around, the deployment step that always breaks, the documentation that is wrong, and fixing it. Nobody assigns this and everybody notices it.
• Making other people faster. Reviewing thoroughly, answering questions, writing things down so the next person does not have to ask.
• Communication. Explaining a technical trade off to someone non technical, briefly and without condescension, is rare and disproportionately rewarded.

Three of the four are not about writing code. I go deeper in how to get promoted from junior to mid level developer and in the habits that make an engineer worth routing work through.

Where AI tools fit in your first two years

You will be expected to use AI assistants at work, and you should. But be careful about what they do to your learning. In a randomised study published by Anthropic in January 2026, 52 mostly junior engineers learned a new Python library. Those who could ask an AI to generate code scored 50% on a follow up quiz, against 67% for those who coded by hand. The AI users who scored well were the ones who asked conceptual questions and used the tool to understand, not to replace their thinking.

That is the rule I would give any junior: use AI to explain, to suggest, to check, but make sure you can explain every line you submit. If you cannot, you are borrowing competence you will need later. See am I learning if I do not understand AI generated code and how to use AI as a companion, not a crutch.

On imposter syndrome in your first developer job

You will feel underqualified for most of the first two years. So does almost everyone, including the engineer whose confidence you envy, who is currently confused about something they are too embarrassed to ask about.

The feeling does not resolve by becoming good enough. It resolves by noticing, eventually, that you now answer questions you used to ask, and that the code you wrote a year ago looks wrong to you. Both are signs of progress, and both are easy to miss while you wait for a moment when you feel qualified. That moment does not arrive. The work gets done anyway.

If a bad week is getting to you, read how to overcome imposter syndrome in your first developer job and how to bounce back after a bad day as a junior developer.

Learn it on Sefism

• First job roadmap and the first job cheat sheet
• First 90 days in a new developer job
• Career growth roadmap for year two and beyond
• The Missing README, a book written for exactly this stage
• Grokking System Design Fundamentals for when you start designing features
• Grokking Relational Database Design and Modeling for understanding the data behind the domain

FAQ

What should a junior software engineer focus on in the first year?

Reading the codebase, learning the team's tools and deploy path, asking structured questions after about thirty minutes of trying, and shipping small changes reliably. Technical depth grows from there.

How long does it take to feel comfortable in a first developer job?

Most people start to feel useful after three to six months and genuinely comfortable somewhere in the second year. Feeling lost in the first few months is normal, not a warning sign.

How do I get promoted from junior to mid level?

Be reliable, take on small problems nobody assigned you, help others move faster, and communicate clearly. Keep a weekly record of your work so you have evidence when review time comes.

Is it normal to feel like an imposter as a junior developer?

Yes. Most engineers feel it, especially in the first two years. It fades as you notice yourself answering questions you once asked, not by reaching a moment of feeling fully qualified.

Should junior developers use AI coding tools?

Yes, but use them to understand rather than to avoid thinking. Research on junior engineers found those who asked AI conceptual questions learned far more than those who let it write the code.

Ask your own question

If your situation is different from the ones above, the career questions library has honest answers to the questions students and engineers ask me most.

Want a learning roadmap built around you, written answers to your own questions and a place to talk through your first job? Create your free Sefism account. Members can also book a one to one session when they want to talk it through.

Stay in touch

• LinkedIn: where I share roadmaps, career advice and honest takes on hiring. Follow, or message me.
• X (Twitter): short practical thoughts on engineering and careers.
• Instagram: quick tips and a more personal side.
• Sefism Discord: meet other students and engineers working through the same job market and share what is working.
• Sefism on YouTube: walkthroughs and talks.