How Android Engineers Work at Buzzvil

Hello, I'm Dio from Buzzvil's Output team.

One of Buzzvil's main products is an SDK that makes it easy to add advertising placements to mobile platforms, including Android and iOS. It supports Native, Interstitial, Feed, and Lockscreen placements. Buzzvil's Android and iOS engineers are responsible for developing this SDK. Our first role is to build these placements and improve their UI and UX, while regularly exploring new placements and interfaces. We also work continuously to deliver these features efficiently on mobile devices and make the SDK easier to use for our customers, such as engineers and product planners at publishers. We operate Honeyscreen, an app built by Buzzvil using these placements, and use it to improve the experience of actual app users as well.

In this post, I would like to introduce how Buzzvil's Android engineers work to build these products. The article focuses on the Android development process, which is my main area of responsibility, but our iOS engineers work in a similar way. I think iOS developers will find plenty of interest here too.

Our SDK development process

Buzzvil's Android engineers mainly work in sprints. Each sprint lasts two weeks, and at the end we produce working SDK and app builds. The builds then go through QA. Once QA is complete, rollout begins with the apps that Buzzvil operates directly.

Running a sprint

Buzzvil organizes its teams around layers of the product, so Android engineers belong to different teams depending on the product they work on. Each team plans its sprint work according to its short- and long-term goals, and engineers participate in that planning to agree on and set their individual goals. Once those goals are defined, the two-week sprint begins. In the following week, we create new version builds and move into QA.

Deployment

Like backend deployments, app builds and SDK releases use ChatOps. Entering a predefined command in Slack sends the request to an internal chatbot service built with botkit, which triggers an app build or SDK release through our CI service.

Buzzvil's Android project uses a <monorepo with multiple modules> structure. This introduces many considerations when testing pull requests or releasing SDK libraries—for example, managing versions in a multi-module SDK. We implement the logic we need in custom Gradle tasks, CI services, and deployment pipelines.

Engineering culture

As mentioned earlier, our teams are organized by layer, but engineers in the same discipline are always exchanging ideas, and Android and iOS developers communicate closely too. We meet regularly every one or two weeks to discuss important code changes, interesting issues and how we solved them, and design questions. There is also broad interest in new technology. Engineers introduce technologies during these meetings or organize study groups to explore them in greater depth. After careful scrutiny, we apply what we learn to real products.

Code review is another important part of Buzzvil's engineering culture. Personally, I believe culture matters more than rules in making code review active and effective, and that culture is well established here. Pull request authors try to provide as much context as possible so their work can receive a thorough review, and reviewers put equal effort into reviewing carefully. When code structure or design patterns require discussion, we sometimes open a draft pull request or write a short design document to begin talking with colleagues before formally requesting a review.

Let me briefly introduce our code review rules too. They are based on Google's code review guidelines, but we care more about the underlying philosophy and principles than about following every rule strictly. We also adapt or add rules to fit Buzzvil's circumstances, and individual teams may follow slightly different conventions. For example, “[OUT-840]” in the screenshot above is a prefix added to a pull request title to connect it to a Jira card.

Wrapping up

That was a brief introduction to how Android engineers work at Buzzvil. A short article cannot capture everything about our way of working, but I hope it has given you a sense of it. We will keep sharing how we work in areas that developers may encounter less often, such as ad tech and SDK development. Thank you for reading.

Apply for an engineering role at Buzzvil

Have a coffee chat with a Buzzvil tech recruiter