My Apple Resume - What I worked on during my time at Apple

Apple Chronicle's. New weekly segment about my life as a Software Engineer @Apple from 2014 to 2020 - I'll share with you bits and pieces of my ~6 years tenure.

This week, we are going to take a trip down memory lane and briefly discuss my work at Apple. Essentially, we will review the section of my resume that highlights my Apple experience.

I held a total of four different roles at Siri, Apple:

  1. Started as Software Engineer in Tooling/Testing | 2014

  2. Became a Senior Software Engineer in Siri Tool Team | 2015

  3. Led the same team as Technical Lead | 2016

  4. Moved to work on Siri product | 2017

For those interested, this is my current resume if you want to take a full look.

LucaLupo_Resume_2024.pdf107.24 KB • PDF File

Software Engineer in Tooling/Testing

When I started at Apple in 2014, my job involved automating QA (quality assurance) processes. Our team heavily relied on manual testing, which I, as an engineer, found inefficient.

I designed and built the de facto iOS tool used in Siri to file bug reports. This tool improved the productivity of the Siri QA team by 6x, increasing the number of daily bug reports from 50 to 300.

This project was very impactful and led to my promotion to Senior Software Engineer. If you're interested in how leveling works at Apple, I wrote about it in leveling-performance-reviews-apple.

Senior Software Engineer in Siri Tool Team

After improving the way people reported bugs in Siri, the next logical step for me was to eliminate the need for manual testing entirely. With the support of my manager, who was always up for a challenge, I built a new automation system that allows non-technical people to create and run E2E (end-to-end) tests for Siri. In just two weeks, 10 people created 15,000 E2E functional tests. 

Technical Lead in Siri Tool Team

I was then given more responsibility and made the lead for the Siri Tool team, which I grew from 2 to 4 engineers.

After spending a few years in the Tool team, I decided I wanted to contribute more directly to the product itself.

Senior Software Engineer in Siri Client Platform

As part of the platform team, we built a distributed platform capable of running Siri (partially) on the device or on the server, avoiding code duplication. We provided domain engineers with the necessary tools (networking, dialog layer, reusable components) to build up domains with minimal effort.

I won’t be able to name all the projects I worked on because some never launched, and some were super secret.

Performance

One year, there was an all-hands-on-deck effort to improve performance.

I improved Siri's response time for the most-used Siri domains (50% of daily requests) by optimizing process launch time (up to 68%), reducing memory footprint (custom caching vs. NSCache), extending process lifetime (reducing COLD cases from 25% to 4%), and boosting process priority.

I made Siri super fast! However, Siri was still a little dumb, which led to my next project.

Siri Architecture

I worked on the new Siri architecture, designed to propagate ambiguity closer to the user's device based on domain-probed features, user preference, and engagement signals. This increased user experience scores by 3.4% (from 4.39/5 to 4.54/5), with a performance impact of only 50ms.

As a result, I also wrote a patent: US20190370413A1, and Apple awarded me $2500 for it. In essence, this project aimed to avoid making premature decisions for ambiguous intents. It ensured that multiple intents were propagated to the user device, where they would be resolved, and the best one would be selected and executed.

For example, imagine you ask Siri to call Fidelity. Since Fidelity Investments exists, Siri might call it. However, what if you have Fidelity as a contact? Which one is more likely to be the user's intention?

On Device Siri

Finally, and this was probably the coolest project of all, I built a completely offline version of Siri capable of running fully on the device (NLP, Speech Recognition, domain execution). This version could handle many popular use cases in the Music domain, such as media player commands (play/resume, stop/pause, next/previous) and more complex actions like playing user playlists. This resulted in 2x performance improvements due to the elimination of server roundtrips.

We never announced it, but people on Reddit found out. Check this out: https://t.co/ODuJgHYH3p.

That’s it for this week!

Forward this email to a friend who needs to read this 🚀 

And if you are that awesome friend - Subscribe here to get weekly emails on Apple & Tech from an ex-Apple engineer.

If you are an app developer and looking to launch your app faster, check out shipappfast.com.

Hit reply and let me know what you found most helpful this week—I’d love to hear from you!

See you next Week!

Luca