First 90 Days of Onboarding - How Performance Perception Gets Shaped

May 2, 2026Career9 min read

The First 90 Days Build a Narrative, Not Performance

Your first three months at a new company feel like a window to prove how good a developer you are. They're not. The first 90 days isn't a performance-measuring period; it's a narrative-building one. Your manager, your teammates, even leadership are writing a story about you: "adapted quickly", "asks questions without hesitation", "first PR was high quality". This narrative becomes the reference point for your six-month performance review, your one-year raise, even your first promotion conversation.

Here's the problem: most developers spend these three months in "learning mode" - quietly reading code, trying to understand the existing system, avoiding risk to not leave a bad impression. This strategy is safe but not strategic. Because everyone is forming an opinion about you during these 90 days, while you're still being passive because you don't feel "ready".

This post covers how to spend the first 90 days strategically, which traps to avoid, and what kind of evidence you should walk into your first performance review with.

What Is the Demo Effect, How Does It Work?

The way new joiners are remembered gets shaped by their first three or four outputs. HR literature calls this anchoring: people forming a reference point with the first data they get and judging everything afterward against it. In software teams, this shows up most concretely as the "demo effect".

The demo effect roughly works like this: when you ship a visible output (a PR, a demo, a small project) to the team in your first three months, the quality of that output becomes your "default quality level". If your work in the next six months falls below this level, the perception becomes "couldn't keep up the early performance"; if you exceed it, it gets read as "started quiet but came out strong".

This effect isn't fair, but it's real. The practical implication: producing one visible output in your first 90 days is more effective than writing very good code quietly for three months. The visible output doesn't have to be big; it can be a small tooling that solves a team pain point, documenting an undocumented flow, or even a checklist that simplifies the onboarding process itself.

What Signal Does Your First PR Send?

Your first PR says far more than you think. It doesn't only answer "can they write code"; it collects half a dozen signals at once: question-asking habits, documentation reading discipline, code style, respect for team conventions, behavior during code review.

The typical advice for the first PR is "find a small bug fix and open it quickly". This is correct but incomplete. The ideal first PR carries three properties:

Limited scope, 50-200 lines. Larger PRs tire reviewers in the first week; smaller ones can be read as "trivial change".
Conformance to the existing code style. Lint rules, naming, file organization - none of it should be forced. The PR should show the team's style, not yours.
Written explanation. Commit message + PR description: what changed, why, how it was tested. Even if the team doesn't follow this structure, you should; the "new but disciplined" signal is strong.

Your first PR doesn't have to be a bug fix - it can be a documentation update. A PR that adds a confusing onboarding step to the docs is both a technical contribution and a culture-fit signal. The same ATS-scanning logic from the CV and LinkedIn guide applies here: your first PR passes through a scanner, and your manager evaluates it within seconds.

Three Conversations With Your Manager

Probably the most neglected part of the first 90 days is the relationship built with your manager. Most new joiners only see their manager in weekly 1:1s, and those meetings are mostly "weekly updates". This is insufficient.

You need to have three different conversations with your manager during the first 90 days:

First conversation - expectation setting. In the first two weeks. Ask: "What does success look like at the end of my first 90 days?" If the answer is vague ("adapt quickly", "learn the code"), push: "Could you give me a concrete example? What level on which topics?" This answer becomes your roadmap for the next three months.

Second conversation - first feedback. Around day 30-45. "Could you give me direct feedback? What am I doing well, where do I need to improve?" The timing matters; ask too early and your manager has no concrete observation, too late and the initial perception has already calcified.

Third conversation - 90-day review. Around day 80-90. "Compared to the goals we set for my first 90 days, how am I doing? Should we set new goals for the next 90?" This conversation is essentially a dry run for the first formal performance review. What you learn here helps you speak the same language as your manager during the actual review six months later.

The 1:1 discipline detailed in the performance review playbook is the foundation for all three of these conversations.

Question-Asking Strategy - What to Ask, How to Ask

