Starting a new job as a junior engineer comes with a specific anxiety: you’ve been hired, which means someone believes you’re capable, but you don’t yet know enough about the codebase, the team, or the domain to actually demonstrate it. The temptation is to overcompensate - to work longer hours, to accept every task without asking questions, to avoid raising concerns because you don’t feel you’ve earned the right.

This strategy usually backfires. The engineers who build credibility fastest in their first three months are the ones who ask good questions, show their work, and ship things - not the ones who try to look like they know everything.

The First Two Weeks: Listen Before You Fix

New engineers often arrive with observations that turn into suggestions: “this architecture seems unnecessarily complex,” “this test coverage looks low,” “this API design is inconsistent.” These observations are sometimes correct. The mistake is voicing them before you understand why things are the way they are.

Systems have history. That “unnecessarily complex” architecture might be the result of a painful incident six months ago. The low test coverage might be a known debt that the team has intentionally deprioritized in favor of other work. The “inconsistent” API might have design constraints you don’t know about.

In the first two weeks, prioritize understanding over evaluation. Ask questions that build context: “how did this come to be?” “what’s the thinking behind this approach?” “what problems did this solve?” You’ll learn more, you’ll appear thoughtful rather than critical, and when you do eventually have suggestions, they’ll be informed by reality.

What Good Onboarding Looks Like

Good onboarding isn’t just reading documentation. It’s doing work that gives you contact with the actual system. The most effective things to focus on:

Set up the local dev environment yourself. Don’t wait for someone to sit with you through it. Follow the README, notice where it breaks, fix it if you can, and document what was unclear. A pull request that improves the onboarding docs is a valuable first contribution and signals that you pay attention.

Read recent pull requests. Not to evaluate them - to understand the team’s code style, the review culture, and what problems they’ve been working on. This is faster than reading documentation and more current.

Find a small, real task and ship it. Not a toy task created specifically for onboarding - a real ticket with real consequences. The goal isn’t to impress anyone with complexity. The goal is to get familiar with the full cycle: pick up a ticket, understand the context, write the code, get it reviewed, merge it, see it deploy. Even a trivial bug fix teaches you more about the workflow than a week of reading.

Have a conversation with someone outside your immediate team. A product manager, a designer, someone in customer support. Understanding how your work connects to the product and the users is the context that makes technical decisions make sense.

The Questions Worth Asking

Junior engineers often under-ask, worried about seeming incompetent. The opposite is more damaging: working from wrong assumptions and producing work that misses the point.

There’s a useful distinction between questions that show you haven’t tried to figure something out, and questions that show you’ve tried and gotten stuck. “How does authentication work?” is a lazy question when you could read the code. “I’ve read the auth middleware and I understand that it validates JWTs, but I’m not sure how the role-based access control fits in - is that happening in the middleware or somewhere else?” is a good question.

Questions to ask your manager in the first weeks:

• What does success look like in this role after six months?
• What are the most important things for me to understand about the codebase?
• What’s the team currently most focused on, and where does my work fit?
• What are the things most junior engineers on this team get wrong early on?

The last question is the most valuable. Most managers have seen the same patterns repeatedly and will tell you directly if you ask.

Feedback Loops

The best thing you can do for your growth as a junior engineer is get feedback frequently. Not at performance review time. Not when something goes wrong. Regularly, by asking for it.

After you ship something, ask your reviewer: “Was there anything in this PR I should approach differently next time?” After a technical decision you weren’t sure about: “I chose X because Y - does that reasoning hold up, or is there something I’m missing?”

Most senior engineers don’t volunteer detailed feedback unless asked. They’re busy, and they assume you’ll ask if you want it. Ask.

What Not to Worry About

The anxiety of not knowing enough is normal and persistent - even senior engineers feel it in new domains. The difference is they’ve learned to work with uncertainty rather than freeze in it. You will too, but it takes time.

Don’t worry about having opinions on everything yet. You’re new. You’re supposed to be learning. The pressure to perform authority you don’t have is a trap.

Don’t measure yourself against the most senior person on the team. They have years of context you don’t have. The relevant comparison is whether you’re improving, whether you’re shipping, and whether the team trusts you more this month than last month.

Don’t optimize for looking busy. Shipping something real, however small, is worth more than a week of visible activity that produces nothing.

The 90-Day Mark

By the end of three months, you should be able to:

• Pick up a task, figure out where to make the change, and do it with reasonable independence
• Navigate the codebase without someone holding your hand
• Have opinions about the technical work, grounded in actual experience with the system
• Know who to ask when you’re stuck

You probably won’t be fast. You’ll still be asking questions. That’s fine. The point isn’t to stop learning - it’s to demonstrate that you’re capable of contributing without constant supervision.

The engineers who struggle in their first 90 days usually have one of two problems: they don’t ask for help when they need it (and spend three days stuck on something a five-minute conversation would have resolved), or they can’t ship anything without it being perfect (and spend the first month polishing a PR that nobody is waiting for).

Ship things. Ask questions. Read the code. Show up consistently. Three months is not that long.