8 ms·

There do exist those rare creatures who manage to get promoted to, and beyond, L6 as ICs. I've been trying figure out how they do it, but can't say I've been m

by aix1 5y ago

There do exist those rare creatures who manage to get promoted to, and beyond, L6 as ICs. I've been trying figure out how they do it, but can't say I've been making much progress. (I'm Staff myself, but would not have got here without management responsibilities.)

nostrademons 5y ago
I'm an L6 IC. Basically I had a track record of delivering projects that other engineers said couldn't be done yet were a high priority to upper management. That's actually on the (Google at least) ladder: "At this level...most Google-caliber generalist SWEs could not own and solve the problem this person is owning and solving." Note that even though I'm a coding-heavy L6 (meaning I spend ~50% of my time coding vs. the 0% that most L6s do), the majority of my time is still spent interfacing, negotiating, and communicating with other teams. The ability to silo in a particular problem domain and just become a local technical expert ends at L5.
- faizshah 5y ago
  Can you give an example of a project like that? Or at least a hypothetical example if they are confidential. I can’t think of a project like that that people said couldn't be done, its usually just people saying “we cant do it at this time unless we get more time or reprioritize something else.”
  - ativzzz 5y ago
    Not OP, but I image they are more projects that span multiple teams, disciplines, and stakeholders. There's nothing (unless it hasn't been invented yet) that can't be implemented in software in a silo given infinite time, but the ability to deliver complex solutions to difficult business/process problems that require buy in and coordination from a lot of people are probably these kinds of projects, particularly if these projects are alterations or additions to other pieces of complex processes that already exist and are hardened but need improvement or overhaul. Here's an example from my work. We use a legacy version control system alongside git. This causes tons of issues and the way forward would be to deprecate the legacy version control, but doing so without disrupting current engineering work and making tangible improvements going forward is a very complex task that spans a whole lot of teams and is risky and tricky to implement
    - faizshah 5y ago
      Thanks! That makes a lot of sense.
    - analognoise 5y ago
      Is the legacy vcs ClearCase or DesignSync?
      - ativzzz 5y ago
        no
  - nostrademons 5y ago
    My current project is confidential, but one from 2013-2014: We had a bunch of UXR that showed that people liked iPhones because of the fancy snappy animations, and our execs really wanted to bring that to Google's webapps. At the time, there was this big perception that mobile web sites were slow and clunky and you absolutely had to go native app to get smooth 60fps transitions. I did some profiling with the Chrome profiler and found that the bulk of time was spent in layout & reflow, and that one single reflow would blow your entire frame budget and then some for 60fps on mobile. So then I went to the Chrome GPU team and got a quick tutorial about exactly which operations were handled on the GPU (basically just transform and WebGL, at the time), and put together a visual language that basically involved rendering portions of the webpage to GPU textures and manipulating them only with 2D transforms, which could be GPU-accelerated. The work later formed the foundation for how Material Design was implemented in Search. As a side note, I learned a lot about how browsers work under the hood with that project, and one of the things I learned is that the entire premise that React was sold with was false! At the time, the big selling point with React is that "DOM manipulation is slow, so we create a virtual DOM that's fast and then diff the changes to the virtual DOM so we make only the minimal set of DOM changes we need." Except that every major browser by 2013 used a dirty-bit system for DOM manipulation, so changes to the DOM are actually quite fast (roughly the speed of a couple pointer manipulations in C) as long as you don't trigger reflow. And you can trigger reflow with any one of about 2 dozen method calls, as well as automatically when you return from a Javascript script fragment, so basically every Angular and JQuery website was triggering multiple reflows per event. React was fast because it was declarative and didn't let you execute user code until it was done batching up all DOM manipulations, it wasn't fast because of the virtual DOM. And I believe there have been re-implementations of the React API that do away with the virtual DOM and they are equally fast (oftentimes even faster, since they're simpler and don't need the DOM diffing), but at this point React is popular because it's popular and everyone knows the API, not because of any purported performance benefits.
    - Impossible 5y ago
      What about this project made it L6? Is it because it was a high priority for execs? Is it because you had to get a lot of buy-in from external team(s) in the Chrome org?
morei 5y ago
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!
- deleted 5y ago
  [deleted]
- mring33621 5y ago
  I like the explicit cost/benefit and time-boxing!
- UncleMeat 5y ago
  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 5y ago
  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.
