Your First 90 Days in Your First Tech Job

Nobody Expects You To Be Good Yet

You spent a year preparing for interviews. Then you cleared one, joined, got a laptop, got added to fourteen Slack channels, and opened a repository with 4,000 files in it. Within a week the confident feeling from the offer letter is gone, replaced by a specific, quiet fear: they are going to work out that I do not know anything.

Here is what nobody tells freshers on day one. Your team already knows you do not know anything. They hired a fresher deliberately. Nobody expects technical output from you in month one. What they are watching for is something else entirely, and it is much easier to deliver than being brilliant.

What Probation Actually Measures

Most Indian tech offers carry a probation period — commonly three to six months, with the exact terms in your appointment letter. Confirmation is usually a formality, but "usually" is doing work in that sentence, and the signals that decide it also decide your first appraisal.

Managers are not scoring your code in month one. They are answering four questions:

1. Is this person reliable? When they say Thursday, is it Thursday — or is it Thursday with no message until Friday afternoon?
2. Do they get unstuck? Everyone gets stuck. Do they surface it in two hours, or disappear for three days?
3. Is the ramp visible? Are they asking better questions in week six than week two? Curve, not level.
4. Is working with them easy? Do they take review feedback without drama, write a clear update, turn up to standup with something to say?

Not one of those requires talent. All four are habits. A fresher who is technically ordinary and strong on all four is rated well. A fresher who is sharp but weak on them is the one who has a difficult review conversation in month four.

Week One: Be Useful, Be Small

You cannot contribute to the architecture. You can do these.

Get your environment working end to end, and write down every step. You will hit undocumented ones — a missing env var, an internal certificate, a database seed that fails. Note each. At the end of the week, turn your notes into an onboarding doc and share it. This is the best first contribution a fresher can make: genuinely useful, costs the team nothing to accept, and it says "I pay attention" louder than anything you could say in standup.

Learn the names and the flow, not just the code. Who owns which service, who reviews what, who to ask about deployments, and — in a service company — the delivery manager and client-side contacts. Then: where tickets come from, what the Jira columns actually mean here, what "done" means, how and when things get deployed, who approves what.

Ask for a tiny first ticket. A typo in a UI string, a log line, a small bug. The point is not the ticket — it is to run the full pipeline once, branch to deploy, while the stakes are near zero.

If You Land on the Bench, or in Training

A large share of Indian freshers start not on a product team but in an induction programme or on the bench waiting for allocation — months of classroom training, or weeks of nothing. People handle it badly in a predictable way: they treat it as a holiday and emerge six months later having learnt nothing.

In training, take the assessments seriously; allocation is often influenced by training performance, and that first allocation shapes the next two years more than most people realise. On the bench, treat it as paid preparation time: build something real, and tell your manager plainly that you want to be staffed.

And if you land on work you did not want — production support, manual testing, an ancient codebase — do it properly for a while first. Asking for a change after three months of visibly good work is a conversation. Asking in week two is a complaint.

How To Ask Questions Without Looking Lost

Freshers get this backwards. They believe that asking exposes them, so they stay silent and lose two days — and it is the two lost days the manager notices, not the question.

The rule: try for 30 to 45 minutes, then ask. Long enough that you have genuinely attempted it and can describe the attempt. Short enough that you have not burned a day.

The format that makes you look competent rather than lost:

"I am trying to get the payment webhook to fire locally. I have checked that the endpoint is registered and the ngrok tunnel is up, and I can see the request reaching the router but it 403s. I think it is the signature check — is there a test secret I should be using instead of the prod one?"

Goal, what you tried, what you observed, a specific hypothesis. It takes the reader twenty seconds and makes you look like someone worth answering. Compare "webhook not working, can you help?" — same question, completely different impression.

Two more habits. Batch the small ones: keep a running note of non-blocking questions and bring five to your 1:1 rather than five interruptions across a day. And ask in the public channel, not the DM — someone else answers faster, the answer gets found by the next fresher, and your manager sees you engaging rather than going quiet.

Write down every answer you receive. Asking the same question twice is the one thing that genuinely irritates senior engineers.

Reading a Large Codebase Without Drowning

Do not try to read it. You will not finish, and you will not retain it.

Follow one request from end to end. Pick a feature that already exists. Start where the request arrives — the route, the controller, the handler — and trace it through services, database calls and the response. One path, properly understood, teaches you the project's conventions faster than a week of browsing.

Use the debugger, not print statements. Put a breakpoint in and step through. Twenty minutes with a debugger beats a day of reading. Most freshers have never used one properly, and it is the biggest single productivity jump available in your first month.

Read the tests, and use git blame. Tests are documentation that cannot go stale — to know what a module is meant to do, its test file tells you more directly than the code. And when something looks bizarre, find the commit that introduced it and read the message and the linked ticket. Half of all "why is this code so weird" questions are answered by a commit message from 2023.

