[morei]

It's rare, but possible.

Known of v high level example that is just incredibly disciplined about how they spend their time (e.g. "I did this, but was slowed significantly by poor code over that. Estimate about 30% time loss. I'm going to spend N weeks more in this area, so it's worth me spending 3.5 days fixing that code, but no more. I think I can fix it in about 2 days, so I will fix it. If I can't see the end of the fix by the time I'm 4 hours in, then I'm probably wrong about the expected time, so will abandon the fix").

The result is ridiculous productivity. They don't work long hours (strictly 9-5), but just very, very focused on making certain that there will be meaningful results from those hours.

So they exist, but absolutely it's not going to be common!

[UncleMeat]

I don't know about other places, but volume of work does not matter for L5->L6 at Google. The kind of work you do is what matters. So doing 50% more doesn't get you there.

The L6 (and L7) ICs I know got there by implementing really tricky components way down the tech stack that are very difficult to update due to insane implicit dependencies and also enormously impactful in terms of savings across the entire company.

[m0zg]

It's not rare at all in my experience. You just have to have a combination of skills that pays more than average on the open market (big data runtimes or distributed systems, say, or AI, in addition to other domain expertise perhaps), and you'll be L6 or L7 IC, no problem. No managerial duties whatsoever. L7 is more nebulous, but L6 is absolutely doable for anyone with a modicum of marketable skill.

You see, in spite of their internal promo treadmill and brainwashing, companies have to compete on comp regardless. Comp ranges, in turn, are tied to levels. If, say, someone who knows a distributed query plan from a hole in the ground costs $1M/yr, they'll get that and the "level" will be adjusted accordingly, as much as necessary, ignoring the elaborate formal descriptions of job responsibilities.

It's the proles in the trenches that take the levels seriously. People who actually run things understand that levels are merely a hamster wheel, put in place to give you something to look forward to, and to keep your comp expectations in check. Lack of "broad organizational impact" is _the_ most often used cudgel to deny promotions to the more senior level, unless your skill stack allows you to bypass this bullshit entirely.

[lelanthran]

That sounds entirely logical, but unfortunately having never worked in a FAANG or FAANG-like company[1] I can't tell whether this is the reality or not.

I would very much like other readers here with experience in FAANG or FAANG-like companies to comment on your comment.

[1] Most Corporates and enterprises are different - they resolutely refuse to match based on market-value of skills. There's also very little a developer (senior or not) can do to have a company-wide impact, because the fiefdoms that are in place will resist any attempt to "lose" their territory.

[nostrademons]

Largely false. Managers have pretty wide latitude to approve compensation matches for employees they want to keep without up-leveling them. So if you're a star L5 at Google and Facebook is giving you a $MM E7 package, you could end up with a $MM stock grant (which would normally be reserved for L7+) at Google. Compensation raises are tied to level, but that just means that you'll sit and vest your existing stock grant without further raises or refreshers until your formal level matches your comp package. This happened semi-frequently in the ~2010-2011 era when Facebook was recruiting heavily out of Google with pre-IPO stock.

The promo process is based on your value to your employer, and at least at Google is done by committee, which is drawn from a selection of high-level employees outside of your manager's department (so they have no incentive to keep you) and has a packet of information that does not include anything about your market value outside the company.

[m0zg]

Stock ranges (as well as refresh grants) are also tied to levels you're hired at. "Largely false" my ass. All of this BS applies _only_ to people with weak skill stacks. Committee doesn't even know your "previous" level elsewhere. They know that you've e.g. built this very impressive distributed system here and now and hopefully it made $MM revenue difference (which you'd be smart to quantify and mention). So if you can do it, you'll get rewarded appropriately. If you can't, you won't. And sure, you can't go E5 to E7, there's just no way. But getting from E5 to E7 (or T5 to T7 at Google) is doable in two promo cycles for someone who's in the right place at the right time, and has the right skill stack. Or in fact in the immediate if they are willing to move to another FANG company.

[nostrademons]

Distributed system & big data knowledge is table stakes for Google engineers. At L4 you will be expected to deal with large distributed systems handling petabytes of data. You probably don't need it for L3 (which includes new grads who would never have had an opportunity to develop that skillset elsewhere), but by the time you're at L4 you should be dealing with that regularly.

This is one of the perks for moving from FAANG to non-FAANG; hiring managers elsewhere know that simply by being an engineer there you will have had exposure to distributed systems and big data, and so bring a transferrable skillset to their company.

I thought about whether your comment is true in the context of Speech & Image recognition and other AI technologies. The Speech leads do seem to have an awfully high number of Distinguished/Fellow engineers (this is the top of the eng ladder, where you can basically write your own ticket and your comp package is enough to retire on). However, there are still an awful lot of L4 engineers working on Speech, many training deep-learning models as part of their daily duties.

FB may be different.

[m0zg]

> Distributed system & big data knowledge is table stakes for Google engineers

True, but observe that knowledge is very different from _experience_. In anything sufficiently complicated there's tons of stuff you won't find in books, and even if you do, you won't pay sufficient attention to. E.g. you could sorta know how a database works (from a university course or something), but if you haven't implemented e.g. a state of the art query engine or a storage manager, you'll still be SOL in practice until you write one or more of those things and actually gain experience.

Knowledge by itself is darn near worthless, it only becomes valuable with experience, particularly if it's in 2 or more related fields.

[mring33621]

I like the explicit cost/benefit and time-boxing!