As tutors, much of our value is as a kind of advanced "rubber duck". So we can be extraordinarily valuable, without even saying much at all.
Additionally, it is really essential that we fully understand the problem before we try to tutor. If we don't, we can end up leading students down the wrong path, and causing more frustration and stress later.
So, I encourage and try to follow a 70 to 30 split of my time between listening and tutoring. Some of that 70% time can be spent with clarifying questions, but you want to spend a lot of the time trying to understand how the student's code is actually working.
Once you really are sure you understand the problem, you can begin to talk about solutions. But you must also always be prepared to spend a substantial amount of time listening again, because you may have gotten a bad read on the problem initially.
We can often skip through tutoring too quickly, without stopping and ensuring that our student fully understands what we are trying to explain. When this happens, the student gets more and more confused as time goes on, and may not feel confident enough to stop you and go back.
As such, it's your responsibility to make sure that you aren't moving too fast. You can do this by checking in with the student every few minutes or after you explain a concept. Watch out though, because some students may nod along as you are explaining, but if you see any hesitancy, you may need to stick around on that topic.
A good way to help students open up is to ask for questions, but not ask "Do you have any questions?" which implies that having questions is an abnormal state. Instead ask "What questions do you have?" which reinforces the fact that students should have questions, rather than suggesting they should have understood the concept immediately, without problems.
Finally, it's my personal belief that the best way to learn is to work with someone else to make a solution.
This is distinct from guiding someone else to create the solution on their own! Even though we want to ensure that the student is learning, we also can't load all the work onto them. Oftentimes, a student is coming for help with a problem that they have already tried to solve.
Guiding questions certainly have their place! But they can't be our primary technique.
Instead, I'm a big fan of working out a solution on a whiteboard, working together to fill out a function. Guiding questions here are certainly valuable, but if a student hasn't gotten a solution after one or two attempts (and a guiding question or two), then it's fair to write a line out yourself and explain how that line of code works.