The Good Tech Companies - How We Built a Professional iOS Onboarding at inDrive

Starting point is 00:00:00 This audio is presented by Hacker Noon, where anyone can learn anything about any technology. How we build a professional iOS onboarding at Indrive by Indrive. Tech. In any tech company, onboarding new hires is a moment of truth. How quickly a developer gets into the rhythm of the team affects not only their motivation, but also the speed of shipping new features to production. At InDrive, the pace is always high, with plenty of tasks in motion. On top of that, we have two different architectures,

Starting point is 00:00:29 two navigation systems, a specific code style, our own Git flow, and many project-specific nuances. It became clear. The, figure it out as you go, approach no longer worked. When he did a systematic solution to help new hires take their first steps without unnecessary stress. That's how our iOS onboarding process was born. The problem of starting without a system previously, a new iOS developer would dive straight into a huge project with a UDF, unidirectional data flow, architecture. Debugging was difficult. One event could scatter across a dozen code sections, dependencies weren't obvious, and there was no documentation or established processes. To make things worse, every team implemented UDF differently, adding even more variation and complexity. We'll cover

Starting point is 00:01:17 how we later unified processes in a separate article. Developers often spend weeks, sometimes months, just trying to understand how everything works. By their second day, they might already receive a product task, but without knowing the project's code style, the architecture, navigation, network layer, or even something as basic as how to properly open a pull request. The outcome was predictable, dozens of comments in reviews, endless edits and change requests, wasted time, and the risk of bugs making it into production duetto a lack of architectural knowledge. Ultimately, this also impacted the business, lost money, delayed releases, and so on. The solution. A two-week onboarding to reduce this barrier, we launched a structured onboarding program. It lasts two weeks and takes place in a

Starting point is 00:02:03 separate repository, a mini-application that simulates the core processes of a production project. Step by step, the new hire learns to work with, two architectures, Inclean and UDF. 2 navigation frameworks. X-coordinator and Niveleer, networking and analytics, company code style, design system integration, pull request rules, how we write tests. Each topic is reinforced with practice. The developer gets a task, solves it, opens a pull request, and receives feedback from their buddy and the iOS community lead. Step by step, they build a full picture of the project and immediately learn to work by team rules. Whereas before, new developers were left alone with, with the project, now, each onis guided for two weeks to help them settle in faster. We also check in regularly to see how things are going and whether any difficulties have come up. Their onboarding pull requests are carefully reviewed. We point out issues and explain approaches so working with the product later becomes easier. At the end of onboarding, the newcomer fills out a feedback form, which helps us understand what worked well,

Starting point is 00:03:08 what was challenging, and how to improve. Saving time and improving quality on paper, the company, is two weeks, but in reality, it gains much more. Without onboarding, a newcomer would spend even longer stumbling through the chaos, while the teen would suffer from bugs and overloaded reviews. After onboarding, the developer opens their first product pull request, already understanding how processes are set up. Extra Ben A fits the onboarding solves other important problems, two, fewer errors. Critical production bugs caused by architectural misunderstandings happen less often. Candidate assessment. If someone can't cope even after two weeks, it's a clear signal they may not be ready for real tasks. Feedback loop. Every participant shares impressions,

Starting point is 00:03:53 and the program is regularly updated. Community support. Each newcomer has a buddy from their product team and an iOS community lead. The latter ensures expert reviews and guidance, even if the buddy is busy. Scale and results the first version of the onboarding launched on February 7th, 24. Since then, more than 30 developers have completed it, with nearly 500 pull requests opened. Most participants say they've never seen this kind of onboarding elsewhere. For example, you first understand how the project is structured and only then move on to product tasks. In total, we've collected over 30 reviews, all confirm it's one of the best onboarding experiences in their careers, helping them dive in faster. Without it, they would have spent

Starting point is 00:04:38 far more time figuring things out. What's next? The onboarding continues to evolve. The team gathers feedback, refines tasks, and improves the structure. In essence, it's not just a course for newcomers boot a tool for maintaining quality, reducing errors, and building a strong iOS developer community at INDrive. We realized, systematic onboarding is not about HR checkboxes, or formality. It's a strategic tool that helps people unlock their potential faster and helps the business move quicker and more reliably. For us, it has become part of the culture. We invest in the learning process as seriously as we invest in the product. And it's an investment that has already proven its value. Thank you for listening to this Hackernoon story, read by artificial intelligence.

Starting point is 00:05:24 Visit hackernoon.com to read, write, learn and publish.

The Good Tech Companies - How We Built a Professional iOS Onboarding at inDrive

There aren't comments yet for this episode. Click on any sentence in the transcript to leave a comment.