New webinar: "The Remote Job Search: My Microverse Journey" with graduate Paul Rail
Watch Now

We have launched an English school for software developers. Practice speaking and lose your fear.


An interview on open source, programming languages, a thrilling career, and life in Silicon Valley

A couple of months ago, I came across an amazing open source project on Github called “Tech Interview Handbook” that contains hundreds of useful tips and challenges to help software developers get ready for coding interviews.

Not surprisingly, the repo already had more than 20,000 stars and more than 40 different contributors. The person who had started it all and was responsible for the project was a software developer called Yangshun Tay, and I immediately felt really inspired by his work.

At Microverse, we’re always looking for exceptional people with inspiring journeys. We host a weekly Lunch & Learn where guest speakers share their stories and provide tips on how to start a career in tech, no matter where you are in the world.

This time, we wanted to try something different, so I asked Yangshun if he would be open to doing a quick call and letting me interview him, and he humbly said yes!

I learned a lot from him during the interview, and we talked about his decision to change majors to pursue computer science, his first steps and projects in the world of software development, his passion for open source, and his experience working as a software engineer for some of the largest tech companies in Silicon Valley.

Without further ado, here's the interview…

Hi, Yangshun. Can you share where you're from, which programming languages you work with, and what your favorite food is?

I’m from Singapore, I mainly use JavaScript (React, Redux, GraphQL, Relay) and Hack (strongly-typed PHP) these days. My favorite food would be sushi and hotpot, which, thankfully are commonly available in California where I live now.

How did you get into software development?

I was originally enrolled in a Mechanical Engineering course when I started studying at National University of Singapore (NUS). There was an introductory programming class that all engineering majors had to take, which was taught in C for my case. I was really afraid of programming at that time because I briefly learned HTML during my high school days and didn’t really get it. Keeping an open mind, I gave programming another stab and grew to really enjoy it! In my second semester, I took a more advanced data structures class and in my third semester became a TA for that class.

In my third semester, I begin to realize that I didn’t enjoy the Mechanical Engineering classes as they were highly theoretical and had little hands on. I made the hard decision of changing majors to Computer Science at the risk of losing my school-provided scholarship. Thankfully, the school let me keep the scholarship and transfer majors!

After transferring to CS, I enrolled in one of the most rigorous classes NUS School of Computing had to offer — CS3217 Software Engineering on Modern Application Platforms, which teaches industry-standard Software Engineering through the iOS platform. That was my first time building apps outside of algorithms homework.

What are some early projects that you are really proud of?

Tenza Yakitori — A cooking simulation game for the iPad which we produced as the final project of CS3217. This was memorable because I created the assets for the game, was heavily involved in the engineering and we eventually launched it to the App store.

It was an app for a real business, Tenza Izakaya, a Japanese restaurant which used iPads as menus. Using a tablet as the menu is a common practice these days, but back in 2012, it was still a novel idea. Our project was about making the menu into an app (it was previously a PDF) and adding a game into it to introduce a rewards system. Our game trailer can be found here on YouTube.

NUSMods — Initially, it was a timetable builder for NUS students to easily build their timetables each semester as the school did not provide a decent timetable builder. Over the years it evolved into a one-stop platform that provides both useful tools and an avenue for students to share their knowledge and experiences.

I’m extremely proud of this project as it solves a real need and has a large impact on NUS students. These days, a new team has taken over the development and they are the best and brightest NUS has to offer.

What was your first job and how did you find it?

My first job was an internship in Silicon Valley under the NUS Overseas College program at a startup called EasilyDo (now Edison). It was my first job where I wrote software alongside professional engineers and it was definitely very memorable. I learned many good industry practices from my supervisor and teammates and did work across the entire tech stack — back-end, mobile, front end.

I loved the autonomy my supervisor entrusted me with. I think one downside was that at a small startup with just over 10 engineers, we weren’t given too much mentorship and guidance but thankfully help was readily available around me.

What was it like working at Grab? Which projects did you work on, and how did the fierce competition with Uber for the Asian market affect your work as a software developer?

I gained a lot of insights into the ridesharing industry by working at Grab. For a company like Grab, operational work (offline) might even be more important than the engineering work (online). Grab had a very strong offline team which was important in helping Grab gain a strong position in the ridesharing market in the early days.

