Onboarding yourself as a Senior Software Engineer

The success of the onboarding process depends equally on both parties. There is plenty of advice for the hiring side. I used it myself when onboarding developers of various levels as a Tech Lead. Today, I want to share some tips from another side of the table. I recently onboarded myself at a new job using my learning from onboarding other developers. It worked out very well, with feedback like, “It’s the fastest onboarding I’ve ever seen”, “Your onboarding has been spectacular”, and “Don’t be such an asshole”. I’m also trying to get better at the “Two truths, one lie” icebreaker.

I attribute a lot of my success to a great team in charge of my onboarding. On my side, I did a few things well, too. In this article, I share the less obvious ones.

Get access

As dumb as it sounds, giving you access to critical tools and services needs to be done as soon as possible. Onboarding checklists usually cover access to tools like Jira or Toggl, and that’s okay. But what you really need is access to all the technical tools, from git and Jenkins to Figma and analytics. Chasing some accesses can be non-trivial due to special SSH key requirements or a gatekeeper person being on sick leave.

It’s crucial to get access to all possible observability tools. You can learn so much about your project from Datadog if you only have access and a willingness to explore.

Enable Sponge Mode

I had to consciously enable “Sponge Mode” for my first month in a new company. “Sponge Mode” means that you absorb new information without challenging the status quo. It’s important to note down inconsistencies, ideas for improvements, flaws in processes, etc. Later, you will be able to raise them with the team. But first, you need to understand how the current system works by observing it with curiosity. “Interesting” should be your number one reaction to awkward things. Also, start using the language of the org as soon as possible. If people call the staging environment “preview”, call it “preview” too.

Meet people

Go to the office, share a personal story, play “Two truths, one lie”, have a beer, and be yourself throughout the process. Building relationships and gaining trust takes time. It’s a good idea to show others that you are interested in building relationships. And you are, because software development is a team sport.

Ask different people the same question

During the first weeks, you have the privilege to ask stupid questions and get detailed answers. Try to build a multi-dimensional model of your new workspace by asking different people the same question. For example, ask a fellow developer, Product Manager, and UX designer what they think your team is building. You’ll likely receive three different answers, all correct in their own context.

Read source code

Often, code onboarding is delayed in favour of process onboarding. It’s an unfortunate obstacle that you must proactively overcome. Even when my first week was fully booked with meetings and bureaucracy, I dedicated an hour every day to reading source code. Sometimes I had to read code on a train from my mobile. It allowed me to build my own opinion on the codebase and collect my questions for more productive onboarding discussions.

Ultimately, it enabled me to start coding sooner and steadily increase the complexity of my tasks until I felt at home in my new project.

Setup tooling

You probably have your preferred IDE, clipboard manager, grammar checker, terminal, shortcuts, etc. It’s best to configure these little comfy things before you start coding. Be open to changing habits too. Pairing on a task is easier when the whole team uses the same editor.

Be useful

Usually, a newbie gets maximum attention in the first week or two, and then, slowly, everyone becomes busy again. It’s expected that Senior Developers will take responsibility for their onboarding and complete it themselves. My main advice here is to try to be useful. I couldn’t take on larger tasks at first, but I could review and test some completed tasks, update the repo’s documentation, configure Renovate, etc. There are always multiple ways to help your team, and the sooner you start being useful, the sooner you become part of the team.

To summarise

The first three months in a new company are very intense for a new employee. I encourage developers to embrace all that intensity and proactively onboard themselves using my tips above or other tested techniques. For me, they worked very well. Compared to my interviewing experience, the onboarding was a breeze. I’m looking forward to what’s next!