An impossible first task at Google

I worked at Google in 2021 and 2022, around the time they were asking people to return to the office after the peak of COVID-19. The return date kept getting pushed back and I had to commit to a move, so I ended up in the office well before most of my team, spending most of my days in a mostly empty office. However, that’s not what this post is about; I expect plenty of people had similar experiences with poorly planned “return to office” initiatives, as I did myself at another company later. This post is about something a lot more specific and unique, what I did for my first ~4 months at Google, and how that experience led to the end of my time there. I will acknowledge in advance that my memory of a few technical details might be a bit fuzzy five years later, but the important parts of the story remain.

In case you don’t know me, the short version of what I do for a living is that I write software. Mostly the sort that’s used by other software engineers while they write and test and publish other software, and occasionally the sort that’s used to manage servers “in the cloud” behind websites and apps and other services. No matter what kind of software a company is writing or what kind of service they run, if they are large enough then there’s someone (or some team or department) like me behind the scenes building the tools to enable their development process to work.

The team that I joined at Google was responsible for payments in Android apps. Not buying apps from the Play Store, but spending money within an App for things like upgrades, subscriptions, downloadable content, etc. When that team writes new code, they need to make sure it’s not going to break existing apps or APIs or other parts of the Android ecosystem. One of the many ways they do that is... probably still a trade secret, so I won’t get into details here, but suffice it to say that it’s what I was assigned to work on. I would be improving that system to more effectively test the changes that my colleagues were making, before those changes had a chance to cause problems for anyone else.

Joining a new company as a software engineer usually follows a relatively predictable path, and Google was no exception in most regards. The first few days were mostly HR stuff, filling out forms about things like insurance and payroll. I was issued a laptop and given access to various internal documentation, repositories, training materials, team communication channels, etc. I was also, a bit later, issued a company phone authorized to connect to company servers that my personal phone could not. Once all the initial team-agnostic steps were taken care of, I had a few meetings with my manager and a team technical lead. We discussed the project I would be working on, what my goals would be in the first three to six months, and what the initial steps toward those goals would be. In typical fashion, the very first of those initial steps were things like checking out some source repositories, compiling some code, running some tests, etc, all expected to take a few days while I familiarized myself with the environment and tools available. However, that is where things went off the rails...

You see, I was the very first hire on this team after a new company-wide mandate that new employees would get a Chromebook for local use and a specially provisioned VM to use as a virtual desktop computer, rather than a Mac or Linux or Windows laptop and a desktop computer at the office. As far as I know, the primary motivation here was one of security, in that it reduced the damage of intellectual property leaks when someone’s laptop was stolen. Unfortunately this had a nasty side effect for my particular situation. Just like all the developers downstream of me would interact with the software I wrote while testing their new code, when I wanted to write new code I would need to test it against something maintained by someone upstream of me. Specifically, I couldn’t just deploy untested code changes to the live Android Play Store; I needed to deploy them to an internal test environment “fake” Play Store, and then tell my phone to connect to that fake store so I could interact with my running code.

Reconfiguring an Android phone to connect to a different Play Store requires modifying some internal settings not normally exposed to the user. The way you do this is to connect the phone to a computer with a USB cable, then run a program on the computer called Android Debug Bridge. ADB allows direct access to the phone’s firmware, file system, packages, etc, and has commands for modifying or overwriting all of those things. It’s a tool that any developer of low level Android apps, let alone a Google engineer responsible for Android ecosystem services, is familiar with, although some of its more exotic functionality is less well known.

In 2021, if you had physical access to a desktop or laptop running Linux or MacOS or Windows, you could install ADB directly, either on its own or as part of a larger Google or Android Platform Tools package, then connect a phone with a USB cable. This is what every member of my team had done, and what all of our onboarding documentation expected me to be able to do. If you had network access to that desktop or laptop from a Chromebook running ChromeOS, Google had an internal Chrome app that would allow the Chromebook to act as a bridge between the computer over the network and a phone connected via USB. If you only had network access to a Google virtual desktop VM and physical access to a Chromebook running ChromeOS... you would encounter a problem that, at least as of mid 2021, seemingly no one had ever considered, let alone tried to solve.

I spent months reaching out to every engineer and team and project that I thought might have some insight toward making this work. This included the developers of that internal Chrome ADB bridge app, the ADB developers responsible for its network server/client mode, the engineers who had contributed to the “Chromebooks and VMs for everyone” policy decision, the team configuring and provisioning the virtual desktop VMs, etc. I made minor progress writing patches to ADB and that internal Chrome app to try to make this work. I tried to get permission to use my personal laptop and/or personal phone for various steps of the process. I kept letting my manager know that this weird confluence of policy and technology was causing me to waste ridiculous amounts of time and effort on what should have been a ten minute item from my onboarding checklist that was instead blocking all of my other progress.

In the end, I was eventually issued a Macbook like everyone else on my team, and I eventually returned to the office and got access to a physical desktop computer, again like everyone on my team, either of which could have resolved my blockers the very first day I encountered them. However, by then the whole project I was to have worked on was gone, partially implemented by other teammates, partially abandoned in favor of other solutions. My enthusiasm had waned significantly and the writing was on the wall for the performance review (”perf”) that would cover those entirely unproductive months. I could tell that my manager had given up on me, and my ensuing minor contributions to other projects weren’t what I was looking for in a career or what Google needed from an engineer of my level. I ended up leaving the company a few months later in search of fulfilling work.