What you'll learn
Quick Answer
You are not expected to be productive in month one. Ship something small early, ask questions freely, write down what you learn, and become progressively less dependent. Being easy to work with matters as much as technical output.
What is actually expected
New developers routinely assume they should be delivering meaningful work in week one, then feel like a fraud when they are not. The real expectations are much lower and different in kind.
In practice, teams expect: month one to be setup, reading code and small fixes; month two to include real tasks with support; month three to show you working through a feature with occasional guidance.
Almost every company treats a graduate's first six months as an investment, not a return. Your manager knows this. The person worried you are too slow is you.
What they are assessing is trajectory: are you asking better questions than last month, needing less hand-holding, and finishing what you start? Those matter far more than lines of code.
The first two weeks
Get something to production early, however small. A copy fix, a small bug, a documentation correction. The point is not the change — it is walking the whole path: local setup, branch, pull request, review, merge, deploy. That path is where most of the friction lives, and doing it once removes a lot of anxiety.
Good teams assign exactly this deliberately. If yours has not, ask for one.
Keep a document of everything. Setup steps that were not in the README, who owns which system, vocabulary and acronyms, and how to run the tests. You will forget, and this becomes genuinely valuable.
Then improve the onboarding docs with what you learned. It is a real contribution nobody else can make — after three months you will no longer notice what was confusing.
Read code deliberately. Do not attempt the whole codebase. Follow one request end to end, from the route to the database and back. One complete path teaches more than skimming everything.
Asking questions without feeling like a burden
The most common junior mistake is staying stuck silently for two days to avoid looking incapable. That is precisely what damages the impression you are protecting.
Your time is the cheapest on the team. Two hours of a senior's attention over three months costs the company far less than you being stuck repeatedly.
Practical approach: timebox it. Thirty to sixty minutes of genuine attempt, then ask — with what you tried included, so it is a good question rather than a request to debug for you. See asking good questions.
Batch small questions rather than interrupting constantly, unless you are blocked.
Do not ask the same thing twice. This is what your notes are for, and it is the thing people quietly notice.
Say when you are blocked, immediately — in standup, in the ticket, wherever the team looks. Surfacing a blocker is doing your job, not admitting failure.
What makes a good impression
Mostly unglamorous and entirely within your control.
- Do what you said you would. Reliability is rarer than talent and much more noticed.
- Update your ticket status. Small, and it is how the team knows what is happening without asking.
- Take review feedback well. Comments are about the code. Responding thoughtfully rather than defensively shapes how people experience working with you — see pull requests.
- Finish things. A completed small task beats three started ones.
- Write down decisions. In the ticket or the pull request. It helps everyone and demonstrates you think beyond the immediate change.
- Be visible in the right way. A short written update on what you did and what is next costs two minutes and prevents the impression that nothing is happening — especially if you work remotely.
On feeling out of your depth
Nearly every new developer experiences it, including ones who are doing well. Some specific things help.
Recognise that everyone is looking things up. The senior engineer you are comparing yourself to is also searching for syntax. They have more context and pattern recognition, both of which come from time rather than talent.
Compare against yourself last month, not against a colleague with five years of experience. Your notes make that concrete — reading what confused you in week one is genuinely reassuring.
Ask for feedback explicitly around the one and three month marks. "What should I be doing differently?" gets you real information instead of guessing. Most managers will not volunteer it unless something is wrong.
And keep it in proportion: your first job is where you learn to be a professional developer. Nobody arrives already being one, and the gap you feel is the thing the next two years are for. See burnout if it stops being a feeling and starts being persistent.