Profile

I was on the Facebook Live team at Facebook. My overall goal for the internship was to improve the Live video viewing experience in the Facebook Android app. I worked on various user-facing features to accomplish this goal.

I added a full-screen button to allow the user to watch the video in fullscreen without rotating their phone. This improved full-screen watch time by 0.5%. I also developed a feature to tag and invite friends via comments, similar to commenting on other posts. I added a button to allow users to mute comments. This resulted in a decrease of client data usage by 0.6%. I also redesigned the comment composer to be coherent with the redesign happening in the rest of the app. Finally, I improved video discoverability by showing suggested Live videos, using the Litho framework.

Technologies used: Android, Java, PHP

I worked on WALT Latency Timer (github.com/google/walt), which is a physical device designed to measure touch, screen, audio, and MIDI latency of Android and ChromeOS devices. WALT allows the round-trip latencies to be broken into separate times. WALT connects to the Android device via USB, and is controlled via an Android app. My main project was around making the Android app more usable and making the test results easily interpreted. It also involved making UI improvements requested by our users.

Previously, the latency would be reported as a median of the samples taken during the test. I developed live histograms which update as test results are gathered, plotting the samples in real-time. I also implemented a chart to plot the screen brightness transition curve as it turns black to white to black, and a scatterplot for the drag latency test to give the user confidence in the algorithm used to calculate the latency.

I also created a new type of test to measure accelerometer latency. This is useful for VR applications, where the accelerometer+graphics latency has to be low. Developing this involved cross-correlating the accelerometer signals from the phone and from the WALT device. I also developed a new type of graphics latency measurement to test the fast-path graphics pipeline which is included in newer ChromeOS devices.

I also developed end-to-end tests, which calculate the latency between an external input and an external output. This allows WALT to be used to test any device (e.g. iPhone, Windows), without having to develop a native WALT application for each device.

Overall, Google is an interesting company, as it is working in almost every area that technology can reach. Their size naturally creates the dilemma of multiple teams solving very similar problems, but having little communication or code-sharing (consider the plethora of messaging apps they have developed). Multiple teams are tackling the problem of measuring physical latency on Android and ChromeOS devices, WALT being one of them. I enjoyed working on open-source software, as well as playing around with the hardware, and I felt I was able to have a significant impact on the project.

Technologies used: Android, Java, Python, JavaScript

I was on the Messenger Core team at Facebook. My overall goal for the internship was to reduce data usage caused by a data-syncing library in the Messenger app. One of my projects led to a 1-2% background data usage reduction of the overall Messenger app. I worked on a cross-platform collection-syncing library for Messenger. At a high level, it works by calculating the difference between the stale data the client currently has, and the fresh data on the server, and only pushes down the difference. In cases where the difference cannot be computed, the entire dataset is sent down from the server.

I added functionality to optimize the case when the server cannot compute the difference. Instead of the server sending down the entire dataset, the client sends up an invertible bloom filter made of the client's dataset to the server, and the server will probabilistically reconcile the set and send down only the difference. This resulted in a 1-2% reduction in background data usage of the Messenger app on Android overall.

I also investigated the feasibility of using Zstandard dictionary compression for client-server transmission. I benchmarked Zstandard dictionary compression on datasets, and created a script to train Zstandard dictionaries based on production data. Finally, I investigated the serialization format of Thrift and Flatbuffers. We found that Flatbuffers with the same schema as Thrift were serializing many times larger. I found that the underlying reason was that because Flatbuffers can be read without deserializing the entire bytestream, this requirement created overhead space usage in the form of vtables and pointers. With Thrift, the data is highly compressed but unreadable until completely deserialized. Thrift generated code is also larger as a result, at the benefit of smaller over-the-wire data usage.

Overall, I was thrilled to work at Facebook. They really treat their interns well, and they provide a lot of opportunities to connect with the other interns. At Facebook, you really feel like what your working on is important. Not only is your code deployed to serve over a billion users, but my manager worked closely with me to ensure that I was only working on the most impactful projects. Although I worked at a huge company, I felt I was able to make a meaningful impact on Messenger.

Technologies used: C++, Java, Flatbuffers, PHP

