Hi! I’m Gary, a software engineer based out of New York City, and this is my portfolio and extended resume, since its hard to cram everything into LinkedIn.
Work experience
Meta (April 2022 - current)
At Meta, I worked under a team called Instagram product performance. We were responsible for improving the performance and reliability of the Instagram mobile app (iOS and Android) by scaling efforts through defensive tooling.
This meant preventing bugs, crashes, lagginess, amongst other undesirable qualities for billions of end users.
Here, I mainly delivered the following projects:
Scroll performance regression investigation
Scroll performance was a longstanding but often neglected performance metric. Imagine opening up the Instagram app and scrolling down - if your device was an older one (as many users might not have a recent gen iPhone or Android), it might jitter and suffer from something called “frame drops”.
I developed a new suite of investigating tooling called Incident View with the help of the DevInfra team. What this tooling did was run custom scripts whenever a regression was detected, and aggregate all possible sources of data to attempt to root-cause the regression.
This included:
- whether some experiment or feature-flag had been recently flipped on/off
- changepoint detection in the performance metric itself (was it gradual, or a spike?)
- production performance data traces
It turned out that the most valuable piece was the data traces, since it was already being collected in production, so the difficulty became digesting this data and serving it as an insight to possible engineers. This involved comparing pre-regression to post-regression traces, and making a reasonable attempt at guessing the culprit, which were in the form of functions and call stacks that were recently modified, and have also regressed significantly in terms of wall-time (time it took to run). I don’t recall using any fancy algorithms here, but simply pruning and sorting the severity of these potential culprit candidates until other engineers did not find it too laborious to sift through.
Using these approaches, we were able to start pinpointing a possible root-cause, without needing the help of performance experts (who had more ambitious projects to tackle!).
All in all, this was a technically exciting project, more framed as a research project.
Bug report clustering
Any user today can submit a bug report by rageshaking their phones, and a menu will come up to write out and submit a bug report. Most of the time, the metadata and diagnostics attached to the bug report simply weren’t enough to diagnose the problem.
With help from the DevInfra team, a text clustering widget was developed that would cluster commonly found words and phrases in recently submitted bug reports, e.g. “stories not loading”. Viewed as a stacked area chart on a timeseries, this allowed us to quickly identify what the approximate issue was, quickly improving time-to-mitigate for oncall product engineers in respective teams.
Observation-based unit test generation
This was probably the most technically challenging and rewarding projects I had at Meta, and the original efforts were published as a paper.
I joined the project after the prototype was in an intermediary rollout phase, and noticed a somewhat high failure rate (10-20%)
Subsequently, I built snapshot testing on top
Super.com / Snaptravel (March 2021 - March 2022)
IFS Copperleaf (May 2017 - March 2021)
Seamaster Analytics
About me
I was born in Hong Kong, and experienced kindergarten education there (some of my fondest childhood memories!) for almost 3 years, before my parents decided to emigrate to Canada without formally consulting me (or maybe I forgot).
At the age of 5, I continued schooling in Richmond, BC, which soon became one of, if not the most Asian city in all of North America. I spoke Cantonese at home growing up, but soon my English outpaced that in fluency, much to the dismay of my parents as more and more English replaced my vocabulary at home.
Fast forward to the last year of high school, I had better grades in math and physics, so I chose engineering as my first option for university, without thinking too much about it. I subsequently enrolled into the University of British Columbia, eventually matriculating in electrical engineering.
After my second year, I felt I could build just about anything electrical, using a combination of breadboards and integrated circuits (IC). But this was not without its pains. Debugging circuits meant either using a voltmeter or my fingers, and one time my index finger touched a short-circuiting IC, which is when the seed of trying out web development was planted in my mind. After all, debugging in web dev land was as simple as clicking refresh in the browser or opening developer tools.
I didn’t end up building anything complex per-say, but two of the most rewarding moments were when I helped my friends on their projects.
Here is an example of one such project. It was a final year industrial design project, where the idea here was that people at a dinner table had to keep talking (and not all look on their phones), or else the connected light would gradually dim. Basically, the brightness of the light was dependent on noise volume.
Initially, I used an off-the-shelf microphone component to help detect sound, but the results were terrible as it barely detected sound volumes. A lightbulb (no pun intended) suddenly went off in my head after I accidentally burned through too many of these components, and I decided to use an old Android phone, and build a basic Android app that would take the microphone volume and send its amplitude through bluetooth to an Arduino. The Arduino would then modulate the brightness of the lamp. It worked!
Talking about this seemed to show enough interest to land me my first internship job at Gatekeeper Systems, which manufactured retail shopping wheels that would automatically lock when it crossed above underground wires at the perimeter of a parking lot. I got to test a lot of wheels, and remember one time where, under the heat of a LA (Irvine) summer, was pushing shopping carts placed with concrete bricks to simulate real-life conditions. Although this was both memorable and felt somewhat silly at the time, I later would see these wheels used in Costco, Target, and Walmart, which was pretty cool!
Around this time, I also discovered game development. As a child, one of my favorite games was Little Fighter 2, a side-scrolling beat ‘em up game. I sought to then recreate this experience, but on mobile, with working multiplayer. This led me down a 1+ year rabbit hole of fun, obsession, and also periodic moments of frustration (see Projects section for more).
This also got me my second internship position at Happylatte, based in Beijing. At the time, their game High Noon and High Noon 2 were doing well and raking in a lot of money. I was also barely able to speak Mandarin Chinese at this point, so this was both a serious lesson in game development as well as in language.
One of my proudest achievements here was when I noticed that the manual QA team had to keep playing the game over and over in order to test out post-match conditions. I subsequently created a weapon that would deal 999 damage and end the game instantly (still allowing the QA testers to at least shoot one round). This literally sped up the testing process god knows how many fold, which is when I found a bit of a side-obsession for optimizing low-hanging fruit that others did not question.
Projects
All-In Fighter
All-In Fighter was the most obsessive and dedicated project I had worked on up until this point in my life. I wanted to recreate a version of Little Fighter 2 (LF2) which was:
- mobile first
- supported multiplayer mode (LF2 only supported peer-to-peer networking)
This was difficult at the time, but I learned and implemented some of these:
- networking (with UDP), lobby system, etc.
- 2.5D physics
- AI (finite state machines, goal oriented action planning)
Unfortunately, by the time I graduated, this game was not quite doable with just me and my partner (who served as the artist) while committing to a full time job. It was very difficult back then to come up with something like 10 characters for launch, and by the end, we had 2 main characters, and a few other random AI characters.
Soundio Labs
This was a somewhat silly entrepreneurial-ish venture done with a friend, who had the idea of selling earphones from AliExpress in the North American market, for free, but the customer pays the shipping. The shipping costs were already more than enough to justify the unit price.
At its peak, this actually brought in some money (see screenshots below), but had 0 returning customers. However, I can honestly say that the quality of these earphones were at least equal if not better than what you could get for double the price at BestBuy.
K-pop music sheets
The first thing I ever made any money off, was buying piano music sheets for people off a Korean website called Akbobada. A lot of the interest and inquiries came via my blog post, which is when I registered the domain with some simple contact information to improve SEO.
A lot of these music sheets were the official instrumentals for a lot of k-pop songs or original soundtracks, so they were of a lot higher quality than found anywhere else on the internet.
I could not read Korean myself, but I guess users did not want to deal with inputting their credit card into a foreign website even with Google Translate.
There was no automation to this per say, but it made me happy to help someone out every time. I think I charged something like $5 and the music sheets themselves would cost like $2.