Matt started his career as a software developer at an eCommerce company in the United States. He’d had an interest in Japan, and so when a friend introduced him to an opportunity to teach programming in English at Japanese university, he jumped on it, and made the move.
After about five years of teaching, he was keen to gain some more industry engineering experience. LINE appealed to him because it was an app that not only he had used, but it also had incredible reach. “If you consider a service which has a lot of users, say an ecommerce site”, he says, “it’s definitely something that impacts the lives of people. Maybe people do a lot of shopping, but chances are low that they’ll go to the site everyday. LINE falls into the category of services where the users interact with it on a daily basis, which is cool.”
After applying via LINE’s job portal, he got a job as a server side engineer for the Sticker Shop team. Stickers are LINE’s emoji-like images that allow people to quickly convey a wide array emotions or reactions in chat. Some stickers are free, while others can be purchased.
His team often tackles projects to develop new ways of using stickers. While a lot of his current work hasn’t been released yet, an example from last year was creating the backend for “Custom Sticker” functionality. The custom sticker functionality allows a user to insert a short word of their choosing into a sticker. For instance, you can insert your name, or that of a friend, or any other word of your choice, and change it at any time.
Ensuring stability of our internal services while delivering the experience we want users of the campaign to have required a significant amount of engineering effort this past year. Despite this we were able to invest into trying a number of new things and from an engineering standpoint it was extremely successful.
Another common type of project is short term campaign work. For instance, every year LINE runs a New Year’s sticker campaign, which usually involves some sort of way for users to win a prize. He says, “This project in particular has a lot of technical challenges because it is released during one of the highest traffic periods of the year for LINE. Ensuring stability of our internal services while delivering the experience we want users of the campaign to have required a significant amount of engineering effort this past year. Despite this we were able to invest into trying a number of new things and from an engineering standpoint it was extremely successful.”
Time-limited projects like these are used by LINE to try out new technologies at a relatively low risk, as they avoid the need to maintain a new dependency indefinitely. Rather, as they naturally last only a couple of weeks or a month, they give an opportunity to evaluate a technology, and then apply the learnings back to the services which are permanently in place.
His team provides services to other teams, and as the company grows rapidly, more and more teams are consuming them. This has created an interesting challenge: not only do they need to build services that scale from a performance perspective, but also from a usability perspective. “That’s where the creativity starts to come in,” he says, “making something that’s easy to use for internal teams.”
I had never met someone that could actually do simultaneous interpretation, so the experience was pretty awesome.
As a company, LINE is quite distributed, and so he’s worked on projects with people in other countries. Sometimes the other people he works with don’t even share a common language, and so LINE employs a team of interpreters to help out. He says, “For example, we have an office in Korea, and in some cases, the Japan side of the meeting will be done in Japanese, and the Korea side of the meeting will be done in Korean, with an interpreter helping to facilitate. I had never met someone that could actually do simultaneous interpretation, so the experience was pretty awesome.”
Most of LINE’s engineers can communicate in written English without issue, and documentation is normally written in English. LINE also uses a lot of text chat, and has translation bots to help out. These bots allow engineers to communicate while writing in whichever language they are most comfortable in. In particular, these machine translation bots work great for translating between Japanese and Korean, as the grammar between the two languages is similar.
Using Japanese at work is a good forcing function for improvement. If you go to a meeting that’s in Japanese, you want to understand what’s going on.
Matt spoke some Japanese before joining LINE, and has increased his ability while working there. He says, “Using Japanese at work is a good forcing function for improvement. If you go to a meeting that’s in Japanese, you want to understand what’s going on. For me that motivated me to keep improving, and studying on my own.”
LINE does offer positions that don’t require any Japanese abilities, and the company has a lot of support in place for international developers. Still, Matt recommends learning Japanese. “For our team we hire some people that start with basically no Japanese ability”, he says, “From what I’ve seen, they’re doing okay. But the people that go to the company classes and study start to feel more engaged.” This is not because there’s a divide between Japanese and international developers, but rather that having some Japanese ability helps you to gain tangential knowledge from conversations you might overhear. Furthermore, in more senior roles, there’s a higher chance you’ll be regularly communicating with people from other teams, and in this situation, the more languages you can speak, the more smoothly you’ll be able to deal with that aspect of the role.
While Matt started as an engineer at LINE, last year he changed to a manager role on the same team. Though he still does a fair amount of development, his new role means he spends time helping his team members with career growth. He says this includes regularly working with his team members to see where they want to go career-wise to see if there is anything he or the company can do to support them in that.
LINE has a job leveling system that helps engineers understand how they can be promoted through the organization. Matt also talks to team members who have recently had a level change to better understand the challenges of meeting the requirements for promotion, how they felt going through the advancement process, and if there’s anything he can do to improve it for them. By doing this, he hopes to improve the process for everyone.
I think it is helpful to have someone to talk to about how your career might progress, especially if you are new to development.
For Matt personally, helping engineers grow their career is important to him. He says, “I think it is helpful to have someone to talk to about how your career might progress, especially if you are new to development. For me personally, when I first started as a software developer, I did not have a very clear idea of where my career was going to go. So the people who talked to me about it at that time were really helpful to me.” Now as a manager, he in turn gets to help others grow their career.
His responsibilities also involve helping to hire developers by writing job descriptions, screening applicants, and interviewing candidates. Based on his experience in that role, he has some tips for people applying to LINE, which also hold true more generally.
In your application, it’s important to help the person screening it understand how you’ll fit into the position you’re applying for. He says, “For me, it helps a lot if I can get a feel for what kind of project you had worked on in the past or currently, and how that might bring skills, or some kind of new knowledge to the team. In some cases, that’s really difficult to tell from a resume.”
Without making the resume too long, put in some sort of detail about what you used that was interesting and that had an impact on the project.
Rather than just listing your skills, he advises you go into detail with how you have applied them. He says, “Say that you have a lot of experience with Kafka, and then you write in your experience area ‘used Kafka to make a news article parsing application’. That’s positive, and actually our team is interested if you have Kafka experience, but it’s difficult to tell how exactly you used it because the technology is so broadly applicable. Usually there are difficult problems to solve whenever you’re doing a project like that, so without making the resume too long, put in some sort of detail about what you used that was interesting and that had an impact on the project.”
Similarly, you should clarify your role within projects, as “sometimes the description is too general, meaning that it is difficult to tell what the impact was of the project that you worked on, or it’s difficult to tell what your role was.”
Another tip is to avoid using terminology specific to the company you’ve worked for, as it can make it impossible for the reader to understand what you are talking about. For example, he’s seen resumes mentioning some internal technology that’s not even published.
Having strong technical communication skills helps a lot
As for the interviews, he says you can often get an idea of how to prepare for the interview by reading the job description and paying attention to what is mentioned there. Beyond that, for him “having strong technical communication skills helps a lot, so you can clearly and concisely express your idea of how you think the implementation should be done”.
He also says that while preparing for interviews, don’t stick just to “closed questions” that have a single, correct answer. Rather, also prepare for open ended design or architecture questions. These questions are part of his team’s interviewing process, and are especially important for senior developer roles.
To prepare for these questions, he suggests “Ask someone that you know to ask you a very open question that they’re almost positive you’ve never considered before, and then timebox it, and try to see how you deal with it. When practicing in this way I think it’s important to not skip parts of the discussion which seem difficult. When there is nothing on the line in a mock interview, sometimes we may have a tendency to move to the parts that we feel we do have a handle on how to answer and leave the rest for another time.
“In an actual interview, this is also possible but of course it’s better to be able to come up with some kind of solution to a difficult part of an open ended question. When you’ve run into something tough that you’re not sure how to deal with, instead of skipping directly to “the answer”, start by actually defining why it’s difficult to begin with. This will let you continue to have a technical discussion with the interviewer while thinking about the issue.”