Junior to senior in 2.5 years? I mean, you could do it, by playing politics. But are you really a senior engineer?
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.
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.
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.
If you work at a Fortune 500 and then jump to a FAANG, this difference is very obvious.
See for example this blog by Joel Spolsky [1].
[1] https://www.joelonsoftware.com/2005/07/25/hitting-the-high-n...
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.
Most sensible companies measure by impact - and Taro focuses on how to explain and justify that.