An assortment of commonly asked questions related to mentoring
What qualifies someone to be a mentor?
Can I mentor a language while I'm still learning it?
Can I mentor more than one language?
Should I try to mentor every solution in the queue?
What if a solution has been sitting in the queue for days, even weeks?
What if I have nothing to suggest about a solution?
Should I mentor an exercise I've never solved?
Should I mentor an exercise I've solved, but solved in a different language?
Do I have to mentor a solution once I've seen it?
What if the student does not understand after I've explained something several times?
How do I respond if the student gets defensive about my suggestion(s)?
Should the student have the last word, even if I think they're wrong?
How do I best phrase a suggestion?
Should I enforce formatting, commenting, and naming conventions?
You don't need to be an expert in a language to mentor that language. You only need to be a little less of a novice than the person you're mentoring. If there is someting in a solution that you think could be done in a different way, you can suggest it. It doesn't necessarily have to be a better way, just an idiomatic alternative. That leaves the choice of whether to use the suggestion or not with the student, but at least the student has more options to choose from.
Ideally, you never stop learning a language, even one you already know. Some languages put out an updated version every few weeks or months. Not only may there be new language features to learn, but there may be existing features you're unaware of. Sometimes a student may use a feature, and that will be the first time you've ever seen it. So mentoring can be a good way to learn more about a language.
You can mentor as many languages as you feel comfortable with. It's okay to mentor multiple languages you feel strong in, as well as a language you're still learning.
If you can't think of something substantive or constructive to say about a solution at the time, it may be better for the student if you leave the mentoring request for another mentor, even if that student will need to wait longer for a response.
If the student asked a specific question that you can't answer, you may still want to leave it for someone who can answer their question.
Otherwise, the solution may be for an exercise that was hard for you, which you either may not have solved, or solved but felt you didn't solve very well. In that case, you might look over the solution to see if there is anything you can learn from it. If so, you can thank the student for what you specifically learned from their solution.
Or you may wish for the student to explain their solution to you. That is kind of a "reverse mentoring", but some students may be happy to explain their solution when asked politely and respectfully. You could then ask if they considered another approach and why they chose the approach they did.
Or, you still may not understand the solution overall, but you may see some things you can address.
For example, you might point out to consider using meaningful names for function parameters,
if they used just n or m.
If you're not comfortable doing any of those things, it's okay to leave the request unanswered. Mentoring is voluntary. Just because you're mentoring a language doesn't mean you have to mentor every exercise for that language.
It's okay to say what you like about a solution. In fact, saying what you specifically like about a solution is a good way to start any mentoring encounter. After doing that, if you have no suggestions for alternative ways to approach the exercise, it's fine to just tell the student, "Well done!" If the student submitted more than one iteration, you may be able to point out in what ways the most recent iteration is an improvement.
Sometimes, looking at a student's solution will inspire you to solve the exercise yourself, especially if the approach used in the solution is one that makes the exercise seem simpler than approaches you may have already considered. After solving the exercise, if the mentoring request that inspired you is no longer available, you will at least be ready for the next time.
Given that what is idiomatic in one language may not be idiomatic in another language, it is likely best to have solved the exercise in the language being mentored. If the solutions between two languages are very similar, and you know both languages well enough to know what is idiomatic in each, then it shouldn't take long to transpose a solution in one language to the other. If the mentoring request is no longer available after transposing the solution, you will at least be ready for the next time.
You may look at a solution and realize you don't want to mentor it for any of several reasons, including:
Nothing obligates you to click the "Start mentoring" button if you think the particular mentoring request is not for you.
There may be times when a student seems almost willfully resistant to understanding your explanations. If you feel you've exhausted all the ways you know to explain something, you may decide to finish the discussion with a suggestion that the student resubmit their mentoring request so it can be handled by another mentor who may be more successful in explaining the difficult point(s).
Sometimes a student will say they used a more laborious approach than necessary as a way to learn more about a language feature, even though that feature is not best suited for the exercise. Since Exercism is a platform for learning and not a competitive coding site, that is a justifiable reason for not using the most elegant or efficient approach. You might make some suggestions on how they used their approach, if you see they could have implemented their approach more idiomatically. In any case, you can suggest that they can submit another iteration based on the feedback, or they can end the discussion to free up a mentoring slot.
A student may adhere to a programming paradigm that may not be best suited for the language or the exercise. For example, they may always want to use the object-oriented paradigm, and fragment a relatively simple and straightforward solution into a little explosion of classes with labyrinthine control flow through multiple methods. To the extent that the student is a dogmatic follower of the paradigm, it is usually fruitless to attempt to persuade them of a different approach. You can try, and they may respond to your suggestion, but if the student digs in, it may be best to move on.
The student may outright reject a suggestion.
For example, you may suggest using reduce instead of map and join,
since reduce is only one iteration instead of an iteration for map and another for join.
But the student may reject that, because they find map and join to be more readable.
It's okay to agree with the student that map and join can be more readable than reduce.
You can suggest they may become more comfortable with reduce after more time to get used to it,
and there is nothing wrong with using map and join.
It's okay to agree with a student to the extent they are correct, and it's okay to make an attempt to correct any misconception or exagerration the student may have expressed.
For an example, you may suggest a student not use magic numbers such as 60 and 24
when solving the Clock exercise, but suggest defining them as constants with meaningful names.
The student may respond that, given the context, it's obvious what 60and 24 stand for.
You've made your suggestion and the student has dismissed it.
There may be nothing to gain, and perhaps goodwill to be lost, by arguing about it.
To suggest something as an alternative which might not necesarily be better, you might preface it with "Another approach could be..."
For example, "Another approach could be to use every with includes."
If introducing a language feature the student hasn't used in the solution (such as every or includes),
it would be good to link to a doc that explains it.
Another way to preface a suggestion might be "Perhaps consider..." For example, "Perhaps consider using spread syntax instead of split()." If you feel strongly that the student should use an alternative, you might drop the "Perhaps" and start with "Consider..." For example, "Consider using a default argument."
For a series of suggestions you may want to vary how each one is introduced.
Bullet points are an effective way to list what you like about a solution. They may come across as less friendly when listing suggestions. Offering suggestons in a casual, conversational way may make them less challenging for the student to consider and accept.
One word that is probably best not used when offering a suggestion is "should". For example, "You should use a default argument." Using words like "should" or "must" can come across as overbearing.
Mentors are likely to disagree over when and how strongly to bring up matters such as code formatting, commenting, and naming conventions. On the one hand, you might want to get the student thinking about such things early on with exercises like Two Fer, before they start developing bad habits. Or you might not want to intimidate a beginner with all considerations of propriety. On the other hand, students doing the more advanced exercises may already know the conventions but choose to ignore them while focusing on the task at hand. They may resent a continued focus on conventions as pedantry. If a language has one or more formatters or linters, it can be good to choose an exercise where to introduce them. Otherwise, if the violation of a particular convention is really bad, you may want to point it out wherever it happens. Where mentors may differ is in what may be considered "really bad".