It feels strange that I’ve been at my new job for 6 months already.
I use to get amazed when I see people stay at companies for many years, but I’m just beginning to understand that it's very easy for time to pass quickly.
I’ll be having my final probation talk with my VP of software development this Wednesday and I thought I could document a few lessons that have been invaluable in making my onboarding smooth and effective. So let’s dive right in...
disclaimer: I'm a mid-level frontend engineer and this is my second professional job. I don't know much, but I'm just documenting my learnings. Hopefully, they help you in one way or the other.
An onboarding plan
This is the most important step in your onboarding. You're entering an entirely new world, you’ll have a thousand things to learn (process, technical, etc) and you don’t want to be careless about this. I would argue that this is a great way to determine if you want to remain with this company - if they put a lot of thought into getting you up to speed, it can mean they’re organized and care a lot about helping you do a great job.
Onboarding plans are different across orgs, but an effective one should cover the following...
- Milestones - Why were you employed? What do they want you to focus on in my first week, month, quarter, etc?
- Technical setup: How do you set up all the technical stuff for your role? company accounts, local environments, links to technical documentation, and relevant repositories.
- Intro to people & depts: You'll most likely be working in a team, but you also want to know people outside your team. Think product owners, VPs, design, product, etc. Having a great relationship with these people will make your work easy in the future. Most companies will assign you to an onboarding buddy that'll show you around.
- Product tour: introduction to the product you’ll be building from a business & user perspective. You should try to be interested in the bigger picture. Don't be the engineer that knows nothing about the product except how to code it!
- Steps to resolve your first feature, bug, etc - Github, CI/CD workflows
- Intro to codebase: Depending on your level, you might want to dive into the codebase on your own or peer-program with a fellow engineer to get up to speed with the codebase.
Once you have a plan, you want to intentionally follow it through. The goal here is to avoid being out of context in future meetings, discussions, etc after your onboarding period. Of course, you can go back to check out things, but you don’t want to be the engineer who’s been at the company for 8 months and doesn’t know anything... So try to soak up everything.
First impressions matter a lot
As one of the few engineers working remotely at my company, I made sure I communicated a lot, attended meetings, was reading all conversations, asked a lot of questions, and over time, my teammates started commending my communication skills.
I put a lot of effort into setting up my space - bought a standard studio mic, got great internet, a dedicated, distraction-free office, webcam, and attended meetings very early.
Technically, I designated a few minutes every day to glance through my teammate’s PR. I didn’t understand most of it, but I tried to ask questions and leave comments. I know I sounded stupid most times - one time, I asked a very dumb question on a PR and hurriedly deleted it 🙃.
I think this is a great way to show you're a reliable teammate and gradually build trust amongst people in your company.
Studying the codebase: This was the hardest part of my onboarding process. I've always kick-started projects in my previous roles but this was different. The team has been building the product for more than a year. I had to do a lot of reading other engineers’ code, and learning and understanding patterns. One example was mobx - I had never used mobx before, but my new company swears by mobx. I had to learn it to even do anything meaningful. One thing that has also worked is trying to divide the codebase into different functionality and studying them on their own
- Services - auth, filtering - State management - CI/CD - Caching - Load balancing, etc
Coding style/patterns: This one was quite funny. My teammates have very strict coding styles and they would always catch them in PRs. I use to think it didn’t matter since the code works already but I’ve come to understand why - when trying to understand what a block of code does, the smallest inconsistencies can distract and make it hard to wrap your head around. Try to identify these patterns over time and understand them on a deeper level.
Career ladders: Your goal should be to optimize your career as a software engineer. If you’re still an entry-level engineer after switching 3 jobs, then you’re not doing something right. If you joined as an entry-level engineer, you’ll ideally want to leave as a mid-level. Thinking about career progression is very important and if no one is talking about it, you should. Find the right person to have the conversation with and have it already.
Understanding what to work on: consciously ask seniors what would be the best use of your time. What could you do to bring the highest value to your team? Almost every team has a bottleneck, it’s your responsibility to ask questions and try to work on impactful problems.
Take advantage of your newcomer perspective: This is one place where your company would love to learn from you. Give feedback on the onboarding process, on their CI/CD flow, product architecture, and just about anything. You won't be able to do this anymore once you're in the company for long, so try to be intentional about spotting things that don't feel right and talk about them when necessary.
After the first 6 months, your goal should be impact - trying to contribute your best and bring the biggest value to your team, removing bottlenecks, and enabling your teammates to build the best software you can. This is the phase I'm going into now and I'm so excited about it. I'll do well to write a follow-up to this article. Till then, peace ✌