3 ms·
The FAANG team sizes and TC packages were never about fueling the production engine. They were about: 1. stockpiling fuel for when you may need it 2. starving
by swatcoder 4y ago
The FAANG team sizes and TC packages were never about fueling the production engine. They were about:
1. stockpiling fuel for when you may need it
2. starving your competitors of fuel
With money cheap and valuations absurd, idle or overpriced talent was a much lesser problem than somebody else hoovering up all the good stuff.
So you recruit aggressively using mechanical filters like leetcode/whiteboard tests, then let internal processes figure out who’s actually worth using on meaningful projects. The rest you can sit on, just in case.
- spywaregorilla 4y agoI hear this a lot but I think it's bullshit. Neither of those are goals that anyone would realistically pursue. It was almost certainly middle managers wanting to demonstrate impact by leading a larger team.
- twelve40 4y agohow could middle managers double the headcount by themselves? nobody above them noticed that?
- christophilus 4y agoProbably exactly this. Each tier of management hired a fair bit more than they should have. Managers are generally incentivized to do so. The behavior was normalized and no one really noticed while money was cheap and all seemed well with the world.
- fmajid 4y agoNo. There was a data science conference in the Western US a decade ago. Mark Zuckerberg showed up unannounced, with a job offer for every single attendee. The strategy comes straight from the top, and it makes perfect sense. Even if they are not fully utilized, even a FAANG salary is small potatoes compared to what top-tier talent can bring to a company. Think of it as the HR version of what VC do, invest in many people knowing 90% will fail to live up to their potential, because the 10% that do more than make up for it.
- arcticbull 4y agoHonestly I can't think of any evidence to support this theory.
- borroka 4y agoFor a new team that was set up in my company, there was this idea that we should have had some slack in the system, that is, a certain number of people should be rotating on a sort of "bench", ready to get into action when new work came up: an absurd view of intellectual work, which I very much doubt is viable in a top company like Facebook. As for (2), that's as true as fairy tales.
- QuercusMax 4y agoI'm not sure it's so absurd. There's always unexpected tasks that show up which can throw off a schedule. Or sick leave, vacation, etc. Things happen. I've worked as a TL on several teams before where we didn't assign any implementation work to me specifically, but I was there to jump in and help paddle the boat when folks got stuck. This worked great, because usually the sticky places were integration points between subsystems, which can be especially tough for junior engineers to navigate. As someone with the big picture I could jump in and save them tons of time. In the meantime, if I had spare cycles I'd work on tooling, test automation (and especially stubbing out and deflaking integration tests). Projects where I did this tended to have fewer bugs and hit their deadlines.
- borroka 4y agoBut the role you are describing is different. What I referring to is a team of 50 people, say, with 10 of them that are "on rotation" sitting on the bench and wait for new assignments. What happens is that 2 of them get used to the "vacation" and are not much motivated to get on a new project when the time comes, 2 disappear, 1 takes advantage of the R&R to work on tools and do some self-study, and 6 start interviewing for other companies. Horses want to run.