How would you handle this as a senior manager? Given that there are already coding standards, process etc.
There are coding standards already set and the junior engineer is following the standards, yet the senior engineer is throwing pretty long and a number of comments on the junior engineer's code. This is annoying the junior engineer.
EDIT: The original answer was intended for the direct manager of both the junior engineer and the senior engineer involved. Since OP is a senior manager (and therefore not the direct manager of the people involved), I'm adding a second, more applicable answer. I'm leaving the original answer for posterity and because it may be useful.
New answer:
This is not your problem. You are a senior manager. You have way more important things to be dealing with than whether or not some junior developer 3 reporting steps below you likes his colleagues. If this issue is making its way to you then that means someone below you has dropped the ball. What you should do is find the people in the chain of command in between you and these 2 developers and ask them why they aren't doing their job and why these issues are making it into your realm of awareness. These issues should be handled way below your level, that's what those people are being paid for.
Call a very serious meeting with everyone in the chain of command between you and these 2 developers (not including these 2 developers themselves) and have those people explain themselves, as to why they were not able to successfully manage this conflict and resolve it in an amicable way. If you are not able to get a satisfactory response, then fire all of those people and hire competent middle-managers. Handling these sorts of conflicts so you don't have to is the sole responsibility of middle management, and if that's not being done then those people need to be replaced with people who can do the job.
Original answer:
This depends a lot on the types and volume of comments being made. Speaking as a (sort of) senior developer myself, one tactic I've used in dealing with junior developers is to allow them to merge their code if it reaches 80% of my code quality bar. Obviously a junior developer won't make 100% of my code quality bar, because I'm a senior and they're not, and it's really not worth spending twice as much time arguing over something silly, for 20% code quality. It's ok to let things slide once in a while.
It's also important that the comments being made teach important lessons. Junior developers are junior for a reason, because they're inexperienced. Telling someone to do something a particular way isn't helpful, because they'll make the same mistake again next time. Explaining to them why they shouldn't make that mistake is more helpful, because it teaches them why not to do something, so they won't make that mistake again, and they'll also complain about it less if they know the comment has a reason and is not just "do it because I said so", which a lot of senior dev comments tend to be (oh how I learned this early in my own career!). It's also important to try this once in a while as an exercise: If you make a comment on a PR but are unable to back up that comment with rationale or logic, then perhaps that "coding standard" is not as important as you think it is and maybe the junior is right to ignore it.
Conversely, there are some junior devs who don't understand why they're junior devs; they think they're hotshot rockstars from day 1 and any comment on their PR gets taken as a personal attack. That's also not productive, and if your junior dev is like that then you need to have a chat with them and bring them down to earth. The point in such a chat isn't to chastise them or break their spirit, but rather to bring some perspective: "You've been doing this for 6 months, Bob the Senior has been doing this for 6 years; he has some expertise that you don't have and he is happy to teach it to you if you are willing to learn".
Depending on the situation and the personalities involved, you may want to talk to your senior dev to "put on the kid gloves", so to speak, or to the junior dev to give them some perspective and put them in a learning mindset.
How would you handle this as a senior manager? Given that there are already coding standards, process etc.
I would first point them to such coding standards, processes etc. that your company has defined.
You can also expand that with explaining the reason and benefits of including comments in code, specially when working on teams.
Whenever one person complains about another I get the two people together and ask them if there is an issue at hand.
I don't consider this a question about coding standards. I consider this a question about managing people.
