There’s nothing like a first impression — How to successfully onboard developers
It was a long time since I started a new job, but I still remember very very vividly one of those experiences. I was so excited about my first day, ready to meet my new teammates and start learning the job. Thus, it was so disappointing to get a big list of design documents to read. I was assigned a mentor from the team but he didn’t have much time to dedicate to training me. After a few days, I found myself bored and felt very frustrated.
This frustrating experience is unfortunately very common. It gives a very bad first impression of the company and in extreme cases causes employees to quit within the first month (some statistics suggest 20% of employees leave with the first 45 days.
Onboarding is an important part of recruiting that is commonly overlooked. Covid-19 days made this even more challenging — how do we onboard workers when we’re not physically in the same office?
Houston, we have a problem
When I joined Wix in 2011 onboarding wasn’t an issue. Each new developer was assigned a buddy from the team to guide them and gave them small tasks to start getting acquainted with the system. Our projects were small enough that it worked well.
But as Wix Engineering grew bigger at an extreme rate, we started to realize onboarding was becoming an issue.
We got bad feedback from senior engineers and decided to investigate it.
We decided to assign one of the backend guild managers to shadow an onboarding process. He came back with interesting conclusions:
- The systems are very complex to understand and require learning a lot of internal tools and frameworks.
- The design documents get out of date very fast.
- The buddy assigned as a mentor has other ongoing tasks that take a lot of his time leaving the onborader waiting for him.
- The same problem is tackled by new developers in different teams
- New senior developers are worried about their first impression and don’t like asking “silly questions”.
There must be a better way
The next step was trying to create an onboarding process. We’ve set a few goals for the new plan:
- It should be as self-service as possible.
- The new developer should know how to use all our main tools.
- She should learn how to use our framework and internal services.
- We need to find a way to keep it up-to-date.
- Better support for onboarders questions.
We created a plan aimed at all backend developers. The plan had 4 parts:
- Onboarding checklist: On the first day the onboarder gets a welcoming email from his manager with a link to an onboarding checklist: This is a general document with links to all important systems and reading materials. Each manager customizes the document with the relevant links and goes over it with the new onboarder.
- Nothing-to-prod: One of those links is to a Nothing-to-prod guide. This is a self-guided project the new developer creates. It’s a completely functional “Hello world” production service.
This project is expected to take 2 days. It’s a step-by-step guide, including screenshots.
The goals of this project are:
a. Get the developer's computer installed with all the software and configuration needed for creating projects.
b. The developer learns all our CI tools and gets a feeling of deploying to production. (It is not aimed at completely understanding how the CI/CD at Wix works, but getting acquainted with the tools.) - Something-to-prod: This is the next self-guided project where the developer builds his first fully functional Wix Service.
It’s expected to take 2 weeks. It’s built as 10 step project, each step has a general mission description, a link to the real documentation explaining the subject, and then a few guidelines for the tasks. Then we have links to view the solution.
The goals of this project are:
a. Learn how to use our basic building blocks (For example our FW, Connect to a DB, connect to a messaging system etc.)
b. Get to know the Wix architecture guidelines
c. Learn our best practices (like TDD)
d. Give the developer a real-life experience where he gets a task, goes over the documentation and tries to tackle the problem himself. - Crash course: After the new develper finished the onboarding projects, and worked for a while on new tasks — it is time for him to deep dive and understand better the core services he uses. For that we wanted to create an online course with training videos followed by a live q&a.
As we looked for existing training videos it became clear that we need to make dedicated ones for new employees. Existing training that was given to experienced developers assumed prior knowledge and wasn’t good for this purpose.
We asked each core service to create a dedicated training session for new employees which was then enhanced by a live q&a session.
Keeping it up to date
This plan covers the first 3 goals, but how do we solve the problem of keeping the guides up to date? We came up with a few rules to try and tackle this:
1. We will link to the actual readme’s of all internal projects, framework libraries, CI etc. This way we can make sure they are still up to date.
2. Onboarders are asked to create a PR when they find information that isn’t up to date. This is great because it also gets them involved and they feel part of the process.
3. There is a designated developer who is in charge of the onboarding process and updated the documentation according to issues that are raised / new technology that is introduced.
There are no stupid questions
The last issue we wanted to handle was giving support to onboarders and encouraging them to ask questions and understand the basics properly.
We started with creating a dedicated slack channel for onboarders so they can support each other and have graduates of the onboarding process give advice.
Then we came up with a great idea: We wanted to keep the buddy system but encourage new developers to ask questions. So we decided that the biggest onboarding chunk, which is doing the something-to-prod project, will be done in a different project and team, and the buddy will be assigned from that project. This gives us 2 great advantages:
1. The new developer isn’t scared to ask questions that he might think are basic or stupid. he’s not harming his reputation in his new team in any way.
2. She gets to experience other ways of developing in Wix.
3. It takes off the pressure of delivering features and allows focusing on learning
Does this work when WFH?
We were running the new process for a few months when the pandemic broke and we moved to WFH. It turned out that without knowing it we were prepared for this shift.
The new program is working great, we were able to continue the onboarding process remotely and we are getting great feedback from the new developers.
The next challenges
Even though this was a huge improvement, we’re not done yet. We see this as an ongoing task to continue improving the process.
We keep holding 1 on 1 interview with developers a few months after they joined the company to hear their pains and suggestions and try to improve on it.
We are in the process of creating a guideline for onboarding to the specific project after the general onboarding is finished.
We see great success out of this project and love having happy new developers join us all the time :)
You can hear more about the change to our onboarding process in this poscast episode: https://www.youtube.com/watch?v=mYyaxkhce9A
Want to join us too? You can see our open positions here: https://www.wix.com/jobs/home