New joiners make two kinds of mistakes: either they ask no questions (risk of disappearing) or they ask everything (risk of wasting people's time). The right middle path comes from understanding the cost-benefit balance of asking.

A few practical rules:

First, do 15 minutes of self-research before asking. Look at the documentation, the repository itself, old Slack/Teams messages. If you still can't find it, ask. This pre-research is a visible discipline signal; "I looked here, couldn't find it" sounds very different from "I have no idea".

Second, ask your questions in batches. Asking five questions at once creates less interruption than asking one question at five different times. Collect notes throughout the day, ask them in batch in the evening or weekly 1:1.

Third, ask the right person. Asking a senior engineer about an architectural decision instead of your manager, going directly to HR for an HR issue instead of through your manager - both improves the quality of the answer and your perceived speed.

Fourth, write down everything you ask. Keeping a Q&A log both prevents asking the same question twice and serves as a "what I learned" list during your day-60 manager check-in.

Most developers pay attention to the technical side of the first 90 days; very few to the social side. In reality, social investment has higher long-term returns.

There are three layers:

Immediate team. The 4-8 people you work with directly. Coffee with these people at least once a month, lunch at the same table, casual chat while coding nearby - all building blocks of how your performance is perceived. Whatever these people tell your manager about you, the non-verbal channel is the strongest evaluation source.

Other teams. If you're in backend, then frontend, DevOps, product, design - all of them. This often doesn't happen organically; it requires intent. Saying "could I have a 30-minute chat with someone from the product team to understand the flow" is enough. These conversations both broaden your technical context and help you say "I know that name" later when cross-team projects come up.

Leadership and HR. Direct contact with leadership in the first 90 days is usually limited; but possible at company events, all-hands, or cross-team presentations - be visible. Meeting HR at least once (about your contract, benefits, training budget) pays off later.

When you want to switch teams internally, as detailed in the internal rotation guide, the reference network is the most critical factor. Connections you build in the first 90 days help with rotation requests three years later.

When Do You Bring Up the First Salary Conversation?

Most new joiners avoid bringing up salary in the first year. This is partially reasonable; your contribution is still being measured. But staying entirely passive is the wrong strategy too.

You don't open the salary conversation in the first 90 days, but you build the groundwork. That means:

First, learn the company's raise calendar. Annual or semi-annual? When are performance reviews? Are new joiners included in this cycle, or is the first year skipped? This information comes from HR or teammates who joined earlier.

Second, learn the company's promotion calendar. When are Junior-to-Mid and Mid-to-Senior transitions evaluated, against what criteria? This information comes from the seniors on your team.

Third, start keeping a brag document immediately. First PR, first bug solved, first flow documented - all of it gets used in the first performance review. Writing it retrospectively is hard; if you keep a daily log, you have a 50+ item list by month six.

The natural timing for the first salary conversation is your first performance review (usually 6-12 months in). Until then, you're preparing for the strategies detailed in the annual raise negotiation guide.

The Three Most Common Mistakes

The first-90-day traps repeat in very predictable patterns:

First mistake - staying silent. Thinking "I haven't fully learned yet, let me not voice my opinions" and being quiet in every meeting. This strategy looks safe in the first three months but sets the "this person is passive" perception by month four. Hard to break later. Solution: ask questions from week one (not opinions), bring small suggestions by day 30, voice opinions from day 60.

Second mistake - picking the wrong fight. New joiners sometimes start questioning bad decisions in the existing system right away. "Why is this architecture like this?", "Why is this code so disorganized?" - questions like these get read as "just got here, already criticizing" in the early weeks. The same questions are much stronger when asked at day 60-90 after you've learned the historical context.

Third mistake - overworking. Working evenings, weekends, not taking days off in the first three months looks like a good first impression but lights the fuse on burnout. The cycle described in the developer burnout post usually starts with the overwork habits formed in the first 90 days. Sustainable pace should be set from day one.

After Day 90

When the first 90 days end, three things change: the team stops treating you as "the new person", your manager has formed a concrete opinion about you, and you can see the company's real dynamics.

This turning point is a moment to use. On day 90, do a self-evaluation: what did I learn, what did I ship, who did I meet, what's next? This self-evaluation becomes the map for the next 90 days.

Spending the first 90 days well is like the first three kilometers of a marathon. The pace gets set early, mistakes get hard to recover from, but if it's set up right, the rest of the course is much smoother.

Browse data-driven salary analysis on the Dashboard - knowing the sector average will help when you walk into the performance conversation at the end of your first 90 days with concrete evidence.