I was responsible for helping a few of my new colleagues to get on-boarded into our team. Having worked in the same company for about five years, there are certain assumptions I made by default while doing knowledge transfers, that I was asked multiple follow up questions after each session.
Be ready to unlearn a lot of things.
Your old company would have followed a certain set of rules for everything. Don’t assume anything. You’ll only end up wasting time if you operate on assumptions. So definitely ask questions and make no room for preexisting assumptions.
Proactively start working towards getting access to everything you need.
Some things you may need to request access for:
- Chat groups
- Code repositories
- bitbucket
- github
- gitlab
- QA environments
- Jenkins
- Rancher
- Jumpboxes (ssh)
- Jira/Confluence
- Phone/Video call access
- Meeting tools like Webex or Zooms.
Set up your development environment as soon as possible.
Your very first few tasks will usually be small tasks that get you started with looking into the code and contributing in the least impacting part of the code. Having a development environment will enable you to test and experiment with different workflows and you’ll be able to contribute more quicker if you already know how everything works.
Learn Acronyms.
I don’t know about other companies but my company has a very strong acronym culture, so it’s super important that you get up to speed on all most of the common acronyms that are being used in various meetings.
Get Different levels of Knowledge transfers
Sometimes the org you work for is way too big, so you obviously can’t get knowledge transfers that covers everything top to bottom. It is important, however, for you to get the minimum level of knowledge required to start implementing your work.
- Company level KT
- What your organization does. For example, a high level understanding of the product you are working for, like a website.
- Engineering stack and company wide teams. Do you have a separate Data team? Do you have a CS team? Are developers their own QA. etc
- Team level kT
- Work timings and Code review culture
- This can cover regular workflows like learning how to request time off, days you get PTO, and what your team generally follows
- Coding conventions your team follows
- Cross Team level KT
- What do other teams do?
- Who is responsible for what
- What is the procedure to communicate
- Get names you can reach out to, for quick networking. You could reach out to team members well in advance even if you don’t need to work with them. This will help you get visibility later on.
What are some best practices you have implemented as a new hire at your company?
PS: I wrote this last year when I was still at my old company. As I revisited this draft today, I realized that my new company incorporates ALL of this as a part of my on-boarding process. There are weekly all hands and it’s crazy how streamlined they are and the past two weeks have been an absolute blast!
Her SWE Diaries 