At PagerDuty, I worked on the Realtime Incidents and Alerting team, responsible for maintaining critical Scala services to allow pages to be sent out. Before I arrived at Pagerduty, the team worked on breaking up the Rails monolith into a a pipeline of Scala services. Starting from event ingestion (public facing service which consumes events from monitoring services), to fanning out the event into multiple notifications, to sending out the notifications via SMS/phone call, each Scala service has many instances distributed over 3 AWS datacentres, each with its own Cassandra cluster. 2 of these 3 datacentres are close together on the west coast, while the 3rd being on the east coast. The difference in distance creates an interesting challenge as the uneven latency will skew the read volume in each datacentre.

Overall, I worked on improving the reliability and performance of these realtime Scala services. I tweaked the way end-to-end latency was calculated to be more accurate. I updated the rules under which PagerDuty engineers were alerted due to missed/delayed pages to reduce transient/unactionable alerts. I also increased production data archival speed by 10x by locking on a mutex identified by the timestamp being archived rather than a single global lock.

The team was in maintenance mode during my internship, and we felt that Kanban was the best methodology for this stream of small tasks. This was interesting as there are a few variables that can be tweaked such as: maximum number of tasks in progress, maximum number of tasks in code review, and minimum number of tasks to-do. Our manager carefully measured the throughput and latency of these tasks, optimizing the team like a machine. Overall, the PagerDuty backend is an interesting system to work on, as the priorities of this system are unique: reliability is of utmost priority (as PagerDuty is a system to keep other backends reliable), while latency is not (anything under 5 minutes is acceptable).

Technologies used: Scala, Cassandra, Finagle, Apache Thrift, Zookeeper, Rails, AWS

I was on the Android team at Remind. At the time, the Android team was 4 people, and the major feature we worked on was Chat. Previously, Remind was a medium for teachers to broadcast announcements to students via text messages, push notifications, and email. Now, Chat would allow students to talk to teachers and other students 1 on 1.

I am proud of the Office Hours feature on Android I developed, which allows teachers to mute messages at certain times of the day. This feature was used by over 50% of teachers. During a company hackathon I developed enhanced notification for Android Wear, allowing students and teachers to read and reply to chat messages from their smartwatch. I also developed a Slack integration to scrape Google Play Store reviews and dump them in our #reviews channel. Our team maintained a 99.9% crash-free status which is impressive given the app has over 1 million downloads. At Remind I also implemented Material Design and helped migrate our test suite from Espresso to Robolectric which significantly reduced flakiness in our tests, enabling us to merge PRs only when the CI build passes. I made some minor improvements to the Angular app and Rails backend as well.

I really enjoyed the week-long workcation in Lake Tahoe. The entire company drove up in a bus, slept in 2 neighbouring mansions and really focused on building Chat during the day, and bonding at night. On the last day we went skiing and had a blast. I looked forward to chatting with teachers weekly and providing them with support (an activity all engineers at Remind participate in). It was a great opportunity to directly learn about pain points in the app and to observe the different ways teachers and coaches use Remind. Remind has a culture where everyone is connected and close with each other, and I haven't felt this at the other companies I've worked at.

Technologies used: Android, Robolectric, SQL, Jenkins, Angular, Ruby/Rails

I worked on a variety of Android projects at Pivotal Labs, including Comedy Central, Carnival HUB, MCX Mobile Wallet, and a Paypal wallet app. I was able to work on so many projects because Pivotal reallocates most engineers to different teams on a weekly basis. Pivotal prides itself on two things: Test-Driven Development and Pair Programming. In exchange for the freedom of not having code reviews, 2 engineers must work on the same computer, each alternating between writing code and advising the other person. The biggest thing I learned here was the right way to do Agile development. I also learned about the Robolectric testing framework (developed by Pivotal), and the MVVM design pattern, used in the MCX Mobile Wallet app.

Pair programming was a great experience for my first job, as I was able to learn from a full-time engineer 8 hours a day, every day. However, I feel pair programming is only useful when there is a significant discrepancy in skill between the 2 engineers, such as during on-boarding. Pair programming feels very restrictive, as 2 people must share a single computer, and can remove the sense of autonomy that drives engineers to write quality code. The mantra of test-driven development sounds good on paper, but often slows down development in reality. Pivotal's focus is on a strict development methodology, but this neither attracts top developers, nor allows for creativity and innovation.

Technologies used: Android, Java, Robolectric, SQL