dharmab 5y ago
I've seen this track described as a "Solver", a sort of internal mercenary who can join a project with a critical, difficult problem, research it to a very detailed level and drive a solution.

by aix1 5y ago

nostrademons 5y ago

I'm an L6 IC. Basically I had a track record of delivering projects that other engineers said couldn't be done yet were a high priority to upper management. That's actually on the (Google at least) ladder: "At this level...most Google-caliber generalist SWEs could not own and solve the problem this person is owning and solving." Note that even though I'm a coding-heavy L6 (meaning I spend ~50% of my time coding vs. the 0% that most L6s do), the majority of my time is still spent interfacing, negotiating, and communicating with other teams. The ability to silo in a particular problem domain and just become a local technical expert ends at L5.

faizshah 5y ago
Can you give an example of a project like that? Or at least a hypothetical example if they are confidential. I can’t think of a project like that that people said couldn't be done, its usually just people saying “we cant do it at this time unless we get more time or reprioritize something else.”
- ativzzz 5y ago
  Not OP, but I image they are more projects that span multiple teams, disciplines, and stakeholders. There's nothing (unless it hasn't been invented yet) that can't be implemented in software in a silo given infinite time, but the ability to deliver complex solutions to difficult business/process problems that require buy in and coordination from a lot of people are probably these kinds of projects, particularly if these projects are alterations or additions to other pieces of complex processes that already exist and are hardened but need improvement or overhaul. Here's an example from my work. We use a legacy version control system alongside git. This causes tons of issues and the way forward would be to deprecate the legacy version control, but doing so without disrupting current engineering work and making tangible improvements going forward is a very complex task that spans a whole lot of teams and is risky and tricky to implement
  - faizshah 5y ago
    Thanks! That makes a lot of sense.
  - analognoise 5y ago
    Is the legacy vcs ClearCase or DesignSync?
    - ativzzz 5y ago
      no
- nostrademons 5y ago
  My current project is confidential, but one from 2013-2014: We had a bunch of UXR that showed that people liked iPhones because of the fancy snappy animations, and our execs really wanted to bring that to Google's webapps. At the time, there was this big perception that mobile web sites were slow and clunky and you absolutely had to go native app to get smooth 60fps transitions. I did some profiling with the Chrome profiler and found that the bulk of time was spent in layout & reflow, and that one single reflow would blow your entire frame budget and then some for 60fps on mobile. So then I went to the Chrome GPU team and got a quick tutorial about exactly which operations were handled on the GPU (basically just transform and WebGL, at the time), and put together a visual language that basically involved rendering portions of the webpage to GPU textures and manipulating them only with 2D transforms, which could be GPU-accelerated. The work later formed the foundation for how Material Design was implemented in Search. As a side note, I learned a lot about how browsers work under the hood with that project, and one of the things I learned is that the entire premise that React was sold with was false! At the time, the big selling point with React is that "DOM manipulation is slow, so we create a virtual DOM that's fast and then diff the changes to the virtual DOM so we make only the minimal set of DOM changes we need." Except that every major browser by 2013 used a dirty-bit system for DOM manipulation, so changes to the DOM are actually quite fast (roughly the speed of a couple pointer manipulations in C) as long as you don't trigger reflow. And you can trigger reflow with any one of about 2 dozen method calls, as well as automatically when you return from a Javascript script fragment, so basically every Angular and JQuery website was triggering multiple reflows per event. React was fast because it was declarative and didn't let you execute user code until it was done batching up all DOM manipulations, it wasn't fast because of the virtual DOM. And I believe there have been re-implementations of the React API that do away with the virtual DOM and they are equally fast (oftentimes even faster, since they're simpler and don't need the DOM diffing), but at this point React is popular because it's popular and everyone knows the API, not because of any purported performance benefits.
  - Impossible 5y ago
    What about this project made it L6? Is it because it was a high priority for execs? Is it because you had to get a lot of buy-in from external team(s) in the Chrome org?

morei 5y ago

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!

deleted 5y ago
[deleted]
mring33621 5y ago
I like the explicit cost/benefit and time-boxing!
UncleMeat 5y ago
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 5y ago
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.

dharmab 5y ago

I've seen this track described as a "Solver", a sort of internal mercenary who can join a project with a critical, difficult problem, research it to a very detailed level and drive a solution.