Your First 90 Days in a Software Job: What Actually Gets You Kept

Part of our guide hub: IT careers in Pakistan

Most juniors spend their first month trying to prove they can code. That is not what anyone is evaluating. Your team already decided you could code when they hired you.

What they are working out is something else entirely: whether managing you costs more than you produce. Here is what that actually means, and how the first ninety days usually go for the people who do well.

What your manager is really assessing

1. Do you get unstuck? Not whether you get stuck, everyone does. Whether you spend nine hours silently stuck or ask after ninety minutes with a clear description of what you tried.
2. Do you finish? A small task fully done, tested and deployed beats an ambitious one at eighty percent.
3. Is your work visible? If nobody knows what you did this week, for practical purposes you did nothing.
4. Do you improve after feedback? The same review comment appearing three times is the clearest negative signal there is.
5. Can people work with you? Clear updates, no defensiveness in code review, reliable about what you committed to.
6. Do you understand the business? Juniors who ask why a feature matters get given better work.

Weeks 1 and 2: absorb and ship something tiny

Your goals are narrow: get the project running locally, understand how code reaches production, and ship one very small change.

That first change can be trivial. A copy fix, a validation message, a small bug. What matters is that you have walked the entire path from ticket to production once, because everything after that is the same path with bigger changes.

Keep a questions file. Write down everything you do not understand instead of interrupting five times a day. Batch them into one conversation. Senior engineers notice this immediately and it reads as respect for their time.

Weeks 3 to 6: build a real thing

You should now be taking properly sized tickets. Three habits separate the juniors who progress from the ones who plateau:

Ask before building, not after. Spend twenty minutes writing what you think the task requires and confirm it. Two days of work in the wrong direction is the most common junior failure and it is entirely preventable.

Read more code than you write. Before adding something, find three places in the codebase that do something similar. Match them. Code that looks like the code around it is the mark of someone who will be easy to work with.

Test your own work properly. Not “it runs”. What happens with empty input, a slow network, a logged out user, a duplicate submission. Every bug caught by QA that you could have caught is a small withdrawal from your credibility.

Weeks 7 to 12: become dependable

By now the question has shifted from “can they do the work” to “can we rely on them”. Dependability is mostly about communication, not output.

• Flag slippage the day you know. “This will take until Thursday, here is why” on Monday is fine. Silence until Thursday is not.
• Own mistakes plainly. “I broke staging, I am fixing it, here is what happened” earns trust. Everyone breaks something. How you handle it is what people remember.
• Volunteer for the unglamorous work. The flaky test nobody fixes, the documentation nobody updated. It is visible, it is appreciated, and very few juniors do it.
• Start having opinions. Gently. “I think this should be in a shared helper, what do you think?” A junior who never disagrees is a junior nobody learns to trust with decisions.

The five mistakes that cost people the role

• Disappearing when stuck. The single most common reason juniors are let go. Nobody minds you being stuck; they mind finding out on Friday.
• Pretending to understand. Nodding through a handover and then guessing. Ask again. Nobody respects you less for it.
• Rewriting things nobody asked you to rewrite. The old code is usually old for reasons you have not learned yet.
• Treating code review as criticism. It is how the team transfers knowledge. Arguing every comment marks you as expensive to work with.
• Working late instead of working clearly. Long hours early are read as poor estimation, not commitment.

The weekly habit worth building

Every Friday, write three lines somewhere your manager can see: what you finished, what you are blocked on, what is next. It takes four minutes.

Six months later this is also the document that gets you a raise, because you can point at a record rather than trying to remember what you did. Most people cannot, and it costs them.

If you are still trying to land that first role, our notes on writing a CV that gets shortlisted and preparing for technical interviews cover the step before this one.

Frequently asked questions

How much should a junior produce in the first month?

Very little, and that is expected. Most teams assume a junior is net negative for six to eight weeks. Trying to look fast in week two usually produces work that costs a senior more time to fix than to have written.

How often should I ask for help?

A reasonable rule: try for sixty to ninety minutes, write down what you tried, then ask. Include what you attempted and what you expected to happen.

What if I was hired for a stack I do not know well?

Say so early and privately to your manager, along with your plan to close the gap. Discovered in week ten, it is a problem. Declared in week one, it is normal.

When can I ask for a raise?

Not in the first ninety days. Build the Friday record, deliver consistently for two quarters, then ask with evidence.

Ezitech runs three month hybrid internships that put trainees on live client work with mentor review, which is where most of these habits are actually learned. See the programme.