Hacker News Reader

Comment by pcurve | Hacker News Reader

I don't get it. Company that is flush with that much cash couldn't find new roles for the 'small number' of people that were impacted? I'm thinking they used the good old "your position is being eliminated due to business reasons" excuse to get rid of people they didn't want to keep.

It's a common HR tactic.

View on HN

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.

So...it's kind of like being Big Head working at Hooli? Hanging out on the roof, or building potato guns and piezoelectric sensors?

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.

Do they have you whiteboard asinine college CS algo problems in the internal version?

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.

what is CL?

Change List: internal Google lingo for what is more commonly known as patch, diff, or pull request in the Open source wold.

Roles that don't involve recursion? What next, no for loops please - we are developers!!

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.

Yes of course, traversing directories or dependencies is hard. We are developers, not mercenaries!

We hired an engineer once. He wrote a tail recursive function. We had to fire him. We hadn't tested him on that on the whiteboard.

@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 was just taking GP's statement and shows that it is not consistent with the rest of his argument.

I don't agree that all jobs have to deal with trees either.

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.

Trees as data structures are inevitable. Did you have to balance them or perform other nontrivial graph theoretic transformations though?

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.

This practice isn’t uncommon. In some cases, I’ve seen FAANGMs give people up to 6 months of ‘window viewing’ time to find new jobs

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.

Finding a new role inside the company actually requires some work though.

Finding a job can itself be a full time job though

You do realize that show is based on reality, right?

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.

Keep in mind this is going to screw your performance rating / bonus / promotion situation. You’re incentivized to love fast.

Yes, love fast and make things. An engineer's ethos.

Google engineers - single-handedly increasing the bay area's birth rates

Edit: Wow, just realized that could be a veiled reference to artificial insemination

This is why I live and work in Sunnyvale, and rejected offers to move elsewhere.

I've worked away from the head office at other companies, and it's limiting.

I left Sunnyvale (and the bay area) never looking back. I worked on Castro in MV and it was a 30 min drive 9 years ago.

For me the quality of life is so much better outside of SV.

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.

Smart is the wrong word - more like savvy googlers usually have an internal network and know what teams are hot. They move on quickly.

Bottom tier can't linger long if they have 90 days to find a new job or get fired.

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.

I've heard this where the Big Head meme from Silicon Valley comes from.

> Company that is flush with that much cash couldn't find new roles for the 'small number' of people that were impacted?

The third sentence in the article: "Google didn’t specify how many roles are being cut and said it was working with affected employees to find them new positions in the company."

I hate to be that guy, but I want to point out that more people not always equate to more output. E.g. if you create a "controller" role, they would try to justify their existence and create more work/overhead for others.

And you would be surprised how many roles in big bureaucracies are "controller" roles by nature.

It's good to point it out.

In the third world, if you hire 100 people for a 5-man project, people end up doing nothing but their own things. It's bad but it's obvious that something is going wrong.

In the first world, if you hire 100 people for a 5-man project, people end up to invent and justify 100-man's job. Everyone's role would become their identity, everyone is busy and hardworking. The output is high, they would also have fancy analytics and reports.

It's hard for a person to believe a 100-man busy project actually only needs 5 men.

> In the first world, if you hire 100 people for a 5-man project, people end up to invent and justify 100-man's job. Everyone's role would become their identity, everyone is busy and hardworking. The output is high, they would also have fancy analytics and reports.

This is such utter nonsense that it's hard to believe you've worked in any human organization.

People in the first and third world are not different species. A lot of white-collar first-world workers provide no value to their company at all.

Interesting.

There are two contradicting unsubstantiated observations, or let's just say blatant generalisations, one gets downvoted another flourishes.

smt88's post was downvoted because it completely misunderstood the point of namelosw's post. smt88 wrote "A lot of white-collar first-world workers provide no value to their company at all." Well, in my reading of it, that was exactly namelosw's point. That is, the social pressure in first world countries, and the fact that so many have their identity tied up in their job, demands everyone looks 'busy' even when they are not really doing anything of value.

