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, 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. We needed 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 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 due to 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 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
- Two navigation frameworks: XCoordinator and Nivelir
- 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 the project, now, each one is 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, what was challenging, and how to improve.
Saving Time and Improving Quality
On paper, the company “loses” two weeks — but in reality, it gains much more. Without onboarding, a newcomer would spend even longer stumbling through the chaos, while the team 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 Benefits
The onboarding solves other important problems, too:
- 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, 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 7, 2024. 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 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 but 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.