A Day in the Life as a Backend Engineer in Merpay
A tour guide of the working environment for non-Japanese speakers
Reference Links
Transcript
What does it feel like to work in Merpay? In this video I’m sharing my experience working here as a backend engineer, to give you an idea of what it feels like to be part of the first unicorn company in Japan.
Hi, My name is Adler, and welcome back to the channel where we talk about software development and career. Today I’m sharing the experience working as a Backend Engineer in Merpay. There is a lot of public information that you can find on Google, so I’m trying to talk about things that are more specific to my personal experience. Also, some of the things I’m talking about in Merpay might be able to be applied to Mercari as well, since they share a lot of resources together.
Also, feel free to jump to different sections using the video chapters in the description below.
What does a usual day look like?
We’re still working from home at the moment, so I usually get up around 8:00 or 8:30 am and start to work between 9:00 and 9:30 am. We have a “flex-time” system where we are free to choose when to clock-in or clock-out, as long as we show up in meetings and finish our work on time. Some members will choose to start work late and some other members might choose to finish their work early. It’s all personal preference.
When I start my work, I’ll go over my TODO list. The tasks are probably very similar to yours. Development, code review, planning, and meetings. For time arrangement, it depends on how many meetings I have that day. Our team does not have a daily standup meeting, so sometimes I have zero meetings. During that time I can focus on my development work, but sometimes when it’s busy, I might have five or six meetings in a day.
We don’t usually have regular meetings in the morning, so before lunchtime, I’ll be able to focus on my own development work, or we also have Japanese classes in the morning for foreigners like me. I would try to finish the most important tasks in the morning because it’s the time when I can focus the best.
During lunchtime, there might be some events. We have regular English-learning lunches for English learners in our team, and English speakers might join to help as well. We also sometimes have mentor lunch for members who join the team, and team-building lunch just for fun. During the WFH period we’ll order our lunch from somewhere and enjoy it with our team. The lunch is on the team.
In the afternoon, there are different kinds of meetings. Most people are at work from 3:00 to 6:00 pm so it’s the most popular time for meetings. Our team is using the agile methodology so we have sprint planning every two weeks, team retrospectives every two weeks, a weekly meeting for reviewing technical debts, and a weekly meeting for the entire backend team to sync important updates.
I know some team members will choose to take a break in the afternoon between meetings. It’s WFH now, so we have more choices than in the office. Some will choose to work out, spend some time with their family, or take a quick nap. Personally, I’ll have a coffee and watch some videos. If I want to take a walk, I’ll go to the supermarket near my place for groceries where it takes about a 5-minute walk.
Sometimes we’ll need to answer questions from other team members, respond to inquiries from customer support, or handle system incidents if there’s one. It’s just regular business operations that we can see if every company. If there’s time, I’ll try to finish my other development work and clock out before 6:00 or 7:00 pm so that I can keep my work-life balance as much as possible.
By the way, it’s required to work 9 hours a day on average, including lunch. Like 9 AM to 6 PM. When I say “on average”, it means that we don’t have to work precisely 9 hours every day. The average is by month, so, for example, you can choose to work 6 hours today, and 12 hours tomorrow, which is also 9 hours on average.
Before we move on to the next section, if you’d like to watch more videos like this, please consider giving it a like and subscribing to the channel.
Language.
Merpay is a Japanese company, and when it started, most communications were done in Japanese. Recently it's been moving toward a more English-friendly environment. Depending on the team, some teams are communicating entirely in English, and some teams just get started recently.
You don’t need to know any Japanese to work here. Even if there are times when you have to work with Japanese colleagues, they have extensive language support. They have free Japanese classes to attend, and most of the time they have interpreters ready for meetings.
My English usage in the daily work is around 80%, with another 10% in Japanese, and the other 10% in Mandarin sometimes. I’m very lucky that most members I work with are able to communicate with me in English. But as I take more and more responsibilities, it’s inevitable that sometimes I need to talk to Japanese speakers who are still working on their English proficiency. It’s very challenging to speak Japanese directly to talk about work, but it’s also a great opportunity for me to practice.
Development Workflow.
Every backend team has a different workflow when it comes to teamwork, but basically, every team is taking a little bit from the agile methodology, and trying to find an efficient way to maximize productivity. Some small teams only have three to four members, and some big teams might have 10 to 15 members.
As you might already know, most of the applications in Merpay are built with Golang, working on Kubernetes in a micro-service architecture. One huge benefit of working in Merpay as a backend engineer is that we don’t have to do frontend testing. If we’re working on a micro-service, then we only need to make sure the requests/responses are working as expected for this single service. For me, it's a huge plus. Personally, I hate frontend, and I hate JavaScript. In my previous jobs, I had to open the browser to test everything before I can submit my code. I really hate that part. In Merpay, the QA team will do it. It saves a lot of time, energy, and curse words during development.
For development workflow, it might be different by teams, but they should be similar. In our team, we use GitHub flow for version control, and we usually focus on a single micro-service at a time. Every external connection is mocked in the codebase. Once a feature or bugfix is done and reviewed, we create a release branch for QA. We then deploy the test docker image to the test environment for QA members to run the tests. This is the time when our code will actually talk to other micro-services. If something is not working as expected, we will work with QA members to figure out the issue and fix it.
One big challenge every team has is to handle technical debts. For my team, we have a Slack channel that every team member can post whatever issue they want to resolve. For example, “performance issue here” or “this part should be removed”. We have a weekly meeting for going through the messages and decide whether we should create a ticket for each issue. If a ticket is created, it will be put in the discussion in sprint plannings and assigned a member.
Career
In the Merpay Engineering department, there are different kinds of roles in two career paths. One career path is development. The other one is management.
The first role is as a regular developer. This might include other non-developer roles like QA so it usually called a “player” in the company. The next one is the tech lead. A tech lead is the leader of a team. The difference between a tech lead and a developer is that a tech lead would be assigned with more senior developer responsibilities. For example, a tech lead would need to communicate with other teams for technical solutions, more mentorship, more code review, and more meetings with product managers and engineering managers. Basically, a tech lead is a go-to person if you have any technical questions regarding a team. I’m not saying that a regular developer cannot do these, but there will be more expectations on a tech lead to resolving issues.
The next role is as an engineering manager. Engineering managers would focus on managing team members, and participate in company strategy discussions. They don’t do development, so most of the time would be spent on planning, meetings, and more meetings.
As an engineering manager, there is also a “player/manager” role. This just sounds like a class in Dungeons & Dragons. Half of the responsibilities would be doing development, and half of them are management. The benefit is that the managers will still have a chance to actually participate in the development and keep up with the technical change in applications. In that case, the managers would be able to give more insights and suggestions when talking to their members.
Moving up would be the manager of managers and VP of engineering. These roles would be involved with more management.
From what I can see, it’s very flexible that we can choose whichever role we want to take. We might join as a developer, move up to tech lead once we have enough experience, move to a management role if we like, and move back to the development role if we want some fresh air.
One thing I would like to add is that there’s no limit in the tech lead and the developer role. Even though there are many roles in management, if we want to focus solely on development, and are good enough, there is a huge space here for developers to grow. It comes with more responsibilities and, of course, much more salary.
OK. I hope you find this video helpful. If you have other questions regarding working in Merpay, leave a comment below, and I’ll see if I can help. I’ll see you next time.