Your First 90 Days as a Software Engineer: The Complete Playbook

You signed the offer letter. You picked a start date. You bought a new pair of headphones because your old ones had a crackle in the left ear and you didn't want that to be your thing at the new job. Good call.

Now what?

The first 90 days at a new engineering job are the most consequential period in your entire tenure at that company. Research from Enboarder shows that 86% of new hires decide how long they'll stay within their first six months. The first three months are when reputations form, relationships solidify, and opportunities either open up or close off. Get this window right and you'll be the developer who gets the interesting projects, the early promotion conversations, the latitude to push back on bad decisions. Get it wrong and you spend the next two years digging out of a hole.

I've started at new companies more times than I'd like to admit. Some of those transitions went great. Others were rough. The difference was never about technical skill. It was always about having a plan. The engineers I've watched succeed at new jobs all did roughly the same things in roughly the same order. The ones who struggled usually had better credentials but no strategy for the first 90 days.

This is the playbook I wish someone had given me before my first day at my first real engineering job. It's organized into three phases: Days 1 through 30, Days 31 through 60, and Days 61 through 90. Each phase has a clear goal, specific actions, and common traps to avoid. Steal whatever is useful. Ignore whatever doesn't fit your situation.

Why the First 90 Days Matter More Than You Think

There's a practical reason and a psychological reason. The practical reason is that your first 90 days are when management is actively evaluating you. Even at companies that don't do formal probationary periods, your manager is forming opinions during this window. According to AIHR, the average ramp-up time for a new software engineer is 6 to 7 months. If you can demonstrate value in 90 days instead of 7 months, you've just lapped most of your peers.

The psychological reason matters more. There's a concept called the "primacy effect" in cognitive psychology. People weight first impressions disproportionately. Your manager's initial impression of you becomes a lens through which they interpret everything you do afterward. If they see you as competent and proactive in month one, they'll interpret a missed deadline in month four as an anomaly. If they see you as slow and passive in month one, they'll interpret that same missed deadline as confirmation of who you are.

The stakes are real. Data from Shortlister shows that the first 45 days of employment account for up to 20% of all worker turnover. People either click with a new environment fast or they start looking for the exit. Your goal isn't just to survive the first 90 days. It's to build a foundation strong enough that you're still benefiting from it two years later.

Before Day 1: The Pre-Start Checklist

Most engineers show up on day one and wing it. Don't be that person. There's work you can do before you even badge into the building that will put you ahead of everyone else who started that same week.

First, research the tech stack. You already know what languages and frameworks the team uses from the interview process. If you're rusty on any of them, spend a weekend building something small. You don't need to become an expert. You need to be comfortable enough that you're not googling basic syntax on day two while someone watches over your shoulder.

Second, read about the company's product. Not the marketing page. The actual product. Sign up for a free trial if there is one. Read the docs. Use it the way a customer would. When you show up on day one and can ask specific questions about the product instead of generic ones, people notice. It signals that you actually care about what the company does, not just the paycheck.

Third, figure out your commute or your remote setup. This sounds trivial but it's not. Showing up late on day one because you underestimated traffic, or having your video freeze during the first standup because your WiFi is garbage, creates exactly the wrong first impression. Do a dry run. Test everything.

Fourth, prepare your questions. Write down 5 to 10 good questions about the team, the codebase, the deployment process, and the team's biggest challenges. Having a list ready shows initiative and prevents the awkward silence when your onboarding buddy asks, "So, any questions?"

Phase 1: Days 1 Through 30 (Learn and Listen)

The goal for month one is simple: understand the lay of the land and build trust through small wins. You are not here to revolutionize anything. You are not here to point out everything that's wrong. You are here to listen, learn, and prove you can ship something.

Week 1: Orientation and observation. Your first week will probably involve a mix of HR paperwork, tool setup, and onboarding meetings. Use every minute of downtime to explore the codebase. Clone the repo. Get the project running locally. Read through the README and any architecture docs, even if they're outdated. Especially if they're outdated, because that tells you something about the team's culture.

Start a daily log. John Sonmez talks about this in Soft Skills, and it's one of the highest-leverage habits you can build. Every day, write down what you learned, what you worked on, and any questions that came up. You'll use this log for two purposes: first, to compile weekly reports that make your progress visible to your manager, and second, to reference during your first performance review when you need to prove what you accomplished.

Week 2: Ask questions aggressively. There's a window of about two to three weeks where everyone expects you to ask questions. After that, the expectation shifts. Take full advantage of this window. Ask about deployment processes, testing practices, how the team handles incidents, who owns what parts of the codebase, and why certain technical decisions were made.

