In "defrags" like this, Google does not lay off people outright, it just tells them their job is going away and they have X months to find a new one within Google -- and they usually do.
I've personally been through this twice at Google. The company definitely provides a very attentive set of resources to help you find a new position within the company, but I've always been able to find a new project on my own.
That said, the more flexibility you have the easier it is to find a new position. This naturally favors some people over others.
In my most recent case, it ended up being a bit more challenging due to having to balance the constraints of family life versus the opportunities availed by an extremely arduous commute, but I ended up finding a project I enjoy that works with my commute constraints.
So... Like... What do you do in the interim? Not work, look for teams, and still get paid a shit ton of money? Do you do some training on the side? Work on a side project? How long does it take to find the new team?
From the couple people I know who have done this, I think it's pretty choose-your-own-adventure... Get paid to look for your new job, with very few actual responsibilities.
It's worthwhile to compare this relative downtime to ramp-up time for new hires... who also generally spend a couple-few months being fairly useless (though working hard at it).
And googlers being googlers, there's a decent chance that the 'down' time turns into interesting learning or side project time.
Lots of networking over coffee. You don't just blindly apply on the internal job board. You talk to people you know in other parts of the company, you schedule meetings with managers with open roles. You reflect on what you actually want to do next. You reach out to mentors on if they know anyone who has interesting open roles or just on advice for next steps.
Also interviewing with other companies. The next best job for you may not be with Google even if you could easily get an internal transfer role. And teams don't just blindly accept you because you already work at Google (although it helps). You still have to go through a somewhat more informal interview loop that you will definitely want to prepare for.
Of course this is up to the individual, you can definitely just screw around for awhile and apply for an interal role with much less care.
Entirely dependent on the team and hiring manager. And the technical requirements of the role you want to move into versus your prior role. If you want to move from working on gmail to working on the android kernel, I imagine there's gonna be some whiteboarding. (Not that gmail is simple software, but just picked two examples that came to mind with different domain expertise).
Sounds reasonable. I was referring more to the gatekeeping type, like a heavy focus on things like balancing trees and recursion for roles that clearly involve neither trees nor recursion.
It's really not that at level. Once at Google you really get the benefit of doubt of clearing a high bar. It's mostly a talk around your work / perf / CLs and then team fit.
If it's anything like amazon they will just be able to look at all of your code for the last N years which is a very strong signal to go along with interview questions. For internal transfers I general focus more on design questions and check the code history for "can they code IRL". Design is harder to check for and also is more dependent on "can we work together to solve problems" which isn't always apparent from just artifacts.
Shrug recursion, where it makes sense, is wonderful and fun. I’m always happy when I find a problem where it makes sense, because those tend to be interesting problems. But in a lot of roles, working in languages like Python and Java, it just isn’t the best option very often.
@ericd, what programming roles don't deal with trees or recursion?
I've dealt with trees in every single domain I've been in, frontend or backend, whether doing "real" programming or building with no-code tools like FileMaker. I've seen admins and accountants build trees and recursion with spreadsheets. I don't think these things are as "gatekeeping" as you imagine.
They're both occasionally the best tool for the job, but I think they're hugely overrepresented in that type of interview. I haven't found that they come up very often in most web development, as an example, but they definitely come up in interviews for web developers.
Since all programming jobs deal with trees and recursion, and if you are already at Google working on another team, wouldn't it mean you already know about those (since our assumption being all jobs deal with those)? Why not just check directly if you were actually useful instead?
It's 100% not true that all programming jobs deal with trees. I worked for years on a major audio/video/screensharing communications SaaS product and never once needed to write recursive code or use a tree structure. Not all code is for processing data. There was tons of code that had very little to do with data structures or algorithms, and much more to do with implementing network protocols, business logic, managing state, abstracting the differences between the various operating systems we had to support, etc...
I don't think people understand that when you work at scale, efficient data structures and algorithms actually matter. I doubt there are many positions in Google that don't fundamentally require the ability to understand both.
Totally depends. My team has specific domain expertise requirements so I interview transfer candidates in addition to speaking to their manager, reading their prior performance reviews, and speaking to them more casually.
There are other teams where there is little need for more formal process.
After a recent merger at my employer, had some people in of the teams at my office with very little responsibilities for most of a year. The first six months they had minimal work because the company hadn't told them yet they were dropping them for a competing team on the other side of the merger, then they did inform them and gave them 3 months to find a new role in the company and apart from the odd production incident on their system, there was basically no work incoming to their former team.
I think 3-4 moved within the company, 3 left on their own time before the deadline, and 4 waited out for the redundancy payment.
Not really. It was pretty stressful for me last time since I needed to find a project whose commute allowed to get home in time to take care of my kids, since my spouse's job has no flexibility in that regard.
When I saw this at Google, the employee had 60-90 paid days to find something new within the company. Some people waited til the last few weeks to find something because they essentially got two months paid vacation.
I took a vacation to Tokyo on a whim when I heard about my defrag. Checked out Google Tokyo (just have to find a Googler near the tower in Rappongi willing to take you up where your badge can matter) and enjoyed another month or so of relaxation back here before starting a new job at a different company. In my case, they were paying a multiplier of my salary due to the circumstances of my "defrag". In all I was paid an entire years salary in one quarter while I enjoyed a sabbatical.
This is a very smart tactic that also, as a side effect, brings the average quality across all engineers at the company up. Smart people with desirable skills would have no problem finding another team within Google to transfer to, while bottom tier performers won’t, thus leaving Google.
On the other side, the company can create a nice "market" by tuning it correctly. When I was at Intel, it was relatively easy to get an internal hiring req, and relatively difficult to get an external one. And... the total number of internal hiring reqs was allowed to over-subscribe the total authorized head count. Coupled with a rule that no manager could block an internal transfer for more than a couple of weeks of clean-up, the net effect was that there was a certain amount of "hole flow", and you could always identify a bad manager by the vacuum that surrounded them. Overall, I thought that was brilliant.
As to people on re-deployment, it did happen that poor performers had a hard time landing a new role -- but then again, they would have had a hard time staying in the company in their old role, so that kind of fits your point. But Intel didn't use redeployment as a "shadow RIF". Intel was not shy about moving people out of the company -- they didn't need to nor bother to hide it.
Back to redeployment -- I can remember occasions of fairly large redeployments (business unit shutting down) where those of us in parts of the company considered more strategic would find ourselves suddenly rich in hiring reqs. Again, the company created the right market conditions and let the hiring managers and employees sort it out.
Unless their skillset just isn't needed at that location anymore and they can't move to a different city for example because they have children in school.
I guess it helps keeping the workforce young and flexible.
A vast majority of full time Googlers are bucketed onto ladders that are needed in pretty much any team. Say SWE, SRE-SWE (that can switch to SWE at will), TPGM, all kinds of managers. Much of the remainder are people who should be able to do the switch, say SRE-SWE to SWE, within the grace period. Legal and accounting might find themselves in a pickle, but these don't move often.
It'd be interesting to study. My intuition is that over the long term it'd cut in the opposite direction--smart people will move on while bottom tier will linger as long as possible.
In my experience the best leave at the first redeployment. Each subsequent buyout the smarter ones leave, it's rarely the crap people that take a buyout or leave altogether.
