The last six months I’ve been working as a mentor in one online school - this became a certain stage after mentoring in chats for free. Most of this part-time activity is occupied by reviewing projects. And here are the thoughts I wanted to share:

The main thought is that you need to give detailed feedback. That is, not just point out what needs to be fixed, but explain the reasons why it should be done exactly this way. This way you can transfer your experience and close several problems that would arise with an approach without detailed feedback. First, this removes distortion where it may seem that the student knows why it should be this way. It’s obvious to us, but for the student, most likely not, since they’re making a mistake. Second, this allows avoiding taste preferences. If the code works, performs the task, and tests cover what’s needed, then it doesn’t matter that the style differs from how I would write it. A certain line emerges: if there’s no justification for why it needs to be done differently, then the solution is accepted.

Leave refactoring to student’s choice. Part of fixes I write with a “not required” note, behind which are hidden complex challenges, but which are generally optional for an educational project. That is, the student can decide themselves whether to refactor their solution or not, just google what it is, or ignore it because it’s good enough. With this approach, it turns out not to nightmare students with impossible requirements, while showing in which direction to grow. Everyone has different deadlines and learning conditions, so the student chooses their optimal variant of immersion in the topic.

Don’t spend a lot of time on review and do it iteratively. Since all projects involve test coverage, for review an editor isn’t required and a GitHub link is enough where you can immediately see general features. If tests are green and passing, you can focus on the solution without worrying that the solution is crooked. First you can go over the surface and understand that the solution architecture doesn’t have critical problems, or immediately send the solution for rework without checks for type annotation or documentation presence, because this can change during refactoring. This way, the student gets quick feedback and doesn’t waste time determining priorities, because there’s focus only on critical things, and small things will be next.

And probably the thought in general about mentoring: this is an important process and it’s worth adding to the list for career growth for those who want to develop in the profession, because it allows training awareness, correctly forming your thoughts and highlighting growth points for yourself.

Have you had experience working as a mentor or with a mentor?