First 90 Days at a New Developer Job: How to Pass Probation

The short answer

Probation does not test how brilliant you are. It tests whether people can rely on you: you ramp up quickly, ask good questions, finish tasks and communicate problems clearly. The key to the first 90 days is to find out early what success looks like and check in with your manager regularly.

Week 1: environment and introductions

• Run the project locally. Follow the setup guide, and where it is outdated, fix the README. That is a useful first contribution.
• Get access: repository, task tracker, CI, logs, monitoring, team chats.
• Meet people. Learn who owns what and whom to ask about the backend, infrastructure and product.
• First meeting with your manager. Ask directly: what should I have achieved by the end of probation, and how will it be assessed?

Write down the answers and send your manager a short summary a couple of days later, so you both share the same understanding.

Weeks 2-4: the domain and first tasks

• Use the product as a user. Go through the main flows and see what problems it solves.
• Understand the architecture. Draw a diagram for yourself: services, databases, external integrations, how data flows from request to response.
• Take small tasks: a bug, a minor improvement, a test. The goal is to go through the whole path from ticket to production and learn the process.
• Keep your first pull requests small. They are faster to review and feedback is easier to address.

How to handle code review:

• read comments as information about the team's conventions, not as criticism;
• if you disagree, explain your reasoning calmly and accept the team's decision;
• note recurring comments and check yourself against them before the next PR.

Questions: when to ask

Newcomers usually err one of two ways: staying silent for days or asking about every detail. A practical rule:

1. Try to figure it out yourself — code, documentation, task and commit history.
2. If you make no progress in a reasonable time (say, an hour or two), ask.
3. Frame the question with context: what you are doing, what you already checked, where exactly you are stuck.

Such a question saves colleagues' time and shows you worked on the problem.

Weeks 5-8: consistency and relationships

• Deliver predictably. If an estimate is slipping, say so early, not on the deadline day.
• Review other people's code. Even "why is it done this way?" questions help you learn and bring you into the team.
• Build relationships. Thank those who helped; offer help with what you already know.
• Mid-point check-in with your manager. Ask: what is going well, what should I improve, does my progress match expectations?

Feedback halfway through is more valuable than waiting for the end: there is still time to correct course.

Weeks 9-12: a visible result

• Own a task end to end: from clarifying requirements to deployment and checking it after release.
• Do something useful beyond your tickets if you see an obvious problem: speed up a slow test, fill a documentation gap, automate a manual step. Agree with the team first.
• Prepare a summary for the final meeting: tasks completed, what you learned, what you plan next.

End-of-probation checklist

Common mistakes

• Not clarifying expectations and learning them only at the final meeting.
• Going dark on a task for days without updates.
• Rewriting "bad" code right away without understanding why it is that way.
• Taking on too much to impress and missing deadlines.
• Ignoring the process: code style, PR templates, branching rules.