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!
