What Actually Changes in Your First Two Years as an Engineer

The job is not what the interview implied

You spent months preparing for algorithm questions and system design. Then you arrive, and the first fortnight is spent trying to get the project to build, reading code nobody has explained, and sitting in meetings about a system you have never seen.

This is not a bait and switch. It is that interviews test the small part of the job that is easy to test, and the rest is learned on site. 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 the main skill now

At university and in tutorials you write code into empty files. 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.

This 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 frequently explain a decision that looks arbitrary.
• 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.

Ask questions well, and early

New engineers reliably wait too long to ask, out of a 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.

Small changes, shipped, beat large changes in progress

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.

Keep changes small permanently, not just at the start. A small pull request gets reviewed in an hour and a large one sits for three days, and the difference compounds into how fast you appear to work.

Code review is where you learn fastest

Review will feel like criticism for a while. It is worth reframing quickly, because it is the highest bandwidth teaching you are going to get.

On receiving it: separate the code from yourself, which is easier said than done and gets easier with practice. Ask why when a comment is unclear rather than complying silently; the answer is usually a piece of context you did not have. If you disagree, say so with reasoning, then accept the decision if it goes against you.

On giving it, and start giving it early even as a junior: distinguish between what is broken, what is a genuine improvement, and what is your preference, and label them. Approve things that improve the codebase even when they are not what you would have written. Reviews turn hostile almost entirely through tone, and almost never through content.

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. This knowledge is not transferable 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.

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 document 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.

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, 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 resume, you will be asked what you achieved and you will remember the last three weeks. Everything before that is gone. The people who have specific examples with numbers attached are not more accomplished; they wrote it down.

What actually gets you 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 the thing down so the next person does not have to ask. Multiplying the team is what senior means, long before the title.

Communication. The ability to explain a technical trade off to someone non technical, briefly and without condescension, is rare and disproportionately rewarded.

Notice that three of the four are not about writing code.

On imposter syndrome

You will feel underqualified for most of the first two years. So does 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 are looking for a moment where you feel qualified.

That moment does not arrive. The work gets done anyway.