Interview with an Android Engineer — Mustafa Mutlu
Our Android team is growing rapidly. As a company experiences hypergrowth, processes and structures break. I find it fascinating to see how teams learn and improve in this environment. In this interview, find out how our Android team grew and scaled. I sat down with Mustafa Mutlu, one of our Android Engineers, to get some relevant insights.
PK: Please tell me a little bit about your background.
My name is Mustafa. I joined N26 about a year ago in April. Before that I was working in Istanbul, Turkey. I have three years of Android experience. I enjoy working at N26 and living in Berlin. I spent most of my time in the “Payment Schemers” team in the “Payments Group.” We’re focused on bringing more features to the UK and follow up after our launch last year. I’m also now working towards the US launch and excited about that as well.
PK: You mentioned working as an Android Engineer in Istanbul. How would you describe the difference between how the team here works and how you’ve worked in the past?
My previous employer in Istanbul was a lot smaller. We didn’t have several offices with lots of people working on the same application. N26 is a hypergrowth, scaleup company. We’ve grown rapidly and kept the same startup values. It’s not one of those huge companies where you don’t talk to people outside of your team. Everyone is very approachable. You can always approach anyone with your feedback or questions. It’s nice to have this openness and transparency.
In the Android team we are now about twenty people.
PK: It’s massive!
Yes. When I first joined, we were twelve people and it had doubled in size. We are growing exponentially, which is very exciting. At the same time, as we grow, we face new challenges on how we work as a team. We’ve had to evolve our processes.
PK: What’s an example of a process you had to evolve?
We run events called “Knowledge Sharing Events.” We have a weekly one-hour meeting focused on knowledge sharing. In the past, we met face-to-face in a room. We shared our screen, walked through code we recently wrote or discussed a problem we recently solved. I found it very helpful when I first started and still find it useful today. We also learn more about what everyone else works on. If you introduce a new component or a new way to solve a problem, this is the perfect place to share the knowledge.
After expanding the Android team to our Barcelona office, we had to evolve these “Knowledge Sharing Events.” In our current process, we create a new page on our wiki for each meeting. Every engineer who wants to share something prepares by writing topics and details to share in that page. In the meeting, we connect remotely, walk through the page and discuss.
It’s better because it’s based on documentation that you can later refer to. Information is not lost. If you don’t have time to attend the meeting, or if you’re on holidays, you can still catch up. We like to think it’s like an internal blog we use to share information with each other.
PK: That’s a great scaling idea. You can also go back to something you discussed in the past.
Yes! We also know finding information is important. We also keep the pages indexed so others can easily search and find relevant information. Our “Knowledge Sharing Events” used to be ad hoc face to face discussion. We’ve scaled up our practice to work remotely and more asynchronously. I think we tackled this challenge nicely. It works very well.
PK: Much more scalable, too.
Indeed! I expect we will continue to grow. Like when we have an Android Engineer in our New York office, we think this practice will scale well.
PK: What have you learned so far since joining N26?
Before I joined, I saw Lucia’s article on the Reactive Clean Architecture. We use this here at N26. It excited me because I have never used a Reactive Architecture before. We use RxJava intensively. I wanted to learn more about this and have learned a lot about how to use it since joining.
I have also learned how we evolve our architecture. During one of our team meetings, we shared what we thought the weakest aspects of our architecture was. We also brainstormed as a team on how to address them.
PK: It sounds like a great technical retrospective, focused on the Android architecture.
Right! We used post-its and everything like in a normal retrospective. It was great that all Android engineers contributed to this. We have already improved some of these areas, and have plans for others. Our architecture is battle-tested to support the features we need and the variety of devices we have to support.
PK: What else have you learned?
Our team works very closely with a team of Barcelona. This means working like a distributed team across two locations. Our daily standups and ceremonies are therefore held remotely. I’ve never had that experience before and it works very effectively.
PK: Out of all the teams at N26 I know of, your team is probably pioneering these experiences and practices. More teams will need to learn from yours as our company continues to grow and becomes more distributed!
Yes, I agree. I have learned so much. Now that we have New York and Barcelona, there are lots of lessons to share.
PK: I’ve heard about the Android core team. Tell me more about it and how it works.
Our Android team members normally work as part of cross-functional product teams. We also have a small, dedicated Android core team that does not contribute to product features. It’s a rotation-based team with a couple of permanent members. You join for a month, and then return to your cross-functional product team.
In the core team, we like to say, “You develop features for features.” You provide essential building blocks for other Android engineers. Those other Android engineers are more focused on product features.
As part of the core team, you also have more time to explore the latest Android technologies. You assess if they’re relevant for us. If it makes sense, you might even implement a technical spike to learn about them. Of course we then distribute those learnings as part of the “Knowledge Sharing Events.”
I learned a lot during my time as part of the core team. We had some cross-platform goals like improving modularisation, unifying our design approach, and expanding test and release automation. I improved modularisation by implementing a common navigation tool and method. I also added in more automation and instrumentation to our tests. These reduce our release cycle and better locate errors in our regression tests.
PK: The rotating core team is a very nice model. You get to work on both a feature in particular domain and you get to work on some platform-like features. You get some variety this way.
That’s right. We like to describe that we are members of two teams. I’m part of a cross-functional Product Team. At the same time, we like to think of ourselves as Android Ambassadors for that Product team. We are people who offer Android insights to help Product teams achieve their goals.
As an Android team, we also need to align so that the codebase is consistent. We aim to build a codebase that looks like a single person wrote it. We don’t want it to look like twenty different people wrote it, because we want to easily rotate to different parts. We continue to develop ways to distribute knowledge to ensure we are always up to date with others.
We work well as an Android team. I’m always aware of what other Android team members are working on. It doesn’t mean I know the detail. I do know who to approach on particular topics if I want to find out more. It’s very nice.
PK: It sounds like you’ve learned a lot since being here. There’s also been a lot of change. What is one change you’re proud of working on?
I was part of what we called, a “UK Taskforce.” Launching the UK required a lot of contributions from many teams in the company. My team was responsible for updating our application to offer UK customers the best experience. We had to touch a lot of different places in the application. I am one of the very few people who touched a lot of files at least once as a result.
PK: I bet your Git username is all over the codebase (laughing)
Yes (laughing). That’s probably right. Launching in the UK was our first experience launching a non-Euro currency in the app. There are also subtle localisation differences we had to support.
I’m proud that we accomplished this so rapidly. We’re also taking some lessons learned and applying them as we work towards the US launch. This is even more exciting.
To summarise though, I’m proud we made the UK launch and enabled new customers to enjoy the N26 experience in another country.
PK: It’s not easy launching a bank into a new regional area. Particularly when it’s completely different currency. Is there anything else you’d like to share as we come to a close?
Yes. I have three things to share.
First, I have a suggestion to Android Engineers to always write good quality tests. At N26 we expect engineers to write unit tests. If you open a Pull Request without unit tests, reviewers will definitely comment on that. We also introduced writing UI tests a few months back. We’re starting to see the benefits of these UI tests to ensure our features are always working. Always write good unit and UI tests. Make sure that your code is working as expected. You should always test things.
PK: That’s definitely a hard bit about software. Not breaking things when you make a change. What’s the second point?
Secondly, it’s very important to be as transparent as possible. It’s especially important if you’re working in a collaborative environment. Working in a team requires transparency and trust. Always be transparent. Give and receive feedback with your teammates. N26 is good with this.
We often have Q&A with co-founders in the company. With C-level people. I like these sessions as you get to ask questions from people you don’t often to talk to. You get to learn more. You get to see things from their eyes. It’s very helpful.
PK: And your final point?
Last but not least. Have fun! Having fun is one of the most underrated things. I also think it’s one of the most important ingredients. Work shouldn’t be tedious or boring. It should be fun.
PK: Great advice and a great perspective in life as well! Thank you very much for sharing more about the Android team and your own experiences.
Want to work with Mustafa in Berlin, Barcelona, New York or Vienna?
If you’d like to join us on the journey of building the mobile bank the world loves to use, have a look at the Android Engineer roles we’re looking for here.
