Technical jobs are always a little hard to explain: how would you explain what you do as a team to a random MOIA customer?
Jay: Put simply, our team ensures that MOIA drivers know who to pick up, and in what order, so that we can make sure everyone gets to their destination on time.
Robert: Yes, and in addition: we optimize the routes of the vehicles so that we can serve all customers and fill the empty seats by redirecting the vehicles to passengers who share a similar route.
Fabian: On the one hand we want to deliver each passenger as quickly as possible; On the other hand, we would like our vehicles’ seats to be highly occupied. How do we achieve that? By combining passengers with similar rides into one vehicle.
At the moment, there are still many MOIA customers we’re unable to pick up. Can you explain why?
Jan: Simply put, the more vehicles we have, the more customers we can serve. Of course, there is other stuff to it, for example there is research that shows that you need a certain density of vehicles per area and people. Currently, we are below that barrier. We need to improve on that if we want to be a 100% reliable provider for pooling and a valuable alternative to private cars.
Fabian: The reason is that the more vehicles we have on the road, the higher the probability that there is already a vehicle with a similar route for a new passenger trip request. So, in addition to the higher total fleet capacity, the chance for pooling also increases.
Robert: And actually, the answer to this question is not as simple as it might seem at first. Of course, more vehicles mean more requests are served. But on second sight it is a little more complicated. Currently, we act on a first-come-first-served basis. I.e. the customer knows if a request can be served in real time directly after the request has been made. This could lead to requests being served that have a low likelihood of being shared in favor of other requests that could be shared, just because the former request has been made a few seconds earlier than the latter. Having a few more vehicles in this case, the second request (and follow up pooled requests) could also be served.
There are still lots of developments to come. Expanding the fleet will be one of them. Can you describe some more of the impactful changes that are coming?
Jan: There are a lot of ideas coming from other people on how we can improve the current system. The team is growing rapidly, and we want to have a high standard for everything we produce. It is really challenging but fun to balance between all these important topics. The cool thing is that we can bring in our own ideas and the management understands that quality is important for the long-term success of the product.
Robert: One of the biggest challenges is to optimize our customer experience. While the service we provide has a high technical focus, it has a direct impact on customer satisfaction and of course our overall business goals. Measuring satisfaction is a lot harder than measuring the computation time of a program. Also, our service is directly influenced by the performance of the driver or traffic conditions. This means our service is heavily influenced by factors that are not under our control at all but still have to be taken into account while designing and building the new system.
Can you tell us a bit more about the impact you have on the customer experience you mentioned? Which of the aspects you’re currently working on influence the experience?
Jay: The dynamic routing team is integral to the value proposition MOIA offers. We need to calculate street routes and solve the problem of matching vehicles to customers’ requests, while at the same time being able to deliver customers within the time window that we give them when they book. Currently, I am working on the necessary geospatial components to calculate and deliver all the vehicle, customer route and position data.
Fabian: Basically, our team must ensure that our passenger-to-vehicle assignment is the best possible under the constraints defined by our product team. These include the maximum acceptable wait time of passengers at the stop and the maximum allowed additional ride time due to pooling with other passengers. We are currently redesigning our software system in order to be able to take this process to the next level.
To achieve this, what kind of profiles do you need in your team?
Jan: One thing is for sure and that is that we will look completely different in a few months’ time. We currently are ramping up our team by looking for people who bring additional skills, while still having enough overlap to talk about shared topics and issues.
Fabian: Yes, that last part is really important. We now have a team of people with different kinds of expertise who still ‘speak the same language’. Besides that, we always hope to find people who fit somewhere in the spectrum of excellent software engineers, mathematical optimization specialists, cloud native developers, geo-spatial computation and business domain experts.
And what kind of technologies do these experts need to work with?
Jay: I am primarily working with Golang, AWS, and Kubernetes. I’m also doing a lot of work with third party APIs as well as road/street map data.
Jan: My tool belt is filled with a lot of the usual cloud-native technologies. From Docker to cloud services. I rather try to pick the right tool for the job rather than sticking to something I used before which doesn’t quite fit. That usually means researching what’s out there, which framework is usually used to solve the problem and knowing your constraints. For the current component I’m working on, it means doing a lot of Golang in a Kubernetes cluster with Protobuf messages in RPC-style communication.
Fabian: Statically typed languages such as kotlin right now. Lightweight HTTP-frameworks without annotation magic. Docker, Kubernetes, Circle-CI.
Robert: My technical background is rather broad. While I program in languages as I go and kotlin, automize builds in circle CI, and of course use git for source code management, I’m also used to the operations of our software on kubernetes and I use a lot of technology from AWS to build the best product we can. Whenever we can, we use frameworks and tools to make our lives easier, be it optimization frameworks or protobuf RPC frameworks like twirp.
If someone would be interested in joining your team, what kind of philosophy and way working does the applicant needs to fit to?
Jan: We are, at the first place, looking for open-minded people who are quick learners and not focused on one specific technology or framework. Be nice, be an expert in a specific field and motivated to share your knowledge with other people on the team.
Robert: I agree. Especially sharing the knowledge. We believe that it is absolutely beneficial for the whole team to learn from the other team members whenever possible. Pair programming, for example, also helps us detect bugs earlier. Besides, applicants should not be dogmatic towards a certain programming language or framework, but also bring some expertise in one of the fields of relevance.
After reading this, some people might be interested in applying. To give them this final push, could you maybe describe what an average day look like for you?
Jan: I come in an hour before our daily meeting in the morning and sort out what I want to do before consulting with the others to align our daily goals. During the day it involves a lot of teamwork, from pair-programming to ad-hoc office discussions and meetings, so there’s a lot going on. At the end of the day, we sometimes get some refreshments and leave one after the other. Occasionally, there are also viewings of the latest Game of Thrones episode, internal community yoga sessions, board game sessions or mingling with beer.
Fabian: Aside from these rituals, I do a lot of hands-on programming in pairing sessions right now. In addition to that some time goes into coordinating with developers from other teams on interface changes. I have the impression and urge to learn something new every day.
Robert: I haven’t heard anyone mentioning the coffee: I arrive at the office, grab a coffee and then start working. Mostly by reviewing pull requests from the day before. Then, as Jan mentioned, we have our short daily standup meeting where we talk about the progress and impediments of stories. Afterwards, we typically start pair programming sessions, or I work on the clarification of documents or work on cross-team solutions for different challenges, be it technical challenges or conceptual development in the pooling domain. A larger part of my work is currently also dedicated to on-boarding new team members and helping everyone during their first days at the company. This naturally describes a day without meetings, however we still have rituals like a retrospective, a review, knowledge sharing sessions, and last-but-not-least backlog refinements every other day.