One technique that works incredibly well: ask your teammates, "What's the thing you wish someone had told you when you started here?" This question surfaces the kind of institutional knowledge that never makes it into documentation. The on-call rotation that everyone dreads. The legacy service that breaks every Thursday. The product manager who changes requirements after sprint planning. This information is gold and nobody will just volunteer it.

Weeks 3 and 4: Ship your first PR. Your primary goal by the end of month one is to have merged code into the production codebase. It doesn't need to be a major feature. A bug fix, a test improvement, a documentation update, or a small quality-of-life improvement all count. The point is to prove to yourself and your team that you can navigate the development workflow from start to finish: pick up a ticket, understand the code, make a change, get it reviewed, get it merged, and see it deployed.

If your team doesn't have an obvious small task for you, look for one yourself. Grep the codebase for TODO comments. Check the bug tracker for issues tagged "good first issue" or "low priority" that have been sitting around. Fix a typo in the docs. The actual impact of the change matters less than the signal it sends: this person can ship.

Month 1 Mistakes That Kill Your Momentum

The most common mistake new engineers make in month one is going quiet. They sit at their desk, read code, and don't say much in standups because they feel like they don't have anything to contribute. This is backwards. The more visible you are in month one, the faster you build trust. Share what you're learning. Ask questions in standups. Post updates in Slack. Your manager can't evaluate what they can't see.

The second most common mistake is trying to prove how smart you are. You'll look at the codebase and see things that could be better. You'll spot patterns that are inefficient, naming conventions that are inconsistent, or architectural choices you disagree with. Keep it to yourself for now. There are almost always reasons behind those decisions that you don't understand yet. The engineer who walks in and immediately starts suggesting changes comes across as arrogant, not helpful. Wait until month two at the earliest before you start proposing improvements, and even then, frame them as questions, not declarations.

Third mistake: not asking for help when you're stuck. There's a sweet spot between asking too quickly and waiting too long. My rule of thumb is 30 minutes. If you've been stuck on something for 30 minutes with no progress, ask someone. Most teams would rather spend 5 minutes unblocking you than have you spin for half a day. When you ask, show what you've already tried. "I'm stuck on X. I've tried A and B, and I think the issue might be C, but I'm not sure. Can you point me in the right direction?" That framing shows you're not being lazy. You're being efficient.

Phase 2: Days 31 Through 60 (Contribute and Connect)

The goal for month two shifts from learning to contributing. By now you should understand the codebase well enough to take on medium-sized tasks without hand-holding. You should also be expanding your network beyond your immediate team.

Own a meaningful piece of work. Talk to your manager about taking ownership of a feature or a project that's appropriately scoped for your experience level. Not the biggest thing on the roadmap, but something real. Something with a deadline, a stakeholder, and visible impact. Shipping a meaningful feature in month two is the clearest signal you can send that you're ramping up fast.

When you take this on, over-communicate. Send your manager a brief weekly update on progress, blockers, and next steps. John Sonmez recommends a Friday weekly report, and I've seen this work at every company I've been at. Your manager almost certainly has too many direct reports and too many things to track. Making it easy for them to know your status makes you look more organized and more productive, even if you're doing the same amount of work as everyone else.

Start reviewing other people's code. This is one of the most underrated moves for a new engineer. By reviewing PRs, you learn the codebase faster than any other method, you build relationships with other engineers, and you establish yourself as someone who contributes to the team's quality bar. Start with smaller PRs and focus on readability, correctness, and test coverage. Don't nitpick style issues in your first few reviews. Leave comments that are helpful and constructive. Ask genuine questions when you don't understand something.

Meet people outside your team. Schedule informal one-on-ones with engineers on adjacent teams, product managers, designers, and anyone else you interact with. A 20-minute coffee chat or virtual call builds more trust than six months of Slack messages. Ask them about their work, their challenges, and how your team's work affects theirs. These relationships will save you when you need cross-team support later. They'll also give you a broader understanding of the business that makes you more valuable than an engineer who only knows their own corner.

Start your "brag document." This is a running list of your accomplishments, organized by quarter. Every feature shipped, every bug fixed, every process improved, every positive piece of feedback received. You'll forget half of these things by the time your performance review comes around. Your brag document makes sure you don't. Start it in month two and update it weekly. By the time you're up for promotion, you'll have an airtight case documented in one place.

The Social Side That Engineers Ignore

I know what you're thinking. "I got hired to write code, not to network." I get it. I used to think the same thing. Then I watched engineer after engineer get passed over for promotions that went to people who were less technically skilled but more connected. The politics aren't optional. They're part of the job.

This doesn't mean you need to become a schmoozer. It means you need to be known. Your manager's manager needs to know your name. The product manager needs to think of you when they have a question about the system. The designer needs to consider you approachable enough to ask for technical feedback. These relationships form in the first 90 days, and they're hard to build retroactively.

