I'll share an anecdote here. I worked with an engineer at Meta who went from L3 (junior) to L6 (staff) in 2.5 years.

And he truly did operate at the staff level -- I know because eng levels at Meta are private. As he was climbing the ladder, people who worked with him assumed he was already a Staff Engineer, and were shocked when they realized he was 1 or 2 levels lower than that (this info would come out during perf review season).

Seniority is generally about how much people can trust you in the team, to identify blockers, provide feedback, or plan a roadmap. You can call it politics, but no one on the team would have denied that this engineer was hugely impactful. We're trying to capture these lessons + case studies in Taro.

How much of that is optimizing for appearance/behaviour (Either intentionally or unintentionally) and other people wrongly pattern-matching though?

When I joined a big tech company the hardest part of ramping up was learning how to operate in that environment. There are a lot of implicit behaviours a "good" engineer is supposed to that you mostly have to figure out by yourself. Some of them are genuinely useful, but I think a lot are basically a kind of filter: https://twitter.com/danluu/status/1555077502803947520.

From what I've seen, the main skill for promotion in my company isn't engineering a well designed system, it's being visible and finding/creating the right projects.

I completely believe that someone could figure out how to behave like a higher level engineer and even succeed in their team, then get put in a different environment and completely flounder because they were mostly just copying behaviours that worked in their current environment, not learning fundamentals.

I'm also curious, vaguely what archetype was this Staff engineer: https://staffeng.com/guides/staff-archetypes.

I'd say they were somewhere between the Tech Lead and Solver archetype in the article you linked. BTW, we're big fans of staffeng, lots of good content there! One of the signs of promotion is that your behavior leads to having more impact (not just execution), so after a ramp-up period, I'd expect someone very senior to get back to that level of impact in a different team or even different domain.

You're right there is some element of pattern-matching that happens for a higher level engineer, but in my experience this has to be backed up with actually earning the trust of the broader team, and that requires strong fundamentals.

I mean, there’re brilliant individuals in any profession. I don’t see how that turns into a generalization. Most of engineers I’ve seen had to spend many years to become senior. Selling fast growth is denying the reality for most people.

The thing that a lot of people don't understand about SWE (and a lot of other 10x professions) is that years of experience has a very weak correlation with skill. A top tier junior engineer could easily become better than a 15 yoe senior engineer who's not so top tier.

If you work at a Fortune 500 and then jump to a FAANG, this difference is very obvious.

What’s even a “10x profession”?

Jobs where the difference in output between the best and worst is 10x. Generally creative professions like movie director, writer/journalist, lawyer, etc. SWE tends to fall into this category because the difficulty of writing good code is in some respects like writing good prose: the space of "solutions" is vast and there are few well defined rules by which a "good" solution can be constructed. Not only that, but writing it quickly while maintaining quality is difficult as well.

See for example this blog by Joel Spolsky [1].

[1] https://www.joelonsoftware.com/2005/07/25/hitting-the-high-n...

Something software engineers came up with to feel exceptional. There’re great people in most professions, but this “10x” concept is completely subjective and not quantifiable.

The link provides empirical data backing up the idea of 10x, specifically in the context of the speed and quality with which students come up with solutions to a programming project. Quality is measured by correctness and speed by time spent.

It also provides data showing that speed and correctness are essentially uncorrelated between different people - i.e. just because two different people finish at different speeds, does not mean the faster person has a less correct solution, at least in this specific setting. If you assume that's true generally, that makes the idea that there is a large gap between F500 programmers and FAANG ones even more credible, since the best programmers both produce better solutions and produce them faster.

Depends how you measure senior engineer.

Most sensible companies measure by impact - and Taro focuses on how to explain and justify that.

That is fast but I've seen interns that are close to senior a couple months in.