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…
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
Ariel is the founder & CEO of Microverse, an online school for software engineers. Read more about Microverse and how it can help you.
Career advice, the latest coding trends and languages, and insights on how to land a remote job in tech, straight to your inbox.
