The First 90 Days: A Step-by-Step Playbook for Software Engineers
You’ve been in the trenches.
You polished your resume until it gleamed. You beefed up your skills and certifications.
You tuned up your GitHub, studied system design questions until they blurred together, and hit “apply” more times than you care to count.
You braved the interview gauntlet—whiteboards, take-homes, awkward pauses, and all. You leveled up your skills and kept your cool.
And then… the offer letter came. You landed the job! Now the real work begins.
Because while hiring is hard, onboarding effectively is even harder. This is where you transition from candidate to contributor, and where first impressions become lasting ones. Your first 90 days will lay the groundwork for everything that follows.
In this playbook, I’ll walk you through how to hit the ground running as a new software engineer, with practical advice from two seasoned tech pros who’ve been there, done that, and know what works. But first, let’s start with a clear-eyed look at what it actually means to be a software engineer today.
What is a Software Engineer?
Oh gosh, where do we begin? Seriously, you could write a book on this topic, in part because the term is sometimes used as a catch-all for multiple potential roles that span all phases of the software development lifecycle. As a result, other titles are potentially relevant here, such as developer or programmer. We’re using software engineer' as an umbrella term.
Here’s a succinct definition of software engineering, via Michigan Technological University, to keep us on track: “Software engineering is the branch of computer science that deals with the design, development, testing, and maintenance of software applications. Software engineers apply engineering principles and knowledge of programming languages to build software solutions for end users.”
If you distill that down into the simplest of terms, it sounds something like this: software engineers build digital things for people and machines to use. Instead of using a hammer and nails, they use code, along with an assortment of tools like Git and other components.
We should also note one of the reasons many people want to work as software engineers in the first place: the job can pay well. Careers site Glassdoor pegs the median total pay for software engineers at $147,000 per year (last checked: April 28, 2025), though the actual numbers will vary based on factors such as experience, location, and industry. (If you’re just starting out, try our primer, Cybersecurity vs. Software Engineering: 2025 Career Guide, for more smart advice.)
Now let’s dig into some actionable tips and ideas for hitting the ground running.
The First 30 Days
In our companion article for cybersecurity careers, we noted that the first 30 days ultimately boil down to learning. That means everything from codebases and tooling to new faces and new places. And it’s still true here, albeit with some tweaks.
Tip #1: Not all tech stacks are created equal
Navigating your new role needs to be as much about learning people and processes as it is about learning the codebase or tech stack.
“From my experience at big companies, it's more important to understand the people [and] processes than the code's architecture,” says Justin Garrison, Head of Product at Sidero Labs. Prior to his current role, Justin worked as a Senior Developer Advocate at AWS and in multiple engineering roles at Disney, including Senior Software Engineer.
Tip #2: Understand how the business generates revenue
To maximize your value, you must understand how the organization generates its value.
“In addition to learning the technical stack and requirements, engineers should figure out how the business creates value and gets paid,” Chris Carter, Principal Product Manager at NetApp Instaclustr, tells us. Prior to taking on his current role, Chris began at the company as a senior development engineer and engineering team lead. He continues:
“Direct subscriptions? Field sales team and custom deals? Eyeballs and advertising? Figure out how the business measures itself and how it goes from code to KPI.”
Build that understanding early. Software engineers who can connect the dots between their code and their company’s financials are not likely to go out of style.
“By understanding how the business itself measures its success, you can position yourself to be part of generating that success and contribute to the bottom line,” Chris says.
Tip #3: Clone the repo, but don’t rush the commit
Sure, you’re eager to make that first PR. But treat the codebase like a living organism: observe its patterns, understand its anatomy, and ask questions before you operate. Use your IDE’s code navigation features, grep commands, or repo search to follow how data and logic flow through the system.
And if you get stuck? Try reproducing behavior locally and then tracing it step-by-step. Debuggers are underrated, and rubber ducking still works in 2025.
Pro Tip: Look at recent merged PRs to understand code style, review culture, and what “done” really looks like.
The First 60 Days
One of the best ways to ramp up quickly is to get curious, not just about what the code does, but why it does it that way.
Tip #4: Ask, “Why was this built this way?”
Legacy code might look like spaghetti, but often there’s meat in the sauce. Constraints from a now-retired service, a performance tradeoff, a business requirement from a sunsetted product feature—these choices have a history. Learning that history helps you avoid suggesting something that was already tried (and failed), and builds your credibility.
Start with internal documentation (even if it’s stale). Then ask a teammate to walk you through something confusing, and treat them like a co-author of the system’s story.
“What decisions are encoded in this code?” is a better question than “Why does this code suck?”
Tip #5: Identify your team’s “unwritten rules”
Every engineering org has them. Maybe it’s that the team prefers RFCs in Notion over Jira tickets, or that everyone deploys on Thursdays, or that unit tests are optional—but e2e tests are gospel.
These norms won’t always be in a handbook, but they’ll shape your success just as much as your coding skills. Watch Slack patterns, study Git commit messages, and ask teammates what they wish they knew when they joined.
Tip #6: Keep meeting with – and learning from – people
Justin from Sidero Labs posits that meeting people helps engineers understand how systems work together beyond the code: “At the end of those meetings, it was a lot easier to understand why systems look the way they do.”
That has all sorts of cascading benefits, including reducing your blood pressure when reading code that doesn’t seem to make sense at first. If a human wrote it, that human probably had a reason for writing that way, and those could include organizational variables, time pressures, and so forth.
This kind of holistic understanding helps in terms of team culture and communication, but also empathy and diplomacy when the time comes to look for and suggest improvement.
The First 90 Days
You’re all grown up: “By 90 days, you should have found your feet and hopefully find yourself able to take ownership of larger tasks,” says Chris from NetApp Instaclustr.
This last phase is really about planning and beginning to execute. Where can
you start to make some real impact?
Tip #7: Start optimizing with purpose and impact
By 90 days in, you’re not just the “new engineer” anymore—you’re an emerging contributor. That means it’s time to look for opportunities to make things better. But there’s a catch: not every improvement is worth chasing, and not every bug is worth fixing.
“It’s not about creating a laundry list of things that are broken,” says Chris. “It’s about understanding the business, the customer, and the context—and then using that knowledge to identify meaningful ways to improve.”
Here’s how Chris and his team approach that mindset:
- Think upstream: Don’t jump straight to solutions—start by writing clear tickets that describe the problem.
- Prioritize wisely: Learn how your team weighs impact, effort, and urgency. A trivial UI bug on a deprecated screen? Probably not a fire.
- Customer-first mindset: Always ask, “Will this matter to a real user?” If not, file it away and move on.
Once you’ve learned the systems and culture, start seeking out higher-leverage tasks—things that reduce friction, improve delivery, or boost the customer experience.
“By consistently delivering work that moves business targets forward, you’ll quickly be recognized as someone who ‘gets it’—and can be trusted with bigger things,” Chris says.
Tip #8: Ship something. Anything. But own it.
By Day 90, you don’t need to have rewritten a core service or launched a new feature solo. But you should be able to point to one thing, however small, that you’ve shipped and owned end-to-end.
That could be:
- A bug fix that reduced user friction
- A CI/CD pipeline tweak that sped up builds
- A README overhaul that helped the next new hire
- A backend optimization that shaved 50ms off a common query
It doesn’t have to be sexy—it has to be useful. Impact isn’t about flash; it’s about function.
Engineer’s Mantra: “Did I make the team’s life 1% better this week?”
Tip #9: Set up a personal learning backlog
You won’t master the whole codebase, infrastructure, and business logic in 90 days. That’s okay. What matters is what you do next.
Create a personal “backlog” of skills and knowledge gaps. Jot down:
- Areas of the system you still don’t understand
- Tools or frameworks you want to learn deeper (e.g., Kubernetes, gRPC, Terraform)
- Tech debt or oddities you want to revisit
Then prioritize one thing per sprint and check it off. You’re not just learning the system—you’re designing your growth roadmap.
Subscribe to The CTO Club's newsletter to get more playbooks for your first 90 days in any tech role!