I made no generalizations. I did exactly the opposite: I pointed out that there are many exceptions to the 1st/3rd world generalizations, rendering them false.

This is so true man! I've seen this first hand both ways.

I like the analogy:

You don’t get nine women in a room to make a baby in one month.

This is often attributed to Fred Brooks in his seminal book "The Mythical Man Month"

* https://en.wikipedia.org/wiki/Brooks%27s_law * https://en.wikiquote.org/wiki/Fred_Brooks

It also appears to originate from Theodore von Kármán (1957): "Everyone knows it takes a woman nine months to have a baby. But you Americans think if you get nine women pregnant, you can have a baby in a month."

I first heard it from Fred Brooks in Mythical Man Month. But it's even funnier if it came from Theodore von Karman. A lot of HNers will know him from KSP as the namesake of the Karman line, the boundary between atmosphere and space, typically set at 100km above mean sea level.

If you assemble a 9+ stage pipeline, you may reach a point where you produce approximately one baby each month.

Even then they are "working" independently. It's not a pipeline that passes the baby from one to the next. That's just plain parallelism. Either way it would do nothing to latency and so would not get the current one done any sooner.

That's not a 9 stage pipeline, it's 9 separate single stage pipelines.

Massively parallel Baby Processing Units (BPUs)

If you implement QBPUs (Quantum Baby Processing Units), you could theoretically produce infinite babies. Of course, we're perpetually 10 years away from working QBPUs.

That's throughput, not latency.

Most companies have more things they want to do then they can do in the next 6 months. So if you increase throughput without latency, you can still get more of those projects done. Even if you're still doing them all inefficiently.

It's ugly, but "don't hire more people because we'll be less efficient" often runs into this ugly "but we need more total output, not more efficiency" wall.

Yes, that's exactly the point of pipelining.

Sweet. The baby-in-a-month problem is reduced to assembling and priming a nine-stage pipeline in a month!

Why would they publicize it this way though. It seems like it would be easy enough to reallocate these folks in a staged manner without creating a news story out of it.

Legal requirement

Why do they need an excuse?

It's a for profit company with a fiduciary responsibility to share holders. There is zero reason to find jobs for people regardless of the cash position.

Here's a couple:

1. Google's tech staffers are supposed to be some of the top people in the world, and Google spends a considerable amount of resources hiring them. It seems foolish not to keep them on the bench a bit, unless Google foresees that it will be shrinking soon.

2. The people not laid off will very much notice their colleagues being zapped the moment they're not needed. They will rationally tilt towards leaving as well, if they get any whiff that they might be next. It's far better to leave first than to be laid off, if you're sharp.

> Google's tech staffers are supposed to be some of the top people in the world

That ended about 7 years ago when Google decided to expand as rapidly as possible. Alphabet employees over 100k people now. It’s just a younger IBM at this point. There will be thousands of people that will suck and should be laid off rather than kept.

I think you still need to be at the very top of your field to get past that famous interview. It’s completely out of reach for all but the most elite engineers even if they’re already doing brilliantly somewhere else.

Google would like their engineers to believe that, I'm sure, but I doubt it. A large company is just incompatible with the idea of being elite. "Regression to the mean" says that as Google adds engineers they will more closely resemble the general population of engineers.

That’s completely false. The skills to get through the “famous interview” aren’t related to software engineering practices at all. Let that sink in.

Their interview process is loaded with false negative and false positive rates, despite what they claim. If you don’t think they have false positives, just look at the poor quality of so many google products.

An interview process that an algorithms/data structure obsessed senior in college can easily pass is clearly not related to elite engineers. It’s sad that people have been tricked into thinking otherwise.

> If you don’t think they have false positives, just look at the poor quality of so many google products.

I don't disagree with the point you're making, but that's a bad argument. Good engineers are capable of building a bad product if the conditions are right.

The thing is, if they bench too many workers, they will also be ridiculed: https://www.networkworld.com/article/2920903/google-really-k...

In fact, this action is probably part of a conscious effort to move away from "benching".

