Day in the Life of a Graduate Engineer at Wise

I’m Sonnie, a graduate iOS developer at Wise. I work in the HOLD team, which looks after our multi-currency account and the funds that our customers hold on their Wise accounts. Together we build and maintain our vision which is:

Empower people to save and grow their money in any currency, wherever they are. Money is secured, easily accessible, performing for who owns it, and held with clear or no costs.

Our team, like all teams in Wise, is autonomous. As a team, we have everything we need to build what our customers want and the prerogative to do it. I, therefore, work not only with engineers but with people from product, design and operations daily.

My graduate scheme offers a lot more flexibility than most. I don’t have set tasks or rotations. Instead, together with my mentor, I’m able to steer my work in the direction that I think I can add the most value to our customers while learning. No two days are the same, but here’s a typical day as a graduate engineer Wise.

7:00–8:00 — Walk and breakfast 🥐

I wake up at 7 am every day, and start my morning routine to get me up and ready for work. As we’re working from home, I go on a 30-minute walk before work in lieu of a commute. This gives me some activity and fresh air before starting work, getting me in the right mindset for the day. I then get home, have a quick breakfast and make a coffee ready to start my day.

8:00–8:30 — Catching up and reviewing pull requests 💻

Traditionally Wise’s office hours are between 9 am and 6 pm, but I know that I’m considerably more productive in the mornings. To maximise this, after a brief discussion with my lead, I shifted my working day an hour earlier. This better suits me. I love the first hour of the day, where few people are online. With less chatter, I find it much easier to focus.

My day starts with catching up on Slack, where the majority of conversation happens as we’re all working entirely remotely at the moment. I’m able to catch up on any progress from team members in different time zones and check if any tasks need doing immediately. I also review any pull requests that I have open; if they’ve been approved, I merge them while the build sever’s quiet. If not, I make those changes before people are online so that they can review them once they’re in, letting me merge the changes later in the day.

8:30–10:00 — Working on our app 📱

During testing of the app, I noticed that one of the screens in my team’s domain has some accessibility challenges when used with larger font sizes. The text didn’t have room to expand, truncating once it ran out of space, resulting in a poor user experience. Using the app’s analytics, I confirmed that customers are using these accessibility fonts within the app, so took it upon myself to make improvements for these customers. I found that a similar issue had been noted when holding verbose currencies, where for example, where £1,000 was equal to ¥13,6071.76 (Japanese Yen).

I quickly discussed this issue with our team’s designers with some screenshots demonstrating the problems customers were having. They had some early-stage designs they shared which I could use as a starting point, which then together we could build from and continue to use to prototype. This would be the first full screen I’d built in the app, so was my first opportunity to create a full VIPER stack from scratch. I looked at the existing implementation to understand the data I’d need and how it should flow between the different components.

I knew I’d have lots of questions as a result of this initial exploration, so I scheduled a paired coding session with my mentor Christie. I noted down all the questions I had as a result of the existing implementation so that I could ask them and better understand the screen. To best utilise this session, I then stubbed out the basic components and got an initial design ready for us to then iterate and improve upon.

10:00–10:15 — Team stand up time 💬

I joined my team’s daily Zoom stand up meeting. We each give a brief description of what we achieved in the previous day, and what we’re planning on doing and discuss blockers if there are any. I listened to what different team members were doing on the various projects the HOLD team works on. I then explained that I was working, with the help of design, on building a prototype to replace an existing screen to improve the user experience for our visually impaired users. We finished the daily standup with a team tradition, a synchronised clap which never quite works (but always produces a laugh) remotely 👏🏻 .

10:15–11:00 — Quick break ☕

I had a small gap in my calendar and an in-depth meeting up next. I took this opportunity to take a quick 10 minute stand up break away from the computer. When working from home, it’s really easy to forget to take breaks and work straight through the day. I find that after stretching my legs, filling up my bottle and doing any other little chores that I return with more focus.

10:30–11:30 — Staying in touch with our wider iOS guild 👀

I then joined our weekly iOS guild meeting. The guild is made up of the iOS engineers across the various teams at Wise, who together work to:

Provide a reliable foundation on iOS to enable teams to deliver value efficiency and consistently delight customers (and beat the Android app).

