---
# System prepended metadata

title: '#41 - Dzung Nguyen'
tags: [story]

---

---
tags: story
---
# #41 - Dzung Nguyen

Techie had the opportunity to talk with Mr. Dzung Nguyen - software engineer at DoorDash, currently living and working in Japan.

"If I could go back to when I was young and dumbed, I would believe more in myself… The media has always written about successful people. But we all don't know how many trials and tribulations they have gone through. Everyone has different goals, so just focus on your path."

---

![](https://i.imgur.com/emDuGMd.jpg)


**Q: During your working time, how do you usually develop coding skills?**

"When I was working in Vietnam, I always wanted to go to Japan, Singapore, or the US. The first thing that comes to mind is, of course, learning English. The second is improving coding skills. At the same level, the company will undoubtedly choose people in their country not to sponsor the visa. Then we have to excel in both the algorithm to interview and the technical skills to work. It's hard to balance these two. Back then, I would practice LeetCode and the algorithm in the evening. The rest would use the time to improve technical skills by doing side projects and solving problems I encountered at my main job. Those solutions are often generalizable, and I also make them open-source under the company's permission. Because I wanted to make a quality open-source, my technical skills also increased significantly. When I researched and consulted thousands of best practices to apply to my small project, I gained experience and understood why people did so. When I understood the root cause, I was super happy!

Regarding this technical skill part, besides building and researching a lot to gain experience, we must be curious. Don't stop at doing your part! For example, if that task is related to another team, we should learn more about how this whole feature works. Why is this API related to another, and so on. Once we understand it, we will do it very quickly because we have already formed the flow in our head. We are still young; if we're not smart enough to read and understand quickly, let's try to learn and do, a lot.

Some of you will wonder, is curiosity instinctive, or can it be trained? I can only say it depends on your purpose. For example, everything I did above is to fulfill my goal of going abroad and working for a big company. It's certainly not easy, and there's a lot of pressure. Even in interviews, there's no reason people would ask shallow questions. So what I could do right away was dig into what I did every day. When coding JavaScript, I can easily do with variables but looking back, how many types of variables are there? Why are there two types of variables? And why was Closure born? What context should I use? Starting from such small things but also takes a lot of time.”

**Q: Before doing anything, set a proper goal is essential. Do you have any advices base on your experience?**

Yep, setting goals are very important; because from there, you will have questions about how to achieve them, then take specific actions. However, setting a reasonable and specific goal is difficult. For example, if we say, "I want to work at Google in the US," so what can we do to achieve that?. Let's break it down into smaller goals and form a roadmap to get to that vague goal at first. Every mini win on those small goals motivates us to move on.

One of my recent mini wins is [https://www.spotit.page/](https://www.spotit.page/) - a Spotify Extension I built with 40k+ downloads so far. You can read about the building process as well as the product perspective I wrote [here](https://www.dzungnguyen.dev/hanh-trinh-build-spotify-extension/vi/).

![](https://i.imgur.com/yXNSU3E.jpg)


Talking more about Spotit, at first, I thought of building it for myself. Because I basically didn't know if there was a demand or not. But how can I collect data to prove that there is a demand? So I just asked a few more friends, and with 9/10 people saying they wanted to use it, I decided to do it. The total time I spent on it was more than a year. When I released the first version with about 1000 users and started to have feedback, I was motivated to continue developing.

**Q: If you could go back to when you were young and dumped, what would you say or change?**

If I could go back to when I was young and dumped, I would believe more in myself. There was a story like this. Back then, I set a small goal to write a technical article for an Australian technology magazine that I’ve often read. Because of the busy work, after over a year, I sent a direct email to the editor and wrote for a month. And guess what, I've had my first article published. I was very happy! The royalties are not much, but I'm super excited thinking of many people reading my articles. So I want to say: After setting a realistic goal, will we strive enough to do it? And if no one believes in you, at least you believe in yourself. The media has always written about successful people. But we all don't know how many trials and tribulations they have gone through. Everyone has different goals, so just focus on your path. It's okay to fail; consider it a lesson.

**Q: Do you think there’re a limited age for those working as a software engineer?**

“To be honest, I have worked for 7 years in this industry. Although I somehow can't keep up with the speed of the younger people, there is nothing to worry about. I have my own advantages: Be more careful and have experience, especially the tasks that involve multiple systems or need many teams to sit down to brainstorm. Just like a problem I encountered recently. The way my company has designed software is not really good. It doesn't help engineers easily to test. I've searched a lot but can't find a way to test it, and it involves a lot of teams. You see, the company is too big; I have to spend a lot of time finding the right one. In the end, we decided to make version 2 on a smaller scale. Everything is easier to test.

In short, the problem still lies in communication. The timezone between Japan and the US is 13 hours apart, so I only have late evening or early morning hours to communicate with the team. Therefore, I have to learn how to ask the right and enough questions to serve my work. With a remote team, there are three communication levels:

- Communicating in the team's group/channel that can solve my problem
- If no one answers, see the codebase, who is the owner, and ping that person directly. Of course, doing so would be quite annoying, but it was necessary for the job.
- If the person doesn't reply either, then ping their Manager. The Manager will definitely reply.

So, how to ask the right and sufficient questions? This has to be learned; sometimes, it's easier to answer than to ask the question. Try google "How to ask a question." There are many! The first thing is, always know what the output you want is before asking others."