I don't personally agree with the idea that senior is basically the end point of writing high level code. Perhaps it's just a difference in terms but I think of seniors at the high end of their capacity as being able to release high quality features. But if I needed a whole new app greenfielded, would I trust a senior to not only get the job done, but execute at a high level, with a clear vision, clean design system, beautiful code base, all the right choices of libraries, following all the best practices, linting, style, etc? Of course not.
To me, a staff engineer can deliver that application at that level, and can lead senior engineers in maintaining and enhancing it.
We also consider a level above that, the principal engineer, who is primarily focused on higher level and longer term thinking and less about individually jumping into tickets and features. They re-envision the entire approach to implementing the business logic and scale the business in ways that seniors are mostly helpless at. They do work through others much more, and I do personally see Staff Engineer as the highest level where you primarily are still coding day to day.
IMHO greenfield vs new features vs maintenance/tuning/scaling are different skill sets, not level dependent per se. Plenty of junior engineers can spin up a reasonable greenfield app, and plenty of staff/principal engineers never have had to.
The way I look at it is that levels only make sense within an organization that is big enough that a hierarchy is needed to scale. At that point staff+ IC levels are needed because you want purely technical people on the same pay scale and influence level as managers to counteract the incentives of empire building that can corrupt the entire architecture and lead to a Dead Sea effect of engineering talent if left unchecked.
From this perspective most staff+ work is in some way generating influence and impact across multiple teams and individuals. Outside of certain specialties and specific R&D roles I think it’s pretty hard to justify staff leveling on purely technical work.
Of course different companies calibrate levels differently, and they’re all subject to level inflation, but that’s my feeling for a traditional Google L6.
In my opinion, there is absolutely no way a junior / SWE1 could greenfield an app by doing anything other than following a youtube tutorial or similar step by step guide, and would have basically no understanding of the decisions made throughout. They would have no real experience with style, linting, no good opinion on libraries, no knowledge of accessibility, security, usability, nothing. They would end up with a basic 'hello world' application that would likely fall apart before you could even get your business logic in there.
If you have a SWE1 that can literally just greenfield an entire application and do it at a very high level, then they are a unicorn / 10X developer operating at a ~SDE4 level already.
I personally do not think the average SDE1 can meaningfully contribute to a quickly moving and efficient team. By the time they are even able to contribute regularly, they are SWE2/mid in my book.
I do have much less experience in giant beaurocratic slow moving organizations so I don't have an opinion on how all of that rigmarole works, I'm speaking more to highly focused small teams delivering at a high level quickly.
Sure, someone that is an entry level programmer will not have deep technical knowledge, that's not what I was trying to say though. My point is that levels only make sense in organizations that are big enough that tech leadership can't directly assess and compare ICs work because there's too much going on for any one technical expert to assess. Smaller organizations sometimes cargo cult leveling systems because it helps their ICs resumes and give a sense of progression even though the organizational problems that are the raison d'etre for staff+ levels don't exist at that scale.
To say it a different way: consider hobbyist developers who have spent a lot of time developing technical skills. These folks will tend to be very good at creating greenfield apps, and depending what they do, they may also have technical chops that are applicable to large companies as well. So they may be able to be hired as L4 or L5 (Google leveling) just based on technical chops. L6+ will be tough though, unless they have very deep specialist knowledge, because the most common L6+ work is about using technical knowledge to achieve outcomes that depend on navigating multiple teams and stakeholders in a way that the solo dev never has to deal with.
To me, a staff engineer can deliver that application at that level, and can lead senior engineers in maintaining and enhancing it.
We also consider a level above that, the principal engineer, who is primarily focused on higher level and longer term thinking and less about individually jumping into tickets and features. They re-envision the entire approach to implementing the business logic and scale the business in ways that seniors are mostly helpless at. They do work through others much more, and I do personally see Staff Engineer as the highest level where you primarily are still coding day to day.