Apart from how to get a job at Google (which I have previously blogged about), the most common question I get from people considering taking a job here is what the career path is like -- that is, how you get started, how you grow your career, how promotions work, and so forth. I thought I'd try to capture some of my perspective in a series of blog posts on the topic.
(But first, the obligatory disclaimer: This is my personal blog. Google doesn't condone or support anything I'm saying here. Heck, it's probably all wrong anyway. Take it with a grain of salt.)
This stuff is mostly targeted at new grad hires (at any level -- Bachelors, Masters, or PhD) for software engineering positions. (I don't know how things work in other parts of the company, like sales.) This may apply to a lesser extent to more senior engineers or researchers as well.
Before you join: The team match
Before your start date, you will be assigned to one of the many hundreds of teams at Google. While there are exceptions, teams typically consist of O(10) people who all report to the same manager and have a common project focus. Examples might include the Android Hangouts app, feeding real-time data such as sports scores into Search, or (my team) making mobile Web browsing faster and more efficient.
A lot of people want to work on teams doing things they have already heard of -- such as Search, Chrome, or Android. But keep in mind that the vast majority of teams at Google work on things that are (a) not user-facing and therefore (b) not something you would necessarily know anything about before coming here. My first team at Google focused our content delivery network for YouTube, which I never even knew existed until I started the job. Many project teams are building internal infrastructure and tools, and often the work they do is highly confidential, so we can't (unfortunately) always tell new hires very much about the details of what the team works on until they join.
Google tries to assign you to a team that matches your interests. If you are a Bachelors or Masters new grad hire, the team match is typically done in a "late binding" fashion, a few weeks before the start date (so, after you have accepted the job offer). Given how rapidly projects and hiring priorities shift among teams, it makes sense to do the binding as late as possible. For PhD and more senior candidates, because your skills are more specialized, the recruiters try to make sure that the candidate has a team interested in hiring you even before bringing you in for an interview. As a result, you essentially have a spot "reserved" on that team well before you would begin the job. In those cases you might be able to learn a bit more about what your target team is working on during the process of interviewing and negotiating the offer.
The thing I always emphasize is that when you are hired by Google, you are getting a job at Google, not a specific team at Google. In other words, the initial team match is by no means final, and nor is it locking you down. Engineers move between teams all the time -- it is not uncommon for people to look for a new team every couple of years. Some people prefer the stability of staying in the same area year after year, while others prefer to explore different parts of the company. New projects and teams are always spinning up, and (indeed) teams often reorganize or disband. So there is a fair bit of churn, and I would not stress the initial team assignment much -- it's a starting point.
The starter project
My advice to people starting at Google is to roll up your sleeves, dive in, and start contributing however you can. It's a super steep learning curve, and for the first month or two you won't have the foggiest idea what anybody is talking about, but the more you get involved the faster you'll come up to speed.
The first week on the job is typically spent in orientation, which is usually done at the headquarters in Mountain View. I blogged about my first week at Google a while back -- it is pretty intense, and there is a huge amount to learn. I found it to be super fun (though exhausting) and have great memories of that week. You get your badge, your laptop, your first five or six items of Google schwag, try to figure out where to get lunch, how the videoconference system works, and how to get started on programming in our insanely complex environment. There are a bunch of hour-long courses on topics ranging from how Google Search works to how to use our source code control system.
After the first week you'll start working with your new team. Your starter project is intended to show you the ropes and get you up to speed on our coding environment, build tools, code review process, and so forth, so you can start to be a fully productive member of the team. Starter projects might be something like adding a small feature to your team's code or fixing a straightforward bug. A starter project might take anywhere from a week to a month.
Taking ownership
As you come up to speed, you'll proceed to taking on projects with larger complexity and scope, as you become more familiar with the codebase and conversant in the problems that are being worked on by your team. It's really up to you to drive this process and own your work.
To give a concrete example, one of the (relatively) recent PhD hires on my team, Michael Buettner, started out by investigating the size and quality tradeoff for the image transcoding parameters we were using in the Chrome Mobile data compression proxy. Over time he expanded his expertise of our software and started taking on harder, bigger problems -- including sophisticated optimizations to the proxy's HTTP fetching backend. He is now our team's "latency expert" and has devoted a great deal of his time to making the whole system faster. Since he knows so much of our codebase, he advises on a broad range of new features and bugfixes, and works with other teams to implement functionality to streamline our system's performance.
I want to emphasize that this is not something Michael was specifically tasked with doing. Like most teams, ours has way more problems than people, so engineers tend to gravitate towards the problems that match their interests. My job as the team lead is to coordinate and prioritize our team's work, and fortunately we rarely have cases where we have something really important to do that's not up someone's alley.
In the next couple of blog posts I'll talk about the evaluation and promotion process at Google, as well as how new projects are started.
(But first, the obligatory disclaimer: This is my personal blog. Google doesn't condone or support anything I'm saying here. Heck, it's probably all wrong anyway. Take it with a grain of salt.)
This stuff is mostly targeted at new grad hires (at any level -- Bachelors, Masters, or PhD) for software engineering positions. (I don't know how things work in other parts of the company, like sales.) This may apply to a lesser extent to more senior engineers or researchers as well.
Before you join: The team match
Before your start date, you will be assigned to one of the many hundreds of teams at Google. While there are exceptions, teams typically consist of O(10) people who all report to the same manager and have a common project focus. Examples might include the Android Hangouts app, feeding real-time data such as sports scores into Search, or (my team) making mobile Web browsing faster and more efficient.
A lot of people want to work on teams doing things they have already heard of -- such as Search, Chrome, or Android. But keep in mind that the vast majority of teams at Google work on things that are (a) not user-facing and therefore (b) not something you would necessarily know anything about before coming here. My first team at Google focused our content delivery network for YouTube, which I never even knew existed until I started the job. Many project teams are building internal infrastructure and tools, and often the work they do is highly confidential, so we can't (unfortunately) always tell new hires very much about the details of what the team works on until they join.
Google tries to assign you to a team that matches your interests. If you are a Bachelors or Masters new grad hire, the team match is typically done in a "late binding" fashion, a few weeks before the start date (so, after you have accepted the job offer). Given how rapidly projects and hiring priorities shift among teams, it makes sense to do the binding as late as possible. For PhD and more senior candidates, because your skills are more specialized, the recruiters try to make sure that the candidate has a team interested in hiring you even before bringing you in for an interview. As a result, you essentially have a spot "reserved" on that team well before you would begin the job. In those cases you might be able to learn a bit more about what your target team is working on during the process of interviewing and negotiating the offer.
The thing I always emphasize is that when you are hired by Google, you are getting a job at Google, not a specific team at Google. In other words, the initial team match is by no means final, and nor is it locking you down. Engineers move between teams all the time -- it is not uncommon for people to look for a new team every couple of years. Some people prefer the stability of staying in the same area year after year, while others prefer to explore different parts of the company. New projects and teams are always spinning up, and (indeed) teams often reorganize or disband. So there is a fair bit of churn, and I would not stress the initial team assignment much -- it's a starting point.
The starter project
My advice to people starting at Google is to roll up your sleeves, dive in, and start contributing however you can. It's a super steep learning curve, and for the first month or two you won't have the foggiest idea what anybody is talking about, but the more you get involved the faster you'll come up to speed.
The first week on the job is typically spent in orientation, which is usually done at the headquarters in Mountain View. I blogged about my first week at Google a while back -- it is pretty intense, and there is a huge amount to learn. I found it to be super fun (though exhausting) and have great memories of that week. You get your badge, your laptop, your first five or six items of Google schwag, try to figure out where to get lunch, how the videoconference system works, and how to get started on programming in our insanely complex environment. There are a bunch of hour-long courses on topics ranging from how Google Search works to how to use our source code control system.
After the first week you'll start working with your new team. Your starter project is intended to show you the ropes and get you up to speed on our coding environment, build tools, code review process, and so forth, so you can start to be a fully productive member of the team. Starter projects might be something like adding a small feature to your team's code or fixing a straightforward bug. A starter project might take anywhere from a week to a month.
Taking ownership
As you come up to speed, you'll proceed to taking on projects with larger complexity and scope, as you become more familiar with the codebase and conversant in the problems that are being worked on by your team. It's really up to you to drive this process and own your work.
To give a concrete example, one of the (relatively) recent PhD hires on my team, Michael Buettner, started out by investigating the size and quality tradeoff for the image transcoding parameters we were using in the Chrome Mobile data compression proxy. Over time he expanded his expertise of our software and started taking on harder, bigger problems -- including sophisticated optimizations to the proxy's HTTP fetching backend. He is now our team's "latency expert" and has devoted a great deal of his time to making the whole system faster. Since he knows so much of our codebase, he advises on a broad range of new features and bugfixes, and works with other teams to implement functionality to streamline our system's performance.
I want to emphasize that this is not something Michael was specifically tasked with doing. Like most teams, ours has way more problems than people, so engineers tend to gravitate towards the problems that match their interests. My job as the team lead is to coordinate and prioritize our team's work, and fortunately we rarely have cases where we have something really important to do that's not up someone's alley.
In the next couple of blog posts I'll talk about the evaluation and promotion process at Google, as well as how new projects are started.
A great read. Thank you.
ReplyDeleteThis is super helpful! Thank you Matt, and look forward to your future posts!
ReplyDeletewill people have different managers when shift from projects to projects?
ReplyDeleteThat depends. Some managers have several projects, so moving between projects does not mean moving between managers. But, in general, yes, a project change often entails a manager change as well.
DeleteSo the manager here mean more about Project manager or real HR manager, if later, it seems hard for corporate ladder point of view, how the employee is evaluated by their different managers?
DeleteAt Google, a manager can play several different roles. Typically the manager is responsible both for overall technical direction of a project, as well as the "people management" aspects (evaluating performance, hiring, etc.). When someone switches projects, they typically switch managers, but when it comes time for performance evaluation (the topic of my next blog post) both managers would be involved.
Delete