Your First 90 Days: What Nobody Tells Freshers About Their First Tech Job
The skills that get you hired are not the skills that make you useful in month two. Most freshers spend their first quarter quietly panicking about the wrong things. Here is what the first ninety days actually demand, and how to spend them so that month four is easier.
A student I had worked with for two years messaged me six weeks after joining her first job. She had cleared a hard process at a good company and she was, in her words, "completely useless". She had not shipped anything. She had spent three days on a task her manager said should take four hours. She was afraid to ask questions in the team channel because everyone else's questions sounded more informed than hers. She was seriously wondering whether the company had made a mistake.
Nothing about her situation was unusual. She was, in fact, doing well. But nobody had told her what the first ninety days are supposed to look like, so she was measuring herself against an imaginary standard and losing.
This is the part of the journey almost nobody writes about. There is an enormous amount of advice about getting the offer and almost none about the twelve weeks that follow it — which is a strange gap, because those twelve weeks shape your reputation in the team, and reputation compounds faster than skill early on.
The transition nobody prepares you for
College optimises for individual output on well-defined problems with known answers and a deadline someone else set. Work is almost the inverse: collaborative output on badly-defined problems with no known answer, where a large part of the job is figuring out what the problem actually is and who else is affected by it.
That inversion is why capable students feel incompetent in month one. The skills that got you the offer — solving stated problems fast and alone — are not the skills that make you useful. The new skills are reading an unfamiliar codebase, asking precise questions, working out who owns what, and shipping small changes safely. All of them are learnable, and none of them were on any syllabus you have seen.
There is a second shock that catches students who arrive from an intense placement season: nobody is grading you weekly. There is no marksheet. Feedback is sparse and often indirect, and freshers who need external confirmation to feel secure find the silence harder than the work. Learn to read the real signals — are you being given the next task, are your reviews getting shorter, are people asking your opinion — rather than waiting for a score.
Is it normal to feel useless in the first month?
Yes, and near-universally so. Every senior engineer you will meet felt exactly this, and most of them remember it vividly.
Here is the honest accounting from the company's side. Almost no organisation expects meaningful independent output from a fresher in the first month. What they expect is that you set up your environment, understand what the team owns, make a few tiny changes, and start absorbing context. The mental model most managers carry is roughly: month one, learning the terrain; month two, small independent tasks; month three, a real piece of work with support. If you are somewhere near that, you are on track — even if it feels like nothing.
The feeling comes from an information gap. Your teammates have two years of context on this codebase. You have three weeks. Their fluency looks like intelligence and is actually just accumulated exposure, and you are comparing your day thirty to their day seven hundred.
| Period | What you should be doing | What "on track" looks like |
|---|---|---|
| Days 1–30 | Environment set up, reading code, meeting people, tiny fixes | You can describe what your team owns and who to ask about what |
| Days 31–60 | Small independent tasks, first real code reviews, asking better questions | You ship small changes without step-by-step guidance |
| Days 61–90 | One meaningful piece of work, start helping others, spot process gaps | Your manager can hand you something and not check daily |
Print that mentally and stop measuring yourself against the person who joined three years ago.
When can I ask for help without looking incompetent?
This is the question that costs freshers the most time, and the anxiety around it is almost always disproportionate. The reality is that senior engineers get irritated by two things — being asked a question you could have answered in three minutes yourself, and discovering you were silently stuck for two days. Not by questions in general.
The rule that solves both is a time box plus a structured ask. Give yourself thirty to sixty minutes of genuine independent effort: read the code, search the internal documentation, check the repository history, try one thing. Then ask, and ask in a form that makes helping you cheap.
A good question has four parts: what you are trying to do, what you tried, what happened, and what you think might be going on. "I'm trying to get the staging job to pick up the new config. I've updated the file and redeployed, but it still reads the old values. I checked the logs and it looks like it may be cached at startup — is there a step I'm missing?" That takes ninety seconds to answer and makes you look careful.
Compare it with "hi, the config isn't working, can you help?", which requires the other person to run the entire investigation you should have started. The difference is not intelligence. It is preparation, and it is the single most reputation-forming habit of your first quarter.
Ask in the public team channel rather than direct messages where the culture allows it. It feels more exposed and is better: someone other than your intended target usually answers faster, and the answer becomes searchable for the next person.
The first pull request, and what code review really is
Your first code review will come back with more comments than you expected, and it will sting. Read them twice before responding, because the first reading is emotional and the second is informational.
Code review at work is not a judgement on you. It is how teams maintain a shared standard and spread context, and senior engineers get plenty of comments on their own changes too. What juniors get wrong is treating review as a verdict — either arguing every point defensively or accepting every suggestion without understanding it. Both are worse than the middle path: implement what you understand, and ask about what you do not. "I've made this change; on the second point, I wasn't sure why the current approach is a problem — could you explain?" is a completely normal thing to write, and it converts a correction into learning.
Keep your changes small. A fresher's fifty-line pull request gets reviewed in an hour; a nine-hundred-line one sits for three days and comes back with structural objections that undo the week. Small changes ship, and shipping is how you build the confidence that makes the next change easier.
Learning the codebase without drowning
Do not try to understand everything. It is not possible, and attempting it is how the first month vanishes without a single commit.
Learn along the path of the work instead. Take the small task you have been given, follow the code that touches it from entry point to database and back, and ignore the rest. Do that four or five times with different tasks and you will have a working map of the parts that matter, assembled from real paths rather than an imaginary complete picture.
Two habits multiply this. First, keep your own notes — a running file of what you learn, the commands you need, the names of things, who owns which service. Everyone who does this says it saved them; almost nobody does it. Second, read recent pull requests from your teammates even when they are not yours. Fifteen minutes a day of that teaches you the team's conventions and current concerns faster than any documentation.
If your team has documentation, use it and then improve it. A fresher who fixes the setup guide that was wrong on step four has performed a genuine service, has proved they were paying attention, and has done something visible in a period where visible things are scarce.
Reputation is built early, on things that are not code
In the first quarter, the strongest signals you send have very little to do with technical ability, because nobody expects much of that yet.
Reliability is the biggest one. Doing what you said you would do, by when you said, and saying so early when you cannot. A fresher who flags on Tuesday that Thursday's task is at risk is more valuable than one who delivers a surprise on Thursday evening. Nobody minds a slipped estimate; everybody minds a silent one.
Attention is second. Turning up to meetings having read the thread, taking notes, not asking a question that was answered five minutes ago. This is low effort and startlingly rare.
Follow-through on feedback is third and the most powerful. If someone tells you your commit messages are unclear, and your next twenty commit messages are clear, you have demonstrated the trait every team wants most in a junior: that guidance sticks. Managers notice this immediately and it shapes what they trust you with next.
None of this requires you to be the strongest engineer in the room, which you will not be. It requires you to be easy to work with, which you can be from day one.
Probation, expectations, and the conversation to ask for
Most fresher roles have a probation period of three to six months, and most companies handle it as a formality. Even so, treat the terms as information rather than something to be anxious about — the same close reading we recommend for any fresher offer letter applies to what your confirmation actually depends on.
The move worth making is asking your manager, in week two or three, a version of this question: "What would a successful first three months look like for someone in my position?" It is a simple question, freshers rarely ask it, and the answer converts a vague fear into a checklist. Ask again at the sixty-day mark for a short feedback conversation — not a formal review, just fifteen minutes on what is going well and what you should change. Managers respond well to it, and it removes the guesswork about whether you are doing fine.
If a training period or a bench phase means you are not yet on a real team, use it deliberately rather than drifting: build something small with the company's stack, read internal documentation, and get to know people in the teams you would like to join. The freshers who get placed on good projects after training are usually the ones who were visibly doing something during it.
Pace, and not burning the first year
The last thing, and the one that gets ignored. New joiners frequently overcompensate for feeling slow by working late every day, and by month four they are tired, resentful, and no faster. The learning curve is steep because it is a curve, not because you are behind on it, and exhaustion does not shorten it.
Protect your evenings at least a few days a week. Sleep properly, because absorbing a large volume of new context is exactly the kind of work that sleep consolidates. Keep one thing in your life that is not this job. The habits that carried you through placement season without burning out matter more now, not less, because this is a marathon with no results day at the end of it.
And keep some perspective on where this sits in the arc. The first job is a place to learn how work works, and the question of whether it is the right long-term seat is one you cannot answer in month two — you will have a much better view at month twelve, which is when the package versus momentum question becomes worth revisiting properly.
What happened to the student who felt useless
She asked her manager the "what does success look like" question in week eight, which was later than ideal and still transformative. The answer was that he expected her to be shipping small changes independently by month three and that she was already doing it. The three-day task he had estimated at four hours turned out to involve a service nobody on the team fully understood, and two other engineers had lost days to the same thing.
By month five she was the person who knew that service best, because she was the one who had been forced to read it properly. That is how it usually goes. The thing that makes you feel incompetent in month two is very often the thing you end up owning in month six.
Starting your first job and not sure what's expected? Talk to a Career Call counsellor. We'll help you set up the first ninety days deliberately — the questions to ask, the habits to build, and the signals that tell you you're on track.