Imagine that it\u2019s your first day at a new software development job. Before you\u2019ve even finished the standard developer onboarding procedures, your manager tells you, \u201cYou\u2019ve completely f*cked everything up. Leave and never come back.\u201d<\/p>\n\n\n\n
That\u2019s exactly what one junior software developer heard after he followed the onboarding document to set up his local development environment, which inadvertently resulted in the clearing of the production database. U\/cscareerthrowaway567 has since shared his story on Reddit<\/a> and rightfully received a great deal of support and assurances that this catastrophe was not his fault.<\/p>\n\n\n\n If a manager is shouting profanities at a new employee on their first day or a new developer has the ability to wreak such havoc on your database \u2014 it\u2019s not their fault. It\u2019s yours….or more accurately, a fundamental failure of your onboarding process. Or possibly a toxic work environment, but we’ll save that topic for another article.<\/p>\n\n\n\n While we don\u2019t know from which organization unceremoniously dismissed the Reddit user above, we do know that such mishaps are not limited to nameless companies. Similar incidents have occurred with Amazon\u2019s Elastic Load Balancing Service<\/a> and, more recently, GitLab<\/a>, which suffered a loss of production data and hours of service outage.<\/p>\n\n\n\n When welcoming a new developer to your team, from the codebase to code standards, team workflows to team culture, and more, there is a lot to bring them up to speed on. By adopting strong employee onboarding practices, not only can you avoid the type of disasters mentioned above, but you can integrate your new developer as a fully competent, productive, and satisfied team member.<\/p>\n\n\n\n To help you achieve this, we\u2019re going to discuss some best practices for onboarding developers or welcoming new software engineer employees. Let’s get to it!<\/p>\n\n\n\n Looking for top talent fast? See how <\/em>Arc<\/a> can help you:<\/em><\/p>\n\n\n\n \u26a1\ufe0f Find developers, designers, marketers, and more Hire top talent with Arc risk-free \u2192<\/strong><\/a><\/p>\n\n\n\n Hiring may not typically be considered onboarding, but it is the requisite step. Get the hiring wrong and onboarding developers won\u2019t matter much.<\/p>\n\n\n\n Many successful hires begin with a referral \u2014 references and social proof in the form of a referral are great ways to verify the credibility of candidates. Referrals or not, you\u2019ll want to review developer portfolios and past work<\/a>. You can also review any open source projects they have contributed to on repositories like GitHub<\/a> or SourceForge<\/a>. Understanding their past work will give you a better idea of their technical skills and the types of projects they are most interested in.<\/p>\n\n\n\n Don\u2019t underestimate interest. Finding a developer who is genuinely passionate<\/a> about your use-case, business model, and technology will go a long way, not only in the first few weeks on the job, but in sustaining their motivation as a productive team member for the duration of their employment with you.<\/p>\n\n\n\n When bringing on a remote developer, interest and passion will be all the more important. Without an on-site manager and team members, it will be completely up to the new developer to immerse themselves in the new team and the accompanying challenges. Here at Arc, we\u2019ve had the opportunity to sit down with a handful of startup founders who run distributed teams. When it comes to hiring, they all emphasize the importance of passion.<\/p>\n\n\n\n Zapier\u2019s CTO, Brian Helmig, told us that when interviewing a prospective team member, he prioritizes passion and knowledge. Helmig loves to find people that are already part of the Zapier community as users and are excited to bring their expertise to the product. He goes on to say what they really look for are \u201cautonomous doers\u201d who don\u2019t<\/em> need a social workplace.<\/p>\n\n\n\n Similarly, Hotjar CTO, David Darmanin, looks for passion and potential. For David, that means someone who has demonstrated growth in their career, is ready to expand their skill toolbox, and has a growth mindset. In other words, someone who is \u201chungry.\u201d David says he\u2019ll take hunger over experience any day:<\/p>\n\n\n\n Someone who has done it all, achieved everything \u2014 I don\u2019t want to assume \u2014 but they\u2019re probably going to be a little less hungry than someone who is still growing and coming up in their career.<\/p>\nDavid Darmanin, CTO of Hotjar<\/cite><\/blockquote>\n\n\n\n Another often overlooked hiring tip is involving your current employees in the process of onboarding developers to your team. Depending on the size of your team, including project managers and internal employees in hiring decisions can help to build confidence, boost team spirit, and pave the way for successful formal onboarding. <\/p>\n\n\n\n This type of transparency in the hiring process helps to neutralize any anxiety current employees may have regarding bringing on new talent, who can sometimes be seen as a threat. In addition, allowing team members to meet prior to onboarding helps to build the network that will be necessary to carry the new dev hire through the employee onboarding process and become a fully integrated team member.<\/p>\n\n\n\n Read More<\/strong>: 4 Misconceptions About Hiring Remote Developers & What To Do About Them<\/a><\/p>\n\n\n\n Documentation<\/a> will be of paramount importance when onboarding a new developer, especially one working remotely. In our chat with Zapier\u2019s CTO, he drove this point home by saying, \u201cinformation should dispense automatically by design when it’s needed.\u201d<\/p>\n\n\n\n To provide team members with the information they need to do their jobs effectively, you should document everything: from user guides of commonly used tools, organizational charts, SOPs, common bugs and how to solve them, workplace setup, software tutorials, anything that requires step-by-step instructions, organizational charts, and contact lists. <\/p>\n\n\n\n To stay organized, all of this information should be available in a centralized place, like an internal wiki page. To streamline the onboarding processes, some have suggested a welcome ebook<\/a> or a tutorial series. While this would require some initial investment and planning, once launched, there would be minimum upkeep and it would be of lasting utility.<\/p>\n\n\n\n When it comes to developer-specific documentation, you have a whole \u2018nother realm to consider. Each dev team should have a standardized way to set up their local development environment and workflow procedures. Teams should choose the workflow framework most suitable for their projects and programming process \u2014 some popular workflows include GitFlow<\/a>, Feature Branch Workflow<\/a>, and Trunk-Based Development<\/a>. As early as possible, you want to integrate your new developer into this workflow.<\/p>\n\n\n\n Repository documentation should not be overlooked. This should include a wiki detailing how to use the codebase, how it\u2019s been designed, manifestos on core principles, and any other long-form content pertinent to the project. Also include a README, which should be a quick introduction to the project.<\/p>\n\n\n\n Read More<\/strong>: 11 Data-Backed Reasons to Work With Remote Software Developers<\/a><\/p>\n\n\n\n Mentorship can be an invaluable aspect of both onboarding developers and team building. Just because you have an efficient, knowledgeable team and a motivated newcomer doesn\u2019t mean a mentor-mentee relationship will automatically form. Like all other aspects of new employee onboarding, mentorship needs to be thought out and executed with care.<\/p>\n\n\n\n From day one, or even before day one, new recruits should have a person to reach out to who is ready to answer any technical questions, introduce the team, and even walk them through initial projects.<\/p>\n\n\n\n Don\u2019t make the mistake of always assigning the duty of mentoring onboarding developers to your most senior engineer. Eventually, they are likely to get burned out and resent the additional burden AND the new team member. In fact, having a more junior developer take on the responsibility is a great way for them to put their knowledge to practice, give them leadership opportunities, and quietly check that they are up to snuff.<\/p>\n\n\n\n When onboarding new developers here at Arc, our dev team transitions new programmers into their new development workflow by quickly assigning an easy task for them to complete using GitFlow practices. This helps the onboarding software engineer or software developer gain a sense of achievement and contribute to production while learning the workflow. <\/p>\n\n\n\n Tasks can include rebuilding dashboards, writing a new algorithm for a matching feature, updating or building new features, or any less complex task that helps the new developer start participating as a team member. In typical production cycles, it\u2019s not uncommon for tasks to be defined as they are being built \u2014 however, this should be avoided when assigning introductory tasks to new developers. Initial tasks should be well-defined and have clear scope to avoid confusion and frustration.<\/p>\n\n\n\n Here are some tips for mentors-to-be:<\/p>\n\n\n\n Read More<\/strong>: Is Your Developer Ready for Remote Work? 14 Key Interview Questions<\/a><\/p>\n\n\n\n Even before work begins, you should start to include your new team member in communications: email chains, Slack channels, weekly updates, etc. There\u2019s no need to pile everything on all at once \u2014 ease them into one channel at a time to let them get comfortable with your communication flows.<\/p>\n\n\n\n Once the developer joins your team, have regularly scheduled updates. Be prepared to answer their questions and address their concerns. Weekly updates can be done stand-up style where everyone reports what they have done in the past week, what problems were encountered, what needs to be improved, and what is on deck for the next week. Ideally, your stand-up meetings should be followed up with written notes that everyone has access to.<\/p>\n\n\n\n In addition to team meetings, you should use regular one-on-one meetings to check in on new hires. One-on-one meetings are a good time for you to let your new team member know how they are doing, give any feedback or suggestions for improvement, and listen to them. Managers should encourage new engineers to give honest feedback, share what they have enjoyed, and discuss anything they may be struggling with. <\/p>\n\n\n\n Zapier has a useful meeting strategy to solicit two-way feedback which we\u2019ll call the “four ones.” In sit-downs, one of the founders will ask the following questions:<\/p>\n\n\n\n It works as both a great experience for onboarding developers and for your veteran staff members alike!<\/p>\n\n\n\n Read More<\/strong>: How & Why Hiring Remote Developers Builds Strong and Diverse Teams<\/a><\/p>\n\n\n\n Having standardized communication structures and clear performance expectations are important to onboarding developers, but integrating a new developer into your company culture will add a shot of stay-power. Encouraging creativity and spontaneity with team-building activities is a great way to help your new developer feel at home on your team.<\/p>\n\n\n\n One way Zapier does this is with what they call pair buddies. This is a random pairing of two teammates who are matched for a 10-15 minute chat. The focus should not be on work, but rather on personal or professional sharing, so teammates can get to know each other better. Of course, the end goal is a stronger working relationship.<\/p>\n\n\n\n Other distributed teams have been known to have virtual beer meetings<\/em>. Everyone can grab a beverage of their choice and have an online team-building session to talk about random or designated topics. It may sound strange, but it\u2019s a way to bring online relationships to life a bit more.<\/p>\n\n\n\n In addition to spontaneity, also embrace ceremonies to be held at regular intervals. Ceremonies can include demos of soon-to-ship features, buddy coding day, hack day, or whatever else you\u2019ve got up your sleeve. Hack days are great opportunities for developers to take a break from regular sprint-based work cycles and activate their creative programming skills on problems that interest them most.<\/p>\n\n\n\n Plan ceremonies so that everyone can join, including any remote team members, particularly if they are onboarding developers. Ceremonies should bring a dose of consistency, an opportunity for everyone to share their talents and recent learnings, and hopefully becomes something your team looks forward to.<\/p>\n\n\n\n A healthy combination of ceremony and culture-building<\/a> will help to promote personal relationships and team spirit \u2014 this is a vital part of helping new onboarding developers fit into your team culture. Culture and attitude fit will likely be the most important factors determining whether or not your new hire ultimately becomes a successful long-term member of your team.<\/p>\n\n\n\n Read More<\/strong>: Good vs Great Developers: How to Tell the Difference & Hire the Best<\/a><\/p>\n\n\n\n To best evaluate the performance of new developers, it\u2019s important that they work in public. Programming-related tasks can be done on platforms like Bitbucket or GitHub where everyone has access to the repository and can see what pull requests have been submitted or what changes were made. Non-coding tasks should be done in shared spaces like Google Docs, and updates made on project management tools like Asana or Trello.<\/p>\n\n\n\n Evaluate not based on time spent but value produced. It is useless to be constantly looking over your developer\u2019s shoulder. Instead, keep track of the tasks they are working on and create an environment that allows them to produce valuable results. Do this by sticking to clean code standards, code coverage expectations, and timeboxed sprints. <\/p>\n\n\n\n Use a code review process to make sure new team members are meeting code standards and offer suggestions on where they can improve. Additionally, have periodic discussions on current workflow processes and address any barriers or bottlenecks.<\/p>\n\n\n\n Be sure to measure by quality, not quantity. One thousand lines of messy code will never be as good as 100 lines of clean code.<\/p>\n\n\n\n Lastly, remember that evaluations should not only be for the manager’s and the company’s benefit. Developmental feedback is key to helping onboarding developers and software engineers learn and grow and collaborate better across teams.<\/p>\n\n\n\n Read More<\/strong>: Contract to Hire: The Flexible Remote Engineering Team Scaling Solution<\/a><\/p>\n\n\n\n To the greatest extent possible, you should include remote developers as if they were actually on-site.<\/p>\n\n\n\n All onboarding procedures can be done digitally, with the help of video chat and your run-of-the-mill virtual office tools. Though it may take a little more effort, team introductions, and mentoring can, and should, still take place with remote team members.<\/p>\n\n\n\n Whether you are working with remote freelancers, part-timers, or full-time employees, becoming part of the team means learning about the company. Many companies use an introductory course, or at least have some required reading, introducing the company’s history, values, mission, and long-term vision. If remote team members understand the company and its goals, they will be more likely to feel like they are part of the team. It\u2019s important to help remote developers feel a sense of purpose within the company and camaraderie with team members. They are more likely to be motivated, loyal, work conscientiously, and have overall stronger performance.<\/p>\n\n\n\n Even after remote team members are fully integrated, their goals and workflows need to continue to be aligned with the company\u2019s initiatives and long-term goals. To do this, Hotjar annually drafts a one-page strategic document and asks that all teams and individuals align their work with the company\u2019s North Star.<\/p>\n\n\n\n Read More<\/strong>: How to Be an Engineering Manager Your Company & Team Respects<\/a><\/p>\n\n\n\n Don\u2019t expect perfect performance the first couple of weeks a new developer is on the job. The average employee takes upwards of six months to become fully competent in their role. In this article, we have offered some tips to help you reduce this time.<\/p>\n\n\n\n What we have presented here is not a rigid template to be followed, but a formula to be adjusted for your specific project and team. To optimize your own onboarding process, you can ask yourself a series of simple questions:<\/p>\n\n\n\n If you can answer these questions and address them in your onboarding procedure, you\u2019re on your way to successfully integrate a new team member.<\/p>\n\n\n\n With the proper onboarding process, there will be no need for profanity, (unless that\u2019s your culture), or data loss, which we\u2019re pretty sure isn\u2019t<\/em> part of your company culture.<\/p>\n\n\n\n Happy onboarding!<\/p>\n\n\n\n You can also try <\/em>Arc<\/a>, your<\/em> shortcut to the world’s best remote talent:<\/em><\/p>\n\n\n\n \u26a1\ufe0f Access 450,000 top developers, designers, and marketers <\/a>Try Arc and hire top talent now \u2192<\/strong><\/a><\/p>\n","protected":false},"excerpt":{"rendered":" Here are 7 best practices to create a process for successfully onboarding new developers and software engineers to your company and team. <\/p>\n","protected":false},"author":3,"featured_media":1008,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4,5],"tags":[],"class_list":["post-1006","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-hiring","category-management"],"yoast_head":"\n
\u26a1\ufe0f Freelance or full-time remote + fully vetted<\/em>
\u26a1\ufe0f Save up to 80% with global hires<\/em><\/p>\n\n\n\n1. Hiring<\/h2>\n\n\n\n
\n
2. Documentation<\/h2>\n\n\n\n
3. Mentorship<\/h2>\n\n\n\n
\n
4. Communication<\/h2>\n\n\n\n
\n
5. Culture<\/h2>\n\n\n\n
6. Evaluation<\/h2>\n\n\n\n
7. Integrating Remote Developers<\/h2>\n\n\n\n
Conclusion<\/h2>\n\n\n\n
\n
\u26a1\ufe0f Vetted and ready to interview<\/em>
\u26a1\ufe0f Freelance or full-time<\/em><\/p>\n\n\n\n