Our 2 Month Plan to Onboard New Engineers

Onboarding is a critical time for both new team members and the company hiring them—a very critical process to get right.

It’s an employee’s first impression of our company and it will dictate the mindset the new hire has about their job. We want to make sure a new employee feels welcome, valued, driven and starts learning the company culture and the expectations we have for them.

At Turing Technologies, we’ve put in a lot of effort to make onboarding our teammates a smooth and structured process.

We want to share our process for the engineering team—what we’ve learned so far and the areas we are still working on.

Pre-Joining List:

Our onboarding starts a few weeks before a staff member’s first day. 

As we’re using the NestJS, MongoDB, TypeScript, GraphQL and NextJS for almost all our projects/products. Hence most of the engineers who end up working for us are not used to following the same standards or tech stack.

Hence after they accept their job offers, we send them a list of tutorials, code-alongs and documentation to go through. Doing this is completely at the person’s will however it helps us achieve two goals:

1. After joining, the engineer gets onboarded in a relatively shorter time.
2. Get early signs if the engineer is self-motivated and can work with minimal supervision in the future.

We do understand that the last few weeks before transitioning from a company are usually the busiest, and empathize with our staff member if they’re not able to complete the pre-joining list.

Day One and First Week

A typical first day at Turing Technologies is centered on these goals:

• Make the new hire feel welcome
• Introduce them to our company, to the team, and to the role
• Give them time to read and handle their HR tasks
• Set the precedent for how we operate
• Following up on their pre-joining learning
  

There is nothing out-of-the-ordinary here in terms of what we cover. Where it gets interesting is how we tackle these as a distributed team (with on-site, hybrid and remote team members). For one, meeting the team is not as simple as taking a tour of the office.

Instead, an engineer’s first day is a lot of face-time with their manager, covering company basics and meeting the team on paper. We also do not include the new hire to daily standup before they’ve gone through the product.

We’ve also pre-designed generic training plans which we tweak based on the engineer’s area (Frontend, Backend, Full Stack, DevOps or Testing), experience and familiarity with our tech stack.

‍2nd Week

Over the course of this week, sprint calls, as well as regularly scheduled meetings, provide the opportunities for the new person to meet their team in real-time.

Usually by this time they’ve gone through their initial learning tasks and are given a small project to get them familiarized with our practices and standards. One such task they are given is to implement their hiring test (that they’ve already done during our hiring process) to our current tech stack. 

For example, frontend developers will implement their hiring test in NextJS, TypeScript and GraphQL.

After that, a new engineer is ready to go. They have access to our repos and access to make changes into the dev environment. They’ve been through the process and it’s time to learn by doing.

During the 2nd week, they also get a chance to get another product overview from our QA and design team regarding user-experience and how to approach a problem/issue.

Our design team also gives them examples of some great SaaS products known for their impeccable design and simple user-experience. This is more relevant to the frontend team however we encourage backend developers to garner interest in this part of the process as well. This is because we believe that a good experience for our end-user starts from the whiteboard to backend and then to frontend.

A member of our HR and People team usually observes these meetings to give feedback to the managers on how they can improve their delivery, keep the listener engaged and encourage questioning.

3rd and 4th Week

At this time, engineers are usually given a small task, refactor code or a bug to fix on the product/project, this helps us understand if the engineer has understood the codebase and can debug issues by testing the frontend or APIs.

We don’t expect them to know everything. In fact, we encourage lots questions early on, the goal now is to increase the complexity of the tasks they are working on. 

To that end, we queue up more interesting issues or a small project. Often these tasks focus on something the engineering team wants to knock out, such as prep work to support GraphQL server-side or upgrading a minor version of node.js, but it can be a product-related change too, like improving the Dashboard API or add specific response messages. 

Code reviews at this stage are very important as they set expectations. We also get to observe how the engineer receives feedback (constructive criticism) and follows our principle core-value of LOW-EGO.

The capstone of our onboarding process is a meet and greet lunch/dinner with their team. This is where they’ll get a chance to meet their manager (if they are working remotely), design team, and other fellow engineers. In some cases (due to availability), a member of our executive team will join them as well. We are able to do this as we’re currently a small company :).

1-2 Months

After 4-6 weeks (depending on how the onboarding is going), our team member gets a chance to discuss their onboarding with their team lead, people manager and other stakeholders. We also discuss their future career plans and how we can help facilitate those, this can include placing them into another area after a few months to give them a broader perspective on how tech products are developed from scratch.

Our engineers also get a chance to talk to our stakeholders in the US to:

1. Under product’s and the company’s vision 
2. Get any career advice
3. How startups/tech companies in America operate and work
4. How to approach and tackle problems
5. Leveraging existing solutions to build products
   

During this time, our engineer is also given a full fledged product task which would include shipping an end-product and handling edge cases before launch. 

Once the engineer ships their product feature and exhibits signs of taking ownership of their work, the onboarding process is officially complete!

Future Improvements

We’re constantly trying to improve our onboarding process, one way we do this is to ask for feedback from the new hire themselves.

As our team grows larger and more distributed, we’re trying to automate parts of our hiring process, the parts which do not require human interaction.

Did you like our Onboarding Process? Come Join our Team

Checkout this piece by Harvard Business Review on onboarding new employees.