Each week various members are free to add topics to the agenda that they feel need discussion or action by the whole guild. Anything goes, from code changes, testing approaches to the adoption of new technologies. This week’s meeting primarily focused on a proposal to align our low-level architecture across teams. The proposal aimed to help the guild create consistency between different domain level frameworks which are managed by the various teams. Doing so would align our terminology with Android to create a common language to facilitate discussions between mobile engineers. It would also create consistency in the repository, helping improve the ease of reviewing a pull request outside your domain area.

There was a lot of discussion from different members of the team who have a lot of iOS development experience, sparking an excellent debate. Listening in was a fantastic learning experience, helping me understand why the current approach existed, and what new pattern and naming scheme would make the most sense moving forwards. As a result of this discussion, a follow-up meeting was set to give everyone some time to consider the different options and come to a consensus as to what approach may work best given the various teams differing requirements.

12:00–13:00 — Lunch time 🥗

I choose to take my lunch break a little earlier than most, as a result of my earlier start. As well as eat, I use this time to get out of the house; whether that’s to run errands, get a coffee or go on another walk. Whatever I’m doing, I always make sure that it’s time away from a screen.

13:00–14:30 — Paired coding session with my mentor ⚙️

It was time to continue the prototype that I’d started in the morning, by pairing up with my mentor Christie. We do our paired coding sessions over Zoom. I drove it by sharing my screen and controlling the mouse and keyboard. She observes and helps me understand and guides my implementation. The session started with me explaining the issue that I was solving, similar to what I did with the designers, so she understood the scope of the problem. I then walked her through my understanding and stubbed implementation of the different VIPER components, with her answering the questions that I’d flagged earlier.

With that understanding in place, we started to collaborate on finding the clearest and most maintainable way to build the screen. Although the prototype’s initial scope was simple, there was a lot of complexity that’d be added once it replaces the existing screen. Pairing with someone much more experienced helped me avoid common pitfalls, saving a lot of refactoring time in the long run. At each step, we were considering maintainability, how to make the UI scale elegantly with the larger accessibility sizes and how the feature would appear to those using voice over to navigate the UI.

Although it was a short session, it gave me the foundations to continue working on the prototype independently.

14:30–15:00 — Leading the weekly iOS app release 🚀

I was selected as the release captain for the app this week, meaning the weekly release of the iOS app was my responsibility. This week was an exciting release; we were doing a major version release bump from version 5.43 to version 6.0 due to my team’s new feature, Jars, which helps our customers organise their money in the app 🎉.

I’d already done the code cut earlier in the week, seeding the various beta versions out via TestFlight to our testers as bug fixes were cherry-picked. I needed to create the final build and upload this to App Store Connect, then update the release notes in all the languages we support. Then, submit the app for approval from Apple over the weekend ready for a phased release on the following Monday.

15:00–16:30 — User research in progress 🔎

I then sat in a user research session for our upcoming investments product. The session involved watching a real user navigate around a prototype of the app. While doing so, they explained to the interviewer how they felt and voiced any confusions they had with the different screens within the flow we were testing. The prototype used was derived from ideas and discussions the team had collectively iterated upon after the previous round of user testing. We were able to watch and discuss in real-time about what we were noticing about the user’s behaviour and thoughts. At the end of the meeting, we collated this information together and had a broader discussion about the implications of the feedback we’d received.

It was great to see that some of our assumptions had been correct, but even more interesting to see where we’d missed the mark and what we needed to continue to iterate on based on this feedback. I’ve been enjoying the opportunity to participate in shaping and guiding a new product at such an early stage, as mobile design is one of my interests. It’s also teaching me a lot about how real users are using the app, which is helping me make better decisions about how I iterate on existing features within the app.

16:30–17:00 — Final admin 📒

As I said, I know that I’m less productive in the evenings, so I plan my day around this. I spend the time at the end of the day to finish any small admin tasks that I have left to do. I also prepare the tasks that I will do the next morning. This allows me to get any questions I might have answered while people are online, letting me fully utilise my productive and focused time the following day.

While working remotely, I’ve found that it’s crucial to keep a strict boundary between work and life. At the end of the day, I fully shut down my laptop, doing so makes the process of quickly logging on to check something much more time consuming, and helps me keep a work/life balance.

17:00 — It’s a wrap 🏁

Similarly to how I start the day, I always end the day with some exercise, be it a short walk or a cycle due to the lack of commute.

P.S. Interested to join us? We’re hiring. Check out our open Engineering roles.

Follow my personal blog for more updates on my journey at Wise and all things programming and productivity.