I've always viewed the levels sort of like this, obviously very dependent on company:

Juniors need hand-holding at every step. They may be new grads who don't even know how to behave in a professional environment or very inexperienced folks 1-2 years out of school taking a role in a completely different language they're unfamiliar with. You're talking to them anywhere from 5+ times a day to every other day as they transition up. They may have lots of meetings, especially during onboarding, but they're mostly listening. Their day-to-day is almost entirely "how" with very little "why."

Mids need hand-holding for the bigger picture stuff. You still need to give a general shape to their work but you can expect them to look up the docs for your validation library if they don't know how to do something, and you can expect to format and structure their code and PRs the right way every time (the junior will likely ping you on Slack asking how to write a custom validation function at least once). But it's unlikely you're going to need to talk to them daily. Hopefully they have large blocks of uninterrupted time to work as these are the folks churning out lots of tickets. They can also start thinking more about "why" than "how."

Seniors shouldn't really need hand holding for much of anything. Give them a feature or an entire product and they should be able to figure out approximately how to do it and what resources it will take. More meetings than mids but still need uninterrupted time. IME my productivity starts to really dip if I don't have at least two half-day blocks in a week. I'm in a new-ish job (first year still but 14 years in industry) so have been lucky so far but have been starting to block off chunks if I see my schedule filling. Seniors are probably running several of the meetings they're in, and maybe directing work for juniors and mids. I've been in companies where the line between Senior and Engineering Manager is very blurry as well with new EMs still spending 1/4-1/2 their time writing and reviewing code. And in most companies this is the "terminal" or "professional" level where you're not expected to move beyond here. Lots of folks will hit senior and be there for 15, 20, 25 years until they retire.

Staff is where the amount of code you write starts to drop off, meetings start to ramp up (you're no longer able to block off half your day), and in my opinion the biggest difference, you don't get assigned anything to work on. You're expected to have intimate knowledge of your business domain, your technical domain, and the challenges in both, and formulate plans to use technology to ease problems in both. I also feel like this is the first level where most companies don't need them, including a lot that have them. We have about 85 software engineers where I am, and two of them are Staff, which seems like about the right amount percentage-wise. There's only so much big work to go around and while there might be a lot of people capable of doing it, you don't want 10% of your engineers to be Staff and fight over the 0.5-1% of Staff work that's available. This is also the level I see it much more important what you're doing outside of work. Not as far as side projects, but going to conferences, speaking, user groups, having content available that works as advertising for your and your company, etc.

And then of course Principal where 99% of companies don't have or need them, where you're basically a VP or Director but on the Individual Contributor track rather than management. These are going to be so company-specific it's not even worth talking about them except in the context of a particular company. You're probably at Google or Microsoft or similar at this point.