The First 90 Days of Your First Dev Job: What Nobody Tells You
Your first 90 days as a software developer are judged on reliability and attitude, not raw skill. Here is what nobody tells you, with scripts for asking for help and surviving probation.
On your first morning, you will open the company codebase and understand almost none of it. That is not a sign you got hired by mistake. It is the normal starting point for every junior developer, including me on day one in Kolkata years ago. The first 90 days are not a skill test. They are a trust test, and trust is much easier to earn than skill.
If you are still landing that first junior developer role, save this for later. If you start Monday, read it now.
The short answer: what your first 90 days as a software developer test
Your first 90 days as a software developer test reliability, communication, and attitude far more than raw coding skill. Managers expect you to be slow and confused at first. What they watch is whether you show up, ask good questions, own your mistakes, and improve each week. Nobody expects a junior to ship perfect code in month one.
What is actually being judged in your first 90 days?
You are judged on character, not on how much code you write. Most Indian IT firms and startups put new hires on a formal probation of three to six months. People assume probation measures your technical output. It mostly measures whether the team can rely on you.
Here is what your manager is really checking in those first weeks:
- Reliability: Do you finish what you say you will, and flag it early when you cannot?
- Communication: Can you explain what you are stuck on in plain words?
- Attitude: Do you take feedback without getting defensive?
- Growth: Do you make the same mistake twice, or do you learn?
Notice that raw skill is not on that list. A junior who is honest, coachable, and steady beats a faster coder who hides problems. In India, where probation reviews and team hierarchy are taken seriously, this matters even more. Be the person your senior trusts with a small task. The bigger work follows.
Feeling like a fraud in month one is the default, not a warning sign
Yes, it is normal, and almost everyone feels it. That voice saying “what am I doing here” has a name: impostor syndrome. Most people feel it at some point, and developers feel it hard. I went deeper on why it hits even senior engineers in impostor syndrome in tech.
Here is what most new developers do not believe: even senior engineers Google basic things regularly. They forget syntax. They copy from old projects. The difference is they stopped treating not-knowing as shameful. If you ever wondered whether coding is still worth learning now that AI exists, this is part of the answer: the job was always about learning on the go. As one widely-shared piece on things to know as a junior developer puts it, companies do not expect juniors to be experts. They hired you to grow into the role.
The goal of your first 90 days is not to look smart. It is to become useful, one small task at a time.
In my first job I once spent a whole day pretending I understood a ticket, because I was too scared to ask. I shipped the wrong thing. The fix took ten minutes once I finally asked. Hiding cost me a day. Asking would have cost me two minutes of pride.
How do I survive a codebase I do not understand?
Trace one real request from start to finish, and resist the urge to refactor anything. You do not need to understand the whole system. You need to understand one path through it.
This is where beginners get stuck: they try to read every file and panic. Do not do that. Pick one feature, like login, and follow it step by step:
- Find where the request enters: the route or the button click.
- Follow it to the function that handles it.
- See what database call or API it makes.
- Track the response back to the screen.
Add a print or log line at each step and run it. Watching real data move teaches you more than reading ever will. The same patient tracing skill you built while you were learning to code works here too.
One firm rule for month one: do not refactor old code yet. It may look messy, but it often handles cases you cannot see. Ask why it is written that way before you “fix” it.
Ask for help on a thirty-minute timer
Try on your own for 15 to 30 minutes, then ask with a hypothesis. The 15-30 minute rule keeps you from wasting a day stuck and from interrupting people every five minutes. Both extremes hurt you.
The secret is how you ask. A bad question makes you look lost. A good question makes you look like a thinker. Use this script:
I'm trying to: [the goal]
I expected: [what should happen]
Instead I got: [the actual result + error]
I already tried: [the 2-3 things you checked]
My guess is: [your hypothesis]
Where am I wrong?That last line is the magic. A guess shows you did the thinking first. Seniors love helping people who already tried. The freeCodeCamp guide to acing your first year as a junior developer makes the same point: asking well is a skill seniors respect.
Save this script. Paste it into your notes app today. You will use it every week of your first year.
Twenty comments on your first pull request is a good sign
No. Twenty comments on a first pull request is completely normal and is not punishment. A pull request, or PR, is how you propose your code changes for review before they merge. Review exists to improve the code, not to judge you.
I still remember the dread before my first PR. I had written about 40 lines. I got back a wall of comments and felt sick. Then a senior told me something I now repeat to every student:
Comments are free mentoring. Each one is a senior teaching you their experience for free. Read them as lessons, not as a scorecard. Here is how to handle review without stress:
- Do not take it personally. The review is about the code, not about you.
- Ask why if a comment is unclear. “Can you explain this one?” is a fine reply.
- Fix what is asked, and say thank you. Defensiveness is the real red flag.
- Keep your PRs small. A 50-line change gets cleaner review than a 500-line one.
For the mechanics of a clean PR, GitHub’s own guide on how to write a good pull request is worth ten minutes. A clear title and a short description cut your comment count fast.
What do I say in standup when I am stuck?
Say it in three parts: what you did yesterday, what you plan today, and what is blocking you. The daily standup is a short team check-in, usually 15 minutes. It is not a status exam, so keep it tight.
New developers often hide blockers because they feel ashamed. That is backwards. Saying “I am blocked” early is a strength, not a weakness. A blocker you hide for three days is a real problem. A blocker you raise in standup gets solved by lunch.
A simple standup update sounds like this:
- Yesterday: I traced the login flow.
- Today: I will fix the validation bug.
- Blocked on: which API key to use, so I will ping Priya after this.
Short, honest, clear. If you want the background on the format, Atlassian explains how daily standups work well.
What “doing well” actually looks like this early
Ask your manager directly in week one, then write the answer down. The single best question a new hire can ask is simple: “What does success look like for me in the first 90 days?”
Most juniors guess what is expected and then stress about the wrong things. Stop guessing. Get the real target from the person who decides your probation. Then revisit it monthly so there are no surprises in your review.
| What juniors think matters | What managers actually want |
|---|---|
| Writing the most code | Finishing small tasks reliably |
| Never asking questions | Asking good questions early |
| Knowing everything | Learning fast and taking feedback |
| Hiding mistakes | Owning mistakes honestly |
Keep a small “wins log” too. Every Friday, write one thing you learned and one thing you shipped. By review time you will have proof of growth, not just a vague feeling.
You will break something, and it matters less than you think
Own it fast, tell someone, and help fix it. Accountability matters far more than perfection in your first 90 days. Every developer has broken something. The ones who last are the ones who do not hide it.
If you push a bad change, do not freeze. Say it plainly: “I think my change broke the build, I am looking at it now.” That sentence builds trust. A senior would rather hear it in two minutes than discover it in two hours.
You will not get fired for one honest mistake. People get let go for hiding problems, blaming others, or not improving. Mistakes are how you learn. Learn from one and you rarely repeat it.
A week-by-week shape for the first 90 days
Move through three simple phases: orient, contribute, then grow. You do not need to be a star by day 90. You need to be trusted, useful, and clearly improving.
- Days 1-30 (orient): Set up your tools, meet the team, trace one feature end to end, and ship a tiny fix.
- Days 31-60 (contribute): Take small tickets, get through code review, and ask good questions.
- Days 61-90 (grow): Own a small feature, help with bugs, and reduce how often you need help.
If that feels slow, good. Slow and steady is exactly what passing probation looks like. The job is a marathon, and you just started lap one.
Two things to do before day one: paste the help-asking script above into your notes app, and plan to ask your manager the success question in week one. Those two moves will put you ahead of most new hires, and neither one requires you to write a single line of code.
