I recently had the opportunity to interview at Google for a position in their New York office as a Technical Program Manager (TPM). I found out today that I didn’t make the cut. But in the process of interviewing, I found out a lot more about the company, how it does its work, and ultimately concluded that the role was probably not a good fit for me anyway. Here’s some information about what my experience was like, and also what I found out about the company while I was there.
There’s obviously no need for me to explain who or what Google is, but I should mention that I was recruited for an opening in their Site Reliability Engineering (SRE) group, and what that means. SRE’s job is to act as the second stage in the evolution of new Google products. After products stabilize (at least six months running on their own), they are eligible to be adopted by SRE, who will help them grow by, for example, migrating to some of Google’s in-house infrastructure tools like BigTable or MapReduce. This is particularly important for large web applications that come from companies Google acquire; SRE’s job is to help shepherd these products into the “Google Way”. SRE also has an operational role, keeping the biggest Google products like AppEngine or the core search product running smoothly. As such I was told that SRE is the biggest engineering organization within Google.
As I discovered along the way, Google is a company with little organizational hierarchy. Obviously, many engineers like this: it means a minimum of management “overhead” getting in the way of doing great work. There’s also not a huge variety of roles in the (technical) organization. If you’re not an engineer, you don’t really have a place. On the flip side, the system makes engineers wear lots of hats: product manager, system administrator, project manager and QA tester in addition to being a software developer. This works well if the hiring process is rigorous and continues to bring in people who can, again, do things the “Google Way” and adapt to life in an organization where engineers self-organize into autonomous groups to just G.S.D.
All this leads me to try and explain what a TPM is supposed to do. I presume that the danger in having groups of high-functioning engineers determining their own work is that it can lead to a disconnect with the business goals, product features, and timelines. My best attempt at defining the role would be “cat herder”: using both good and bad cop techniques to push very individualistic engineers into shipping product, having the technical wherewithal to speak to engineers on their level, and even plunging in with both hands when necessary.
Eventually it dawned on me that the lack of structure & defined responsibilities at Google do not make it a good fit for me. For a program manager job, I was interviewed over the course of a full day on large-scale system design (requiring mathematics and a whiteboard!), project management, programming, UNIX systems administration, networking, and even more project management. These weren’t just cursory interviews, but ones in which I had to demonstrate a fair amount of expertise.
Google is a very unique company. They’ve managed to build an engineering-centric shop with many in-house solutions to solve problems for their scale; not many companies either have that scale, or the resources (financial or personnel) to pull that off. And they have a rigorous hiring program that seems to have worked for them, even as they’ve grown to 30K+ employees. However, I think they’ll eventually have a tough time finding generalists with the requisite amount of knowledge to do it all, and well. (One Googler told me that they’ve pretty much either interviewed or hired everyone in the Bay Area that they want to, implying that they’re having trouble growing their team.) Eventually, I believe, even Google will have to recognize that not everyone can do everything well, and they’ll have to specialize. Maybe at that point, I’ll be willing to consider them again.
Did you try again since then?