Draw the map yourself. After two weeks, sketch the system — services, databases, queues, external APIs — on paper, then show it to your tech lead and ask what you got wrong. It is one of the highest-value conversations available to you in month one.

Your First Code Review Will Hurt. That Is Normal.

You will open a pull request for a two-day change and receive nineteen comments. Your stomach will drop. Some will feel harsh, because written English in review threads is blunt by nature.

Read this before it happens: the review is about the code, not about you. A senior engineer with ten years of experience still gets comments on their PRs. Volume of feedback tracks how carefully someone read your work, which usually means they are invested in you.

The comments are almost all predictable: naming that made sense to you at 11 p.m. and to nobody else, no error handling on the unhappy path, a query inside a loop, thin tests, a change that breaks an existing convention, and a PR too large for anyone to review properly.

How to respond well: fix things without arguing where the reviewer is right. Where you disagree, ask rather than push back — "I did it this way because of X, does that change things, or is the convention here stronger?" You will be wrong about half the time and learn something both times. If a comment is unclear, ask; guessing produces a second round of the same comment. Never take it to DM to complain about the reviewer, because it travels. Say thanks once.

And keep your PRs small. A 200-line PR gets a real review in twenty minutes. A 2,000-line PR gets a rubber stamp or sits for four days. Small PRs are the fastest way for a fresher to build a reputation for being easy to work with.

Working With a Manager For the First Time

Your manager is not your professor and not your parent. The relationship is simpler than either: they need to know what you are doing, what is blocked, and what you need. Fresher problems with managers come from under-communicating, never the reverse.

Take your 1:1 seriously. Do not turn up empty. Bring three things: what you finished, what is stuck, one question about direction. If you do not get a 1:1, ask for fifteen minutes every two weeks. Almost no manager refuses, and almost no fresher asks.

Send a short written update on Friday — three bullets on what shipped, what is in progress, what is blocked. Four minutes. It quietly makes you the person whose work is legible, and at appraisal time it is the reason your manager can describe your year.

Give estimates honestly. The fresher instinct is to say "one day" to sound capable, then take four and go quiet. Say instead: "I think two days, but I have not worked in this module before, so I will confirm tomorrow afternoon." Nobody minds a revised estimate. Everybody minds silence.

Raise blockers the same day. A problem raised on Monday is a task. The identical problem raised on Thursday is a delay.

The Habits That Decide Your First Appraisal

Appraisals are not decided in appraisal season. They are decided by what your manager can remember and can write down.

Keep a work log from week one. One document. Every Friday, one line per thing you did, with links to PRs and tickets. Four months from now, when the appraisal form asks for your accomplishments, you will have the whole list in front of you instead of trying to remember March. Highest return-per-minute habit in this article.

Finish things. A fresher who completes five small tasks fully is rated above one who started nine interesting ones. Finished includes tested, reviewed, merged and documented.

Own one small area. By month three, aim to be the person who knows one thing best on the team — a screen, a service, a flaky test suite, a deployment script nobody enjoys. Being the go-to person for something small is how a fresher becomes a name rather than a headcount.

Be reliable about the boring things. Standup on time, tickets updated, leave communicated in advance, timesheets filed. In service companies especially, this gets noticed far more than freshers expect.

Do not be the person who only talks in DMs. Visibility is not self-promotion. Answering in a team channel, sharing what you learned debugging something, posting your onboarding doc — that is how people two desks away learn you exist.

What Not To Do In Your First 90 Days

• Do not go silent when stuck. The only genuinely dangerous mistake on this list.
• Do not criticise the codebase. Every legacy system has reasons, and whoever wrote the code you just called messy is probably in the channel.
• Do not compare packages in the team channel. Do it with friends outside work if you must.
• Do not start interviewing elsewhere in month two because the project is boring. A three-month stint on a resume costs more to explain than six more months of patience.
• Do not burn out to prove something. Ninety-hour weeks in month one are noticed for a fortnight and then become your expected baseline.

What To Do This Week

• Start the work log today. One document, one line per task, links included. Friday updates from week one.
• Set the 30-minute rule for yourself and actually keep to it. Write it on a sticky note.
• Pick one existing feature and trace it end to end with a debugger this week.
• Ask your tech lead for fifteen minutes to check the system diagram you drew. Draw it first.
• Write your onboarding notes into a doc and share it, however rough it is.

Ninety days from now, almost nobody will remember your first PR. They will remember whether you were easy to work with, whether you got unstuck, and whether things you said you would do got done. That is a much lower bar than the one in your head — and it is entirely within your control.

(If you are reading this before the first job rather than after it: JobApplyAI is a Chrome extension that drafts a personalised application for a LinkedIn job post, which is the part of the search that eats the most hours.)