I worked on Grab for Work, an enterprise solution for businesses to allow their employees to take Grab rides paid for by the company. Through the project, I got to interact with many cross-functional coworkers and it was constantly a challenge managing their expectations and delivering to their requirements. It was also fun to occasionally put on multiple hats when I helped out the marketing and business development team in their efforts to make Grab for Work better.

Uber had many more engineers than Grab, and naturally, they developed and shipped products at a faster pace. Initially, Grab was playing catch up to Uber but over the years, Grab found ways to differentiate itself and has improved greatly in terms of engineering quality and efficiency. I took a lot of inspiration from Uber for Business when developing some features of Grab for Work and I’m very impressed by Uber’s engineering standard.

Have you worked at a small startup too? How would you compare that experience to working for some of the biggest tech companies in the world?

As mentioned earlier, I worked at a small startup called EasilyDo. Due to the sheer size of the company, small startups do not have that much of a need for infra work and just have to focus on developing products. In contrast, big companies have dedicated teams to improve engineering productivity and development experience. Big companies also have the bandwidth to build tools in-house which have good integration with other existing tools.

Early in my career, I was interested in developing products but lately, I am also exploring infra-related work, such as building tools and reusable libraries.

Why did you decide to move to Silicon Valley and how was the process? Did a company approach you or did you just apply?

In the middle of 2017, I decided that I wanted a change of environment and was keen to be exposed to life working in large companies like Facebook and Google. I studied and prepared very hard for interviews and had a few referrals from friends working at those companies. The interviews went well and I landed myself a Front End Engineer job in Silicon Valley! It is one of the best decisions of my life to move to Silicon Valley to work. I wish I had done it sooner.

Could you tell us about the different interview processes you've been through so far? How did they work?

There aren’t too many different interview processes, but there are a few types of interviews. These are the type I’ve seen before:

Algorithm Question — Candidates are asked an algorithmic question which they need to solve on the spot, either writing code on a whiteboard or an online editor. This process heavily favors CS undergrads who have their CS101 algorithms fresh in their head.

Many people complain that the interview process is broken due to the over-emphasis on algorithms which aren’t commonly seen in day-to-day coding as a Software Engineer. I agree with this sentiment to some extent but I believe Software Engineers have to be strong in their fundamentals regardless of how long ago they have left school.

This type of interview is used by most large tech companies who have no lack of good candidates applying to them and can afford to have false negatives.

System Design Question — Candidates are given a large-scale (usually) system to architect out on a whiteboard. The question is intentionally vague so that the candidate can demonstrate their skills of clarifying requirements and steering the conversation in the direction of their strengths.

This kind of interview commonly involves drawing diagrams on whiteboards, making back-of-the-envelope calculations and database schema designs.

Take Home Assignment — Candidates are given a short assignment where they have to build a small app. Candidates can attempt it at home at their own time and later submit for grading by the company. These kinds of questions are definitely more relatable to what Software Engineers do for a living but can take up significant time and many engineers with families do not want to invest the time into doing it, especially if they are good at algorithm questions.

This type of question is great for demonstrating language and technology proficiency and software design skills. I personally am better at this kind of questions as I don’t have to study or revise for them.

Front-end Question — For Front End roles, the questions tend to focus on relevant domain knowledge on the target platform (Web, iOS, Android, etc). I only had experience interviewing for Front End Web roles and they usually involve implementing a widget or commonly-used JavaScript utility functions. Live coding environments with previews are frequently used, such as CodePen.

This is by far my favorite kind of question when assessing a Front End candidate and has proven to be an accurate measure of a candidate’s proficiency in the domain and problem-solving skills.

Debugging Question — Candidates are given a piece of code or a small project where there is a known bug. They will have to debug on the spot and fix the bug. I have only seen one company administer this kind of question, which is Stripe.

I know you're a big fan of open source, what are your favorite open source projects and why are you so excited about them?

Yes, I love open source! I don’t exactly have favorite open source projects, but I personally benefited the most out of reading jQuery’s source code. I like open source because it’s a good avenue for showing and sharing. Developers can showcase their projects publicly, other developers can use the projects in their work and also learn from reading the project’s source code.

