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

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

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.

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.