I am a senior developer and train graduates and apprentices as developers, so I am familiar with people not knowing much.
You say your new manager has asked you to emphasise the mentoring aspect of the role. You can only do that if you have an understanding of who they hire, both in a technical as well as a personality sense.
My suggestion is to express a far greater interest into the hiring process. Talk to your new manager and tell them that you'd like to be included in interviews. Look at your company's job listings and make sure that the skills listed there are relevant to the position and that they make sense. Feed this back to your manager, who is likely going to be the hiring manager here (but be careful, they might have written it).
If that doesn't work, you will have to figure out first what the people you're given already know. This is always tricky. Keep in mind that most of them will be well-meaning and might not know that they're not very good (if they are not). And it might not be their fault that they're there now, and are not meeting your expectations. If your organisation does not pay market value for example, they will not hire top talent, so you will have to work with what you get.
You should be open and approachable to new hires, make them feel welcome, safe, and encourage them to seek your help. Take some time (yes, I know, deadlines, but this has an ROI) and pair-program with them through their first ticket. Chose a small task that does not require much business knowledge for that. Let them fix a bug that's already diagnosed, for example. Let them drive, sit back and explain proprietary things and business logic on the way, but observe their approach, their technical savvy and how they solve problems.
Keep in mind that different people work in different ways. It can look like someone is slow if they don't use keyboard shortcuts, or if you are used to doing everything in the terminal and they like an IDE. But at the end of the day these things don't matter.
You want to see if they understand what's going on, and if they can figure out how to solve a problem. Don't make up your mind too early, and don't judge. They are at a new job, working with a product they have never seen before, in a new code base that is scary and full of intimidating things that will make them feel like an impostor and they have an experienced person sitting next to them. They will want to impress, and it's naturally that they're stressed. Give them time, and be supportive.
About Pair Programming
In order to facilitate pair programming, you have different options. Remember that you are onboarding someone new, so they will expect that you know the ropes, and they'll be glad about any help they can get. On average a senior developer takes about 3 to 6 months to be fully productive, so it's OK to want to look for guidance in the beginning.
The easiest way is to just offer it to them.
Hey, you got your first ticket assigned. I've got some time this afternoon, so if you want we can sit down together and I can walk you through our ticket workflow and help you get started.
Always try to make it sound like an offer, but not like they will owe you after. You're there to help, and it's safe to ask you things.
You can also check in regularly. Again, try to sound friendly and like you're just trying to help.
How is that ticket going? I know our codebase can be a bit overwhelming at the start. Let me know if you need any help. I'm happy to pair up with you as well.
Alternatively, you can just go and do it. Even if that's not the current company culture, they don't know that yet, because they're new. This is your chance to shape a new culture. If you push this onto new hires, and they enjoy it, they'll embrace it and carry it forward, and the next hire will experience it as normal.
During your pair programming sessions, try and be a passive source of feedback. These people are supposedly experienced, so don't tell them what to do. Instead, your presence should be reassuring. You're there to help, but not to judge. Point out oddities in the repository structure or give anecdotes about why stuff is the way it is as they move along the code, but don't take over the keyboard or mouse. That's probably the most important lesson for mentoring there is. Never take over the keyboard or mouse. That's intimidating and makes them feel inferior or not good enough.
When they are making a mistake, wait for a bit before you point it out. Let them compile and see what's going on. Give them a chance to catch the problem themselves before you intervene (unless maybe it's a missing semicolon).
Watch your language. Don't use expressions like "just do this" or "you could have simply done this instead". That trivialises the problem, although it was probably hard for them to solve. Instead say things like "oh by the way, there is an easier way to do x. Do you want me to show you?".
Finally, don't make the sessions too long. It's hard to concentrate for a long period of time, but it's even harder to do that when someone is watching you. I notice myself getting bored when I'm watching someone for more than an hour, and I lose interest, especially if it's slow going. Allow for breaks, and see how the other person is feeling. If you think concentration is going down, suggest a coffee break. In fact, I often offer to go and get beverages when I'm the one watching.
While we're all working from home during Corona (in the UK in my case), I run a one hour session twice a week with them sharing their screens and video turned on both ways with each of my trainees. They're beginners, and we never did working from home before, so initially I focused a lot on explaining that this is not so I can control that they're working, but that it's so they have a chance to get direct, live feedback. They've all embraced it and are looking forward to the sessions. Sometimes they ask for more of them, too.
Pairing is a powerful mentoring tool, even if all you're doing is helping another senior person out. We can all learn from each other, and we never stop learning.