Which open source projects have you contributed to and which ones have you started yourself?

Over the past few years, I mainly contributed to NUSMods and Docusaurus. I started two notable open source projects myself, but they’re not exactly code, they’re mostly content related to interviewing — Tech Interview Handbook and Front End Interview Handbook.

How do you find the time to contribute to open source?

Open source is my interest and I work on those projects in my spare time. In my previous job, I used open source technologies a lot and sometimes I encountered bugs in them, which I fixed and submitted a patch for. At my current job, many of the technologies I use were built by the company but they are open source. So I get to work on open source while at work.

You are the creator of the Tech Interview Handbook in Github, a project with more than 22,000 stars. Why did you start the project and how did you get so many people to find out about it?

I started the project as a way to share my experiences and knowledge gained from studying for interviews and also to serve as a revision for myself in future if I ever need to be back in the interviewing game again.

The main driving factor of its initial popularity was publishing it on freeCodeCamp’s Medium publication. At present, they have close to 500k followers and it’s a great channel for getting content out to a huge user base. Because of the initial user growth, it was trending on GitHub and Hacker News and even more people came to know about it.

You are also one of the main contributors to Docusaurus. How did you get started?

I participated in my company’s Open Source Mentorship program and chose it as a project for my mentee to work on. In order to guide her better, I looked into the source code and took on some small features and bug fixes. Eventually, I contributed more and got invited to become a core contributor. We’re working on the next version of Docusuarus and it’s gonna be so much better.

How can new developers get started with open source? Should they try to stick to one project they love or try to contribute to multiple ones?

The Open Source Guide by GitHub is a great resource to start out. I think it’s important for developers new to open source to pick a project that is beginner-friendly. Many of them aim to contribute to popular mature projects like React but I think that can be unrealistic. Because these projects are mature, they do not have that much beginner-level work left to do and are likely to have their own roadmap.

My advice would be to try early-stage projects where there are significant features that can be worked on. I don’t think there’s a magical formula as to whether it’s better to stick with one project or multiple at once.

New developers should evaluate the goal of why they are contributing to open source. Is it to learn new skills or perhaps to want to be a maintainer of a project? If the goal is to learn new skills, both focusing on one or working on multiple projects can facilitate that.

Many people ask whether they should learn React, or Python, or Node.js, or Ruby. Is there one language that you think everyone should learn now?

Consider what domain they would be interested in and decide based on the domain — Web (JavaScript), iOS (Swift/Objective-C), Android (Java/Kotlin), Server Side (C++, Java, Ruby, Python), Data Processing (Python), etc.

If they just want to learn the basics of programming, I think Python is a safe choice for beginners. Many universities are beginning to use Python as the language for their introductory programming class. The most important thing is to learn programming and software engineering fundamentals, which are mostly language agnostic. Mastering them helps a developer to pick up new languages quickly and switch between them with ease.

There’s no one single language that everyone should learn now, but I think everyone should at least have experience with a lower-level language (C?) and a higher-level language (JavaScript, Python, Ruby, etc).

Thanks for the amazing insight into your professional journey, Yangshun. Is there anything you'd like to say to someone who is starting their career in software development outside the US?

The world is very connected now and geographical boundaries are no longer as restrictive as before, especially in the field of technology. There are many great programming-related learning resources online which are available for free and everyone keen to improve should leverage on that.

If you're ready to become a world-class software developer, while learning with a supportive online community check out Microverse.

We have launched an English school for software developers. Practice speaking and lose your fear.

Subscribe to our Newsletter

Get Our Insights in Your Inbox

Career advice, the latest coding trends and languages, and insights on how to land a remote job in tech, straight to your inbox.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
We use own and third party cookies to; provide essential functionality, analyze website usages, personalize content, improve website security, support third-party integrations and/or for marketing and advertising purposes.

By using our website, you consent to the use of these cookies as described above. You can get more information, or learn how to change the settings, in our Cookies Policy. However, please note that disabling certain cookies may impact the functionality and user experience of our website.

You can accept all cookies by clicking the "Accept" button or configure them or refuse their use by clicking HERE.