What is expected of a junior developer in the first 90 days?

Far less technical brilliance and far more learning velocity than juniors assume. Realistic team expectations by month: month one - environment set up, codebase partially navigable, small tickets shipped with heavy review, questions asked well; month two - medium tickets with less hand-holding, code reviews responded to quickly, patterns of the team absorbed; month three - a small feature owned end to end, review comments declining in severity, teammates trusting your updates. Nobody expects architectural insight or flawless code. What managers actually watch: do you improve week over week, do you communicate when stuck, and can your work be trusted at the size you’re given? Those three are the whole exam.

Is it normal to feel lost in your first developer job?

It is close to universal, and knowing the mechanics helps. You trained on projects you built from scratch and understood totally; you now face hundreds of thousands of lines you didn’t write, tooling nobody documented, and acronyms with in-house meanings. Feeling lost in that environment is not a skills gap - it is the defining texture of joining ANY codebase, and seniors feel a version of it every job change. The measurable comfort: juniors who track their questions notice the repeat rate collapsing within weeks. Treat the fog as terrain, keep a personal log of what each confusing thing turned out to be, and expect the first "I actually know how this system works" moment somewhere in month two or three.

How do I deal with imposter syndrome as a new developer?

Three re-framings that survive contact with reality. First, the comparison error: you are measuring your inside experience (confusion, googling basics) against seniors’ outside performance (confident-looking output) - but they google constantly too; the difference is they stopped interpreting it as evidence of fraud. Second, the hired-for-a-reason fact: your team interviewed dozens and chose you knowing exactly how junior you were; the expectation gap you fear mostly exists in your head - their bar for you is learning velocity, which you control. Third, the paper trail: keep a "done" log of every shipped ticket, fixed bug, and learned system - imposter feelings argue from vibes, and the log argues back with data. If month three still feels like month one, that’s a real signal to discuss support with your manager; until then, it’s just the standard weather.

What habits make a junior developer stand out?

Five, none of which require brilliance. Ask questions with evidence of effort attached ("I tried X and Y, saw Z - what am I missing?" beats "how do I do this?" in every culture). Write things down - the junior with notes stops asking repeats, and their onboarding doc often becomes the team’s. Make your work visible without being asked: short, honest progress updates build the trust that gets you bigger tickets. Volunteer for the unglamorous - flaky tests, small bug tickets, documentation - because they teach the codebase fastest and mark you as a contributor, not a passenger. And close loops: when someone reviews your code or answers your question, they see the fix land and hear it worked. Trajectory, not talent, is what gets juniors promoted - and every one of these habits is trajectory made visible.

All posts

Careers · Junior developers · On the job

Your first 90 days: everyone struggles. Here’s the map.

The internet is full of advice for getting the developer job and strangely silent about surviving it - which is why the first months blindside so many new juniors. Here is the honest version: what the fog actually feels like, what your team really expects (it is not brilliance), and the small habits that separate juniors who compound from juniors who stall. Written for the offer-in-hand reader, and worth reading a stage early.

Deric Yee Updated 25 August 2026 10 min read

A team of developers working together at laptops

The shock nobody warns you about

Every project you built before this job, you built from scratch - you knew every file because you created every file. Day one of employment inverts that completely: you are dropped into hundreds of thousands of lines you did not write, wired together by decisions made years ago for reasons nobody fully remembers, running on internal tooling with no tutorial. The skill this demands - navigating and modifying other people’s systems - is the single largest gap between learning and employment, and almost no one trains it deliberately. So the first fog is not evidence you learned the wrong things; it is the standard entry experience, reported by essentially every developer alive, seniors on job-change included. What varies is how people interpret it: as a verdict (“I’m not ready”) or as terrain (“this is what week two of any codebase feels like”). The second interpretation is both more accurate and more useful - and teams quietly watch for it, because calm-in-fog is the first professional signal a junior sends.

The practical countermeasure is a personal system, started day one: a running log of every confusing thing and what it turned out to be- the acronyms, the deploy steps, the who-owns-what. It converts fog into a burn-down chart (the repeat rate collapses visibly within weeks, which is the antidote to feeling stuck), it stops you re-asking answered questions, and - a pattern we see with our own graduates - the junior’s private notes have a way of becoming the team’s official onboarding doc, which is a remarkable first-quarter contribution from the newest person in the room.

What your team is actually grading

Juniors assume they are being graded on code quality and speed. Managers, asked directly, grade three different things. Learning velocity: is week six visibly better than week two - smaller review comments, bigger tickets, fewer repeated mistakes? This is the core metric, and it is fully in your control. Communication under uncertainty:when stuck, do you vanish for two silent days (the classic junior failure - the silence is always read as worse than the stuckness), or do you surface it early with evidence of effort attached? The formula that works everywhere: timebox the struggle - thirty to sixty minutes of genuine attempts - then ask with your attempts shown: “I tried X and Y, saw Z, what am I missing?” That question builds your reputation; silence spends it. And trustworthiness at current size: can the ticket you are given be considered handled - tested, honestly described in the pull request, loops closed? Trust at small size is what buys bigger sizes; that ratchet is the entire junior-to-mid trajectory.

AI tools on the job: the junior’s edition

