Learn from our experience developing the Deliveroo product.
One of the best things about working in Deliveroo Engineering is that we have the opportunity to work on a great ever-changing product, which means we are constantly evolving, improving and facing new challenges. One of the main problems we have right now, which is a great problem to have, is the fact that we have grown so much that our monolithic application can’t hold everything in just one place anymore.
Do many software engineers know what an Engineering Manager (EM) actually does? As I moved through several companies through my career I saw this role in so many different colors and forms. Every time I was wondering - what is this job actually? I am not going to come with an exhaustive definition as I doubt it exists… However I’ve recently moved from Software Engineering role to an Engineering Manager, so hopefully my fresh memories and this post will help anyone who’s interested to find out more about what it’s like to be an EM at Deliveroo.
Our services are rapidly growing in number and we need a scalable way of managing the mayhem. Over the course of a year, our site was served as a single monolith and is now composed of over 50 services.
At the start of the year Apple announced their acquisition of Buddybuild, along with the news that Android support would end by March. This meant we had to find an alternative quickly, and Bitrise was our eventual choice. Here’s why, and how we switched.
Reemma writes to us after her time working with Deliveroo during her internship to tell us about her impressions of the company, her team, and what she accomplished with us over the Summer.
Kotlin was the big topic of the year in the Android community. Many of us are talking about it or have started using it. In this blog post I will share a few tips and tricks we’ve learned while converting our application to Kotlin.
Deliveroo is growing fast. We want engineers to come work with us. In this post we’ll go through our interview process and tips to prepare.
Rebase is one of git’s most powerful features. Most-commonly used to rewrite history by squashing related commits, and for keeping your branch up to date with master (without introducing unrelated merge commits), it can also facilitate some pretty clever workflow tricks which when used judiciously can let you factor out parts of your work into separate pull requests.
You work in a medium or a large team and you find yourself tapping your fingers waiting for someone to review your PR. Days pass and nobody volunteers. Your code gets stale, version control conflicts emerge. What to do? Convince your team to start playing Pull Request Roulette. It’s fun and it works!