An impossible first task at Google - by Sparr

Inside Voice

SubscribeSign in

An impossible first task at Google

Sparr<br>Jun 27, 2026

Share

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.<br>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.<br>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.<br>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...<br>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.<br>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.<br>In...