You arrive AI-fluent - it is likely part of why you were hired, and the premium band you were hired into (RM 6,000–9,000/month for AI-capable juniors) prices exactly that fluency. The workplace adds two rules the classroom didn’t. Rule one: the team’s norms outrank your habits - which tools are licensed, what code may be pasted where, which zones are AI-restricted; learn them in week one, because a compliance mistake with company code is a genuinely bad early story. Rule two: your name is on the pull request, not the model’s.AI will happily produce code above your understanding level, and submitting it creates review conversations you cannot survive - the workplace version of the vibe-coding trap we’ve written about since before you were hired. The never-submit-what-you-can’t-explain discipline is not just safety - done consistently, it becomes your reputation. Meanwhile the best junior-specific AI use case is the one nobody markets: comprehension- pasting the confusing legacy function and asking for a plain-English explanation, using the model as a tireless codebase tour guide. It compresses exactly the navigating-other-people’s-code gap that makes the first months hard.

The 90-day arc, month by month

Month one - absorb: environment running, first small tickets shipped under heavy review, question log growing, names and systems mapped. A fine month one looks unimpressive from outside; it is measured in fog cleared, not features shipped. Month two - contribute: medium tickets with less hand-holding, review comments shrinking from structural to stylistic, the first moment you answer someone else’s question. This is also when imposter feelings peak - competence is rising faster than confidence, a documented lag rather than a warning sign. Month three - own:a small feature end to end: clarifying the requirement, building, testing, shipping, and handling the bug report that follows. Somewhere in this month the codebase flips from hostile territory to workplace, and the habits above - evidence-based questions, visible progress, closed loops, the done-log - decide whether your trajectory reads as “steady” or “fast”. Fast-trajectory juniors reach mid-level bands (RM 7,000–13,000 in Malaysia) in two to three years; the ratchet starts in these 90 days.

And if you are reading this a stage early - offer not yet in hand - notice how much of the survival guide is trainable in advance: working in unfamiliar code, explaining your decisions under review, collaborating through pull requests and standups, AI-assisted building with explain-everything discipline. That is not accidental; it is the shape of any training worth paying for, and it is deliberately the shape of ours - mentor review, defence interviews, live-remote team rhythm from week one. The zero-cost preview is the free trial, and the getting-hired half of the journey is mapped in the no-experience playbook.

FAQ

What is expected of a junior developer in the first 90 days?
Far less technical brilliance and far more learning velocity than juniors assume. Realistic team expectations by month: month one - environment set up, codebase partially navigable, small tickets shipped with heavy review, questions asked well; month two - medium tickets with less hand-holding, code reviews responded to quickly, patterns of the team absorbed; month three - a small feature owned end to end, review comments declining in severity, teammates trusting your updates. Nobody expects architectural insight or flawless code. What managers actually watch: do you improve week over week, do you communicate when stuck, and can your work be trusted at the size you’re given? Those three are the whole exam.
Is it normal to feel lost in your first developer job?
It is close to universal, and knowing the mechanics helps. You trained on projects you built from scratch and understood totally; you now face hundreds of thousands of lines you didn’t write, tooling nobody documented, and acronyms with in-house meanings. Feeling lost in that environment is not a skills gap - it is the defining texture of joining ANY codebase, and seniors feel a version of it every job change. The measurable comfort: juniors who track their questions notice the repeat rate collapsing within weeks. Treat the fog as terrain, keep a personal log of what each confusing thing turned out to be, and expect the first "I actually know how this system works" moment somewhere in month two or three.
How should a junior developer use AI tools at work?
Follow the team’s norms first - every 2026 team has them, from mandated tools to restricted zones - and inside those norms, use AI the way you (should have) trained: draft with it, but review everything you submit as if a hostile interviewer will probe it, because your name is on the pull request, not the model’s. The junior-specific trap: AI can produce code above your understanding level, and submitting it creates review conversations you cannot survive ("why did you choose this approach?"). The discipline that compounds: never submit what you can’t explain, use AI aggressively to UNDERSTAND the existing codebase (paste confusing functions, ask for plain-English explanations - the single best junior use case), and let your explain-everything standard become your reputation.
How do I deal with imposter syndrome as a new developer?
Three re-framings that survive contact with reality. First, the comparison error: you are measuring your inside experience (confusion, googling basics) against seniors’ outside performance (confident-looking output) - but they google constantly too; the difference is they stopped interpreting it as evidence of fraud. Second, the hired-for-a-reason fact: your team interviewed dozens and chose you knowing exactly how junior you were; the expectation gap you fear mostly exists in your head - their bar for you is learning velocity, which you control. Third, the paper trail: keep a "done" log of every shipped ticket, fixed bug, and learned system - imposter feelings argue from vibes, and the log argues back with data. If month three still feels like month one, that’s a real signal to discuss support with your manager; until then, it’s just the standard weather.
What habits make a junior developer stand out?
Five, none of which require brilliance. Ask questions with evidence of effort attached ("I tried X and Y, saw Z - what am I missing?" beats "how do I do this?" in every culture). Write things down - the junior with notes stops asking repeats, and their onboarding doc often becomes the team’s. Make your work visible without being asked: short, honest progress updates build the trust that gets you bigger tickets. Volunteer for the unglamorous - flaky tests, small bug tickets, documentation - because they teach the codebase fastest and mark you as a contributor, not a passenger. And close loops: when someone reviews your code or answers your question, they see the fix land and hear it worked. Trajectory, not talent, is what gets juniors promoted - and every one of these habits is trajectory made visible.

Back to all posts The junior developer career guide →

Train for the job, not just the offer.
The first 90 days start in the classroom.

Mentor review, defence interviews, and a live-remote team rhythm from week one - the programme is shaped like the job on purpose. Preview it free: six real projects, a live instructor session, one signup, no card.

Start the free trial Get the offer first