Here's what works: eat lunch with different people. Attend the optional team social events. Respond helpfully in Slack channels outside your team's. Offer to demo your work at team meetings. Volunteer for the unglamorous stuff that nobody else wants to do, like updating the runbook or fixing the flaky CI pipeline. The social capital you build from these small actions compounds over time.

One more thing about the social dimension. Find a mentor on your team, even if there's no formal mentorship program. Identify the most senior engineer who seems approachable and ask if you can check in with them biweekly for guidance. Most senior engineers are happy to mentor when asked directly. They're not happy when they have to figure out that you need help on their own. Make it easy for them to help you.

Phase 3: Days 61 Through 90 (Lead and Expand)

By month three, you should be functioning as a fully contributing member of the team. The goal now shifts to demonstrating initiative and starting to lead. This is where you go from "solid hire" to "great hire."

Propose and drive an improvement. You've been observing the team's processes for two months. You've noticed things that could be better. Now is the time to speak up, but do it right. Don't send a Slack message saying "our deployment process is broken." Instead, write a brief document outlining the problem you've observed, the impact it has on the team, and a proposed solution. Bring it to your manager first, then to the broader team if they agree it's worth pursuing. This approach shows maturity. It shows you can identify problems AND propose solutions. That's the difference between a mid-level engineer and a senior one.

Pick an area to go deep. By now you should have a general understanding of most of the codebase. Pick one area and become the person who understands it best. Maybe it's the authentication system, the data pipeline, the CI/CD infrastructure, or the mobile app's state management. Going deep in one area makes you irreplaceable in that domain and gives you a clear identity on the team. "Ask Sarah, she knows the payment system inside out" is exactly the reputation you want.

Have a career conversation with your manager. Around day 75 or 80, schedule a one-on-one specifically about your career trajectory. Share what you've enjoyed working on, where you want to grow, and ask what the path to promotion looks like from your current level. Most engineers never have this conversation explicitly, which means they're guessing about what their manager values. Don't guess. Ask. A good manager will appreciate the directness. A bad manager will give you a vague answer, which is also useful information.

Write something down for the next person. One of the highest-impact things you can do in your first 90 days is improve the onboarding experience for the person who starts after you. Update the README. Write a "getting started" guide for your team's codebase. Document the tribal knowledge you had to piece together from conversations and Slack threads. This accomplishes three things: it makes the team better, it demonstrates leadership, and it cements your own understanding of the system.

The 30/60/90 Day Plan on One Page

If you want the condensed version, here it is:

Days 1 through 30. Learn the codebase. Build relationships with your immediate team. Ship at least one PR. Start a daily log and weekly report. Ask every question you have. Do not suggest changes yet.

Days 31 through 60. Take ownership of a meaningful feature. Start reviewing code. Meet people outside your team. Begin your brag document. Over-communicate progress to your manager. Build social capital through helpfulness.

Days 61 through 90. Propose and drive a team improvement. Go deep on one area of the codebase. Have an explicit career conversation with your manager. Document what you learned for the next person. Start positioning for your first performance review.

Common Traps in the First 90 Days (And How to Avoid Them)

The Perfectionism Trap. Your first PR does not need to be flawless. Ship something imperfect and iterate on the feedback. The engineers who spend three weeks polishing their first PR miss the window to establish themselves as someone who ships. Done beats perfect in month one.

The Lone Wolf Trap. Some engineers think they'll impress people by figuring everything out on their own. This never works. It just means you take three times as long as necessary and miss context that would have changed your approach. Asking for help is a strength, not a weakness. The best engineers I've worked with ask the most questions, not the fewest.

The Comparison Trap. You'll work alongside engineers who seem to know everything. They rattle off acronyms you've never heard. They navigate the codebase without looking anything up. They casually mention the architectural decisions they made three years ago. Remember: they've been here for three years. You've been here for three weeks. The comparison isn't fair and it's not useful. Focus on your own trajectory.

The Scope Creep Trap. When you take on your first feature in month two, define the scope clearly and stick to it. It's tempting to add extra polish, handle edge cases nobody asked for, or refactor adjacent code while you're in the area. Resist. Ship the thing you committed to first. There will always be time for improvements later, but only if you've already established yourself as someone who delivers on time.

The Technology Debate Trap. You might prefer TypeScript over JavaScript, vim over VS Code, or tabs over spaces. Your new team has already made these choices. Arguing about them in your first 90 days accomplishes nothing except marking you as someone who cares more about tools than outcomes. Adopt the team's conventions, build credibility, and revisit these conversations after you've earned the right to be heard.