The article is about VPs getting a forced sabbatical after a reorg. No one changes their business tactics due to jokes on a TV show. It's totally normal and nothing anyone is moving a way from.

It has nothing to do with rank and file people getting laid off.

You haven’t heard about Netflix’s policy....

https://www.slideshare.net/reed2001/culture-1798664

“We’re a team, not a family.”

They “hire, develop, and cut smartly”. It doesn’t seem to have hurt their recruitment.

I'm all for this mentality.

It's extremely rare, but there's nothing that makes my job satisfaction drop more than having someone incompetent (in no way related to experience) on the team, or being lead by someone incompetent.

I come to work to get cool stuff done, and sometimes people just don't fit with that goal.

These thoughts are in no way related to the topic.

It’s not only about incompetence, it’s about letting someone go who did their job very well, but are no longer needed and keeping them around anyway.

The story is legendary about all of the infrastructure guys that were let go at Netflix whose job was to migrate them to AWS.

Is that a bad thing? Can you imagine the opportunities you could have if you said that you were instrumental in the largest cloud migration in history?

I can’t remember her name but there was a top ranking official at Netflix hired by Hastings personally. She was instrumental in helping Netflix in the DVD era. But she knew she was going to be laid off when they started focusing on streaming because that wasn’t her area of expertise. She went in and got “quit fired”. She said there were no hard feelings.

I first heard about this with an interview she did on the Internet History Podcast.

My brother-in-law works with various Netflix managers. One of them got a negative mark on her performance review for not firing enough of her team members over the previous 12 months. Netflix pays about 20% over market value, but it's like Lord of the Flies over there.

20% over the top of the market value.

"People who have been stars for us, and hit a bad patch, get a near term pass because we think they are likely to become stars for us again".

Source: your link.

The difference is the timescale. Netflix won’t let you cruise doing nothing for 3 months while you troll an internal job board begging people to take you.

That came from Jim Barksdale: "This isn't a family and I'm not your Daddy".

> It's far better to leave first than to be laid off, if you're sharp.

I think it's better to have a good exit strategy, such as another job offer, then get laid off. If you get laid off at a big company, there is usually a severance package.

No one got laid off. Mobility within the company is very good, they just need to find a new role.

That's not always trivial, and I'm sure some will leave the company, but none have to if they don't want to.

How much does it cost to find and hire a Google-tier worker? Many hundreds of thousands of dollars. If you're talking about financial duty surely their duty is to retain the elite workers they've already got.

Not every employee that is hired is really top tier, there are probably some average people that get through. Also people can get lax and complicit.

Also googlers are sometimes useless outside the Plex. Because of their tendency to religiously reproduce processes that they know so well. And tendency of these processes not to work outside.

It's not like any one uses hadoop or kubernetes and has any success am I right?

Given the market’s performance over the last 4 years, it’s most certainly cheaper to fire people who aren’t actively involved in any projects so Google gets the unvested stock back and then hire fresh at current stock price.

Someone who was hired 2 years ago with 500k of stock vesting over 4 years could have enough unvested stock leftover to fund two employees RSU grants...

Hiring google employees is still cheaper than keeping the senior ones.

I don't work for Google, but I think you're making bold assumptions about how much a year or two of domain knowledge is worth to Google compared to a couple hundred k of stock.

If these employees are transitioning to wildly different roles within the company maybe the math changes a bit, but I'm not sure how much.

Edit: not to mention the trust erosion aspect. If I see people getting laid off cause their stock has appreciated, am I going to stay? Basically means stock appreciation is capped. People wouldn't take kindly to that.

> don't work for Google, but I think you're making bold assumptions about how much a year or two of domain knowledge is worth to Google compared to a couple hundred k of stock.

I did. Google is so large the vast majority of engineers contain domain knowledge that is mainly just useful to their group. And if their group is undergoing layoffs, their domain knowledge isn’t too useful.

About the only useful things that a long-time googler will know when joining a new group over a noogler is the test infra and code review process.

Agree completely. I was simply responding to what I read as a "they have the money, give them jobs" sentiment.

Reply on news.ycombinator.com