# Your First 90 Days as a Software Engineer — Onboarding, Asking Questions, Code Reviews, Standups and Growing Fast

Source: https://skills101.in/learn/career/first-90-days-software-engineer — Skills101 free tutorial (Interview & Career). Updated 2026-11-09.

Getting the offer is the start, not the finish. The first three months decide how your team sees you — and how quickly you get interesting work. The good news: what managers look for in freshers isn't brilliance, it's **reliability, curiosity and communication**.

## 1. The 30-60-90 plan

![First 90 days timeline: days 1 to 30 learn the codebase, tools and people and ship a small fix; days 31 to 60 own small features end to end; days 61 to 90 take a medium feature, improve something nobody asked for, and start helping newer people](https://skills101.in/learn-img/career/first-90-days.svg)

| Phase | Focus | A good sign you're on track |
|---|---|---|
| **Days 1–30: learn** | set up the dev environment, read docs, understand the product, meet the team | your first small PR (bug fix, test, docs) is merged |
| **Days 31–60: contribute** | own small tasks end to end | you deliver tasks with little hand-holding |
| **Days 61–90: own** | medium features, on-call shadowing, improving tooling | teammates start asking *you* about your area |

## 2. Onboarding into a big codebase

A real codebase may have hundreds of thousands of lines. Nobody reads it all. Instead:

- **Run it locally** first; write down every setup step that wasn't documented — then improve the setup doc (a perfect first PR).
- **Follow one request end to end**: from the UI click → API route → service → database and back. Use the debugger and logs.
- Read **tests** to learn how code is supposed to behave.
- Use `git log` / `git blame` to see *why* code changed (the PR description often explains it).
- Keep a personal **notes file**: architecture sketch, commands, who owns what, acronyms.

## 3. Asking good questions

Freshers worry about asking "stupid questions"; managers worry more about people who stay stuck silently for days. The rule of thumb: **try for 30–60 minutes, then ask** — with context.

**Weak:** "Hey, the build is not working."

**Strong:**
> Hi Priya — running `./gradlew test` on a fresh clone fails with `Connection refused: localhost:5432`. I've started Postgres via `docker compose up db` and checked the port is free. Is there an extra step for test DB setup that I'm missing? (Full error in thread.)

What you tried + exact error + specific question = fast, happy answers. Ask in team channels rather than private messages when others might benefit, and **write down the answer** so you never ask twice.

## 4. Pull requests reviewers love

- **Small**: one change, ideally under ~300 lines. Big PRs get slow, shallow reviews.
- **Clear title and description**: what changed, why, how you tested, screenshots for UI, risks.
- **Self-review first**: read your own diff before requesting review; remove debug prints and commented-out code.
- **Tests included** and CI green.
- **Respond to feedback** graciously: "Good catch, fixed in 3f2a1c" — reviews critique code, not you. If you disagree, explain your reasoning politely and be open to being wrong.

```text
Title: Add pagination to GET /api/courses

What: Adds `page` and `size` query params (default 20, max 100) to the course list.
Why: The list endpoint returned all 4,000 courses (~2 MB) and took 1.8 s on mobile.
How tested: Unit tests for edge cases (page 0, size 0, size > 100); manual test in Postman.
Result: Response now ~40 KB / 120 ms.
Risks: Mobile app v2.3 doesn't send params, so it gets page 1 only — confirmed with @mobile-team that v2.4 adds infinite scroll.
```

## 5. Standups and status updates

Daily standups are 15 minutes, not a report to the manager. Keep yours to ~30 seconds:

> **Yesterday:** finished the pagination API, PR is in review. **Today:** address review comments, then start the filter by category. **Blockers:** need access to the staging database — I've raised a ticket with DevOps.

Raise blockers **early**. "I've been stuck for two days" at standup on Friday is a problem; "I'm stuck on X, could someone pair for 15 minutes?" on Tuesday is normal.

## 6. Estimates and deadlines

- Break tasks into small pieces and estimate each; add buffer for testing, review and surprises.
- If you'll miss a deadline, **say so as soon as you know**, with a new estimate and the reason. Surprises at the deadline damage trust far more than an early heads-up.
- "Done" means **merged, tested and deployed** (or whatever your team's definition is) — not "works on my machine".

## 7. When you break something

Everyone breaks production eventually. What matters is the response:

1. **Tell your team immediately** — don't hide it or try to quietly fix it alone.
2. Help **mitigate** (roll back, revert the PR) before finding the root cause.
3. Join the **blameless postmortem**; suggest the guard rail that would have prevented it (a test, a check in CI).

Teams trust people who own mistakes openly. (See the Cloud & DevOps track's monitoring lesson for how incidents work.)

## 8. Professional communication

- Write messages that can be understood **without a meeting**: context, the question, the deadline.
- Use the right channel: quick questions in chat, decisions in the ticket or doc, sensitive topics privately.
- Email/meeting basics: clear subject, short paragraphs, action items with owners, follow up in writing.
- Respect time zones and working hours; avoid "hi" messages with no content.
- Keep commitments small and reliable rather than big and missed.

## 9. Growing fast

- **Keep a brag document**: a running list of what you shipped, problems you solved, numbers, praise. It makes appraisals and resume updates easy.
- Ask your manager in a 1:1: *"What would make you say I'm doing great by the end of the quarter?"*
- Volunteer for unglamorous but valuable work: flaky tests, docs, onboarding guides, small tooling.
- Learn the **business**: who the users are, how the company makes money, which metrics matter.
- Keep learning outside work in small steady doses — and protect your health and sleep. Burning out in year one helps nobody.

## Common mistakes

- Staying stuck silently for days.
- Huge PRs with no description.
- Taking review comments personally.
- Missing deadlines without warning.
- Hiding mistakes.
- Comparing yourself with seniors who have 10 years more context.

## Quick recap

- 30-60-90: learn → contribute → own.
- Onboard by running the app and tracing one request; keep notes; improve docs.
- Ask after 30–60 minutes of trying, with context and the exact error.
- Small, well-described PRs; self-review; welcome feedback.
- Short standups, early blockers, honest estimates, own your mistakes, keep a brag document.


Practice quiz and free certificate: https://skills101.in/learn/career/first-90-days-software-engineer