Interview with an iOS Engineer — Meet Daniel Peter
N26 is the mobile bank the world loves to use. Late last year, we launched one of our most successful products, Spaces. This product really demonstrates how we apply our company value of Simplicity to helping people interact with their finances in a much simpler way. I spent some time behind the scenes with one of our iOS Engineer who was working on the Spaces product, Daniel Peter.
PK: Hi Daniel. Thanks for making time to chat. Please introduce yourself.
My name is Daniel Peter and I work as an iOS Engineer at N26. I have been in the company for more than a year now. I joined after finishing my Masters in Computer Science at the Technical University of Munich. I worked as a Software Engineer part time during my studies. This means I had some experience with iOS and writing Swift. I have been writing Swift since it was in Beta.
PK: An earlier adopter!
Indeed! I was lucky. During my studies, my school offered a practical course, developing in iOS, which I took. At the time, Swift was super new. In the field of education, you can use new technologies without worrying about breaking production code. They taught Swift instead of teaching students and older, and more likely to be deprecated, programming language. We built a full game after just a week, called TinyWizard and you can still download it on the AppStore.
PK: How did you come across N26 and the role?
After finishing my masters’ thesis, I looked for a position in Berlin as an iOS Engineer. I felt more comfortable applying for an iOS job than I was applying for a TypeScript or JavaScript job.
It was a coincidence that I saw the job opportunity at N26. I have a friend who also works for N26 as a Backend Engineer. We were just sitting in a bar talking about new technology and trends. My friend referred me to the company. I completed the interview process and ended up with a job offer.
When I joined the company, I joined a team of 5 people. The team built a well modularised, but large application because it does so many different things.
“Modularisation makes it really easy to test”
PK: Tell us more about how the iOS is modularised and how that makes your life as a developer easier.
Every feature becomes a module. Modularisation makes it really easy to test. It scales really well. In your daily time, your build times are reduced by a massive factor. Rather than building the entire codebase, you rebuild the one feature and modules it needs. It also makes discovering code really easy because modules are named after features. You can jump straight to the module based on the feature that you’re working on.
Feedback is really quick.
PK: What team are you working in and what does your day look like?
I’m part of the Home Group, working on a new feature for Spaces. Spaces is a feature that allows you to manage money in a nice and simple way. In the end, they are similar to sub-accounts. You use drag and drop to move money around. I love it because it’s such a simple user experience.
In the Home Group, I work as a part of a cross-functional team that consists of backend engineers, an android engineer, and me, as the iOS engineer. We have a designer jumping in when necessary and a Product Owner (PO).
PK: Tell us about how you ended up working on Spaces.
When I joined I was part of a different Product Group, working on financial products like Credit and Overdraft. I still had some learning to do so I worked closely with the iOS Tech Lead, who showed me how we build the application. After some time, we said it would make sense to switch groups. Another developer, who was working on Spaces, went away for a conference and vacation. I took over for him and was working with the codebase for the next three weeks.
The codebase was really clean, well structured and well architected. This made it really easy for me to jump in. I fixed a minor bug on the very first day I joined the Spaces team!
It shows the speed of how quickly we can onboard people onto new features because they are so self contained and small.
“Our user research challenges the assumptions and ideas you have about what “simple” means.”
PK: What was challenging about working on the Spaces product and why?
The challenging part of building Spaces was nailing the user experience. To do that, we run a lot of user research with designers and user researchers. What’s interesting is how we end up with the product we built.
We all had ideas about how a flow should work. We all had opinions about how interactions should work. Through user research and testing, we discovered users expected something completely different. It was really interesting!
Our user research challenges the assumptions and ideas you have about what “simple” means. The testing really helps you understand how people want to use a feature in a certain way and why, that you can’t predict. It leads to a much simpler product.
“It’s very different from bands who carry money around in a little box!”
PK: What’s your favourite part of Spaces?
For me, it’s the ease of use. When you see Spaces, it’s instantly clear what it does. It’s super easy to set up a sub account when you compare it to other banks. It’s super easy to use and to set money aside.
For example, I also happen to play in a band. We sell merchandise like t-shirts and vinyl records. I’m responsible for managing finances for the band. I opened a Space and whenever we sell something, I just move money into a Space I created and it’s safe. If I compare this to how other bands manage their funds, it’s so easy and convenient. It’s very different from bands who carry money around in a little box!
PK: You were talking before about the modularisation such as how easy it was to find and make changes. What other aspects do you enjoy working with the iOS team or architecture?
Coming from a technology perspective, it’s really exciting to work on application that is so big and used by so many people. In my previous jobs, I worked mostly on prototypes. Most of the time, they remained prototypes too. I published an internal application with some real users, but it was only for thirty end users.
The scale of the application is really exciting. You publish to the App Store. The next day, more than a million people update their app and use it. That’s really exciting!
The way we build the app reflects this scale too. The architecture is really important for us. We have a guideline on how to build features. As a team, we rely on architectural decisions. Whenever we want to introduce anything new, we come together as a team for a full day which we call an iOS Day. We sit in a room to discuss and then we make decisions as a team. It’s great that we can discuss approaches and agree as a team. In the end it makes our life a lot easier because we are aligned on how to design a feature and review code.
“The Handbook provides a lot of context for new joiners.”
PK: You said that the team was 5 people when you first started. What is the size now and how did you onboard so many people?
We grew to 14 people at this point (PK: as of April 2019). Onboarding is straightforward when you join. All the features are self-contained in their modules. When you work on a feature, you can easily find the code for the feature. We have an agreed foundation which we share through our Handbook. Our Handbook is the documentation about how we work and build features.
For example, we describe how we handle networking in our application, how we handle flows, and how we handle push notifications. All of these approaches are written down and kept up to date in this Handbook. The Handbook provides a lot of context for new joiners.
I also found that the iOS team is really supportive. I feel you can post any question to slack like, “I’m encountering this issue. Has anyone faced this before?” and you’ll end up with several responses. Everyone is super supportive.
Being supportive, having great documentation and building a team that cares about people who have just joined is the secret to onboarding a lot of people.
“Don’t be afraid to ask questions.”
PK: If you were to give advice to a starting iOS Engineer, what would you say to help them be more effective?
I would say, “Don’t be afraid.” Don’t be afraid to ask questions. Don’t be afraid to do something wrong. In the end, it will lead to a situation where you will learn something.
I would also add, “Trust in your teammates.” We all have domain knowledge, which you build after a certain time. No one expects you can learn everything in a day, or know the whole domain in a day. I don’t think anyone knows the complete N26 domain at all times as the app is changing so fast.
PK: Fantastic advice. I think this is true, not only for new starters in the iOS team but also for all engineers in all environments. Thanks for sharing your time and giving us some great insights into how the team works.
Want to work with Daniel 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 iOS Engineer roles we’re looking for here.
