Onboarding – From a Senior Software Engineer’s Perspective

The last half/two-thirds of 2021 in the company I work for, I’ve been an integral part of the onboarding process of new hires- some filling void due to people leaving the team, some due to company growth. As an engineer it’s natural to form some (strong?) opinions about a process you’re observing, let alone being part of. I tried to keep it short and be as straight to the point as possible. So, here it goes:

If you’re doing the onboarding.

1. Documentation

Arguably the task a developer hates most – writing documentation. Close second: reading documentation.

In terms of value when it comes to onboarding people and returning back to, usually, very complex parts of the code – documentation is the crown jewels. Needless to say, if you/your company/your team don’t document most the code, write code guidelines and diagrams in dedicated wiki and document custom processes in the development pipeline – you’re not going to get far.

Robust organizations and sturdy developers do the hard things – they write and read documentation. Be one of them, lead the new hires by example.

Provide the documentation to the new hires and give them some time.

2. Pair up

This one maybe seem like a costly point in the short term, but it’ll pay dividend in the long run. As I’ve said, having documentation and reading resources is essential, but having a real flesh-and-bone person, a colleague, walking a new hire trough the code base and processes, contributes to a seemingly onboarding and it cannot be (shouldn’t be) substituted.

Make sure new hires have a go to person in the team, they can turn to in need in the first N months. Make sessions in which most competent person for a certain subject, part of the code base or process will onboard the new hire. That way you’re making new personal bonds, while the knowledge transfer begins. Spread the sessions out as much as reasonably possible.

During the onboarding, if this is possible in your organization, make the new hires work alongside most experienced engineers in the team.

3. Track adaptation

This one falls to management – have an adaptation measurement on how well the new hires are fitting in. This one is important in order to recognize the early signs if something is getting out of hand or is not working out. The adaptation measurement can be anything that makes most sense to your organization – if you don’t have one it can and will be yielded out by the onboarding process for you.

• The week of the first successful PR.
• The time spent on the first feature.
• The complexity (story points?) of the bugs solved

Whatever makes most sense for you. Address problems as soon as they arise, don’t assume, ask questions and make an effort to build rapport.

If you’re being onboarded.

1. Do your homework

There always are going to be things in the field of your expertise, favorite technology, SDK/API that you don’t know by heart. Even when you think you’re on top of your game, tools, methods, libraries change – you can’t feel on top every time – all the time, nobody does (not true, I know couple of people, but for the sake of the argument let’s pretend). That being said, what you can, and should do when you’re entering a new company is to do your homework – make sure you have as much domain knowledge as possible.

I work as an Android engineer, that develops apps that mostly revolve around Bluetooth, so if I get to onboard you – it will be handy if you know that part of the SDK/API. Even if you see that we have “our own way of doing things” in the onboarding process, it cannot be different than what the SDK/API intends to achieve.

If you don’t have experience in a domain or part of the SDK, make sure you learn as much as possible, especially, before you make your first PR.

2. Proactive sweet spot

This one is hard to measure, but it comes with experience. If you are the beginning of your career it doesn’t really matter, because you are probably going to go on one or another extreme of the “I’m going to figure this one out on my own” – “Let’s ask Bob or Lisa about this indentation” spectrum. Probably both, sometimes in the same company. Make sure when you ask questions you exhausted all the resources the Internet(s) have to offer. Double-check the dumbest possibilities, you might have overlooked something obvious. Be humble.

3. Get to know colleagues

Coding comes first, at the end of the day is just a job, BUT, you’re going to spend most of the day at work – make sure to be as pleasant as it can be.

Be engaging and get to know your new colleagues, try to fit in – share your experiences and get involved as much as you feel comfortable to do so.

In my personal experience, the best, most engaging work the team that I’ve been part of has done is after get-togethers, team buildings and after work hangouts. Events nowadays and probably in the (near) future are going to be mostly remote, but we can give our best and make the most out of it.