What to Do If You're Struggling

Not every new job starts smoothly. Maybe the onboarding is disorganized. Maybe the codebase is a nightmare. Maybe your manager is barely available. Maybe you're starting to wonder if you made a mistake accepting this offer.

Take a breath. The first 90 days are hard for everyone, even engineers who have been doing this for 15 years. A rough start doesn't mean you're in the wrong place. It means you're in a new place, and new places are uncomfortable by definition.

If the onboarding is bad, create your own structure. Make a personal Notion doc or Google Doc with sections for each week. Write your own goals. Check in with your manager weekly even if they don't schedule it. Take control of the process even when the process doesn't exist.

If you're struggling technically, be honest about it. Tell your manager you're finding the codebase challenging and ask for recommendations on what to study or who to pair with. Most managers would rather hear this in week three than discover it in week twelve. Early transparency gives them the chance to help you. Late transparency makes them question your judgment.

If the job itself is wrong, give it the full 90 days before making a decision. I've seen many engineers want to quit in month one and end up loving the job by month six. The first 90 days are not representative of what the job actually feels like long-term. Bad weeks happen. Bad months happen. If you're still miserable at day 90 after genuinely trying, then start thinking about next steps. But don't bail at the first sign of difficulty. That pattern will follow you to every job.

Remote vs. In-Office: Adjusting the Playbook

If you're starting a remote position, every part of this playbook still applies, but the execution changes. The social interactions that happen naturally in an office need to be manufactured remotely.

Turn your camera on for every meeting in the first 90 days. No exceptions. People form stronger connections when they can see your face, and being a black rectangle on Zoom while everyone else has their camera on creates a subtle distance that's hard to overcome.

Over-communicate in writing. In an office, your manager can see you working. Remotely, they can't. Your Slack messages, PR descriptions, and weekly updates are the only evidence of your work. Make them detailed. Share progress proactively. Don't wait to be asked.

Schedule virtual coffee chats with every person on your team in the first two weeks. Fifteen minutes each. No agenda, just getting to know each other. Then expand to people on adjacent teams in weeks three and four. This replaces the hallway conversations and lunch invitations that happen automatically in an office. It feels awkward to schedule a "get to know you" call with a stranger. Do it anyway. Everyone who's worked remotely understands why these calls exist, and nobody will think it's weird.

If your company has occasional in-person events like off-sites, team summits, or conferences, attend all of them in your first year. The ROI of face time in a remote company is enormous. Two days of in-person interaction can build more trust than two months of Slack messages.

The Weekly Report That Changes Everything

I learned this from John Sonmez and it's been the single highest-ROI career habit I've ever adopted. Every Friday afternoon, send your manager a brief email or Slack message summarizing your week. Include three things: what you accomplished this week, what you're planning next week, and any blockers or concerns.

That's it. Five to ten minutes of writing. Here's why it works:

Your manager has too many things to track. They're in meetings most of the day. They have five to ten direct reports, each working on different things. Your weekly report makes it effortless for them to stay informed about your progress. When their boss asks "How's the new hire doing?", your manager has a ready answer because you've been handing them that answer every Friday.

It also creates a paper trail. When performance review time comes, you have 52 weekly summaries documenting exactly what you shipped, what challenges you overcame, and how you grew. Most engineers scramble to remember what they did in the last six months. You won't have that problem.

Start this habit in your first week. When you send the first one, include a brief note explaining that you want to make it easy for your manager to stay informed and that you plan to send these weekly. I've never had a manager react negatively to this. Most are genuinely grateful. Some will forward your reports to their own bosses, which gives you visibility two levels up without any self-promotion on your part.

Day 91 and Beyond

If you've followed this playbook, by day 91 you should be in a strong position. You've shipped code. You've built relationships. You've demonstrated initiative. Your manager knows your name, your work, and your ambitions. You've got a brag document tracking your wins and a weekly report habit that keeps you visible.

The work doesn't stop here, obviously. But the foundation is set. The hardest part of any new job is the beginning, and you've handled it with a plan instead of hoping for the best.

From day 91 forward, keep doing the things that worked. Keep the weekly reports going. Keep updating your brag document. Keep meeting people across the organization. Start thinking about what you want your next level to look like and align your work accordingly.

The engineers who build remarkable careers don't do it by accident. They do it by treating every new chapter with intention. Your first 90 days are just the beginning of a chapter that could define the next several years of your career. Take it seriously. Plan it deliberately. Execute it consistently.

And when the next new hire starts and they're sitting at their desk looking overwhelmed and unsure, be the person who walks over and says, "Hey, let me show you around. I've got a few tips that might help."

That's what rockstar developers do.