I only recognize difference between junior/senior levels.
My definition of senior developer:
- Senior will not be "stuck" with a problem. They recognize there is somebody to get help from and they will seek it. But they can also function when there is no person to get technical help from. They will dig, and dig, and dig, until they finally solve the problem.
- I can trust the solution to be usable even without supervision.
- They will have minimum standard they will enforce around them (ownership). Ownership for me means they will look for things that are not right and act on it, without being specifically instructed to.
- Is adult in behavior, can recognize and control their emotions, can work with other people, recognize and deal with communication problems.
From my perspective, people who have huge technical knowledge and experience but can't be trusted with tasks, can't be trusted to not get conflicted with the team on the first possible occasion, are not honest with their results (hide problems), will sacrifice good of the project because they just have to test that new tech -- all these people are junior devs for me.
Your list only handles how senior engineers solve problems.
IMO the most important qualities of a senior engineer pertain to knowing what problems to solve, and, at an even higher level of seniority, why those problems need solving.
For example, senior-level engineers will recognize when a problem is not worth solving at all. They might know that a solution is technically possible/feasible, but they will also understand that the engineering resources (i.e. their time) can, and in fact should, be better spent elsewhere -- fixing more egregious bugs, enhancing existing features and developing new ones.
To go back to what you said, being able to "dig, and dig, and dig" until they solve a problem is not what makes someone senior-level. Anyone with sufficiently high levels of dedication and stubbornness can go down rabbit hole after rabbit hole until they stumble upon something that resembles a solution. What distinguishes senior-level engineers is being able to step back and analyze the situation to determine if the rabbit holes are worth diving into.
Let's be honest, this is requirements for a senior engineer, not a tech lead.
It would, of course, be nice for a senior engineer to have perfect awareness but I think that is too much to ask to qualify to be called senior.
Have you watched Star Trek (DS9 for example) lately? You may have a bunch of senior officers but they still do not always understand why stuff needs to happen. They muddle through on principles until they succeed. Then it is always easy, retroactively, to say it was their idea all along.
This feels like the difference between someone who _needs_ mentoring and someone who does not. In other words, a senior engineer according to your definition can (mostly) "manage themselves". I do think that this is good in that it gets at the core of what makes a software engineer good (from the perspective of a good manager).
At the same time, this is sort of an oversimplification the levels to senior engineers. I've seen a lot of people who have skills that really make them signficantly more effective than other people on the team (particularly me). Here are just some of the common differentiators:
- Getting tasks done [1]: As antirez says, I've noticed that some people just implement things quickly, while others take too much time. Even worse, many experienced engineers learn "too much" and make their code too "perfect" out of habit, even if they are aware of their perfectionism.
- Architecture ability: Some people simply come up with good designs more quickly. They know which data stores to use. Their predictions about scale turn out to be correct. Their designs are simple enough for other engineers to understand. Overall, their designs simply turn out to take a lot less time for the team to implement, test, and release to the customer (and not necessarily in that order).
- Expertise in CS fields: Hard problems do come up and block engineers. Good people can avoid/work around the unsolved ones and just implement that fancy downsampling or concurrency control technique when performance/correctness matters. (Ex: your shiny microservice mess is full of thorny networks/dist computing/database problems. I've seen multiple inter-service race conditions from people who don't know what a transaction is)
- Tooling experience: The person with experience with k8s will implement more quickly than the person who's never worked with a cluster manager. This is not that important, but more important than many more experienced engineers say it is. How long can you wait until your team is supposed to have a working system?
- Other qualities: product expertise, user design, interpersonal (some people singlehandedly make a team's culture good), ops skills, analytics skills, hiring (well now this is just more about what makes a general employee valuable)
My definition of senior developer:
- Senior will not be "stuck" with a problem. They recognize there is somebody to get help from and they will seek it. But they can also function when there is no person to get technical help from. They will dig, and dig, and dig, until they finally solve the problem.
- I can trust the solution to be usable even without supervision.
- They will have minimum standard they will enforce around them (ownership). Ownership for me means they will look for things that are not right and act on it, without being specifically instructed to.
- Is adult in behavior, can recognize and control their emotions, can work with other people, recognize and deal with communication problems.
From my perspective, people who have huge technical knowledge and experience but can't be trusted with tasks, can't be trusted to not get conflicted with the team on the first possible occasion, are not honest with their results (hide problems), will sacrifice good of the project because they just have to test that new tech -- all these people are junior devs for me.