mrmekon [1] gave an excellent answer:
It depends on when and why I'm defining it, but my guidelines are more based on how they work than what they know:
* Junior developer - Will not produce much business value if left alone, and may produce nothing at all. Requires supervision.
* Intermediate developer - Will produce something if left alone, but not necessarily what the business most needs. Needs minimal supervision, but defined goals.
* Senior developer - Will produce immediate business value if completely ignored.
The domain and language don't matter for these, really. A Senior Go developer is going to produce immediate business value if you suddenly throw him/her into a Lisp team, too. Just slower.
Between the two answers I think they have it covered. Now some businesses will call people senior after they've been there 5 years, but they might still be a junior in capability.
Where I do disagree just a little bit with mrmekon, is that I tend to look for people who have experience with the necessary stack. I would be hesitant to hire a senior developer for a C#/MVC position if they have (broadly) never used C# or never done web development, for example. Modern stacks have a lot of moving parts, and I would prefer senior developers to understand how to troubleshoot, tune, upgrade, test, and deploy on the needed stack. These are things that a very strong developer could remediate within a few projects, though, which is why I only slightly disagree with mrmekon.
In my team's case, I was hired to do ML/BigData but had no prior experience. My boss's philosophy is that he wants smart engineers with a desire to learn more than he wants area experts. He's been burned more than once with area experts who were unable to pivot well with the shifting priorities of the team.
That said - if you're hiring someone to come be your ML expert then that requires an expert. Tech stacks are less that way in my opinion and they're rarely static. Even the debugging and troubleshooting tends to be similar if you know the problem space.
With the way you've outlined it I think you've emphasized that a 'Senior developer' is someone who can be both social and technical, that's a good thing and would be very beneficial for any person who can do those two things well... but I wouldn't discount people who are exceptionally technical but need someone else to help them prioritize and define their work and focus.
Previously, I'd either have no idea what to do with it, or just not work on that thing at all. (Usually I'd move on to something else, since there was seldom that I didn't have multiple things that needed doing.)
It means that I'm a lot more efficient at getting things done, but I never get so far out of the proper path that it's a problem. And even going down the wrong path usually produces something of value for the correct path.
Quite often I get no response, and just continue. But those time that I do get a response are still important enough that I'm not willing to risk missing them.
The difference between these two do not seem to be related to technical ability but rather being able to detect 'business value' within the organization's general business model.
The business value defined by the engineering department and the business value defined by the business department, can be sometimes very different.
People who work in environments with, for example, "pressure -- lots of pressure" often end up not realizing there's another option that's actually a lot healthier for them, their coworkers, and their organization.
Senior professionals avoid all of that nonsense like the plague and would never glorify it. Senior people are professionals who work efficiently and effectively.