How can I handle a situation where honest mentoring resulted in junior acting rude?

Based on the context you provided, I think you've done a lot of the right things already. In the past, one of my seniors got frustrated with a more junior engineer around the same issue. Initially, I asked them to work through it, but once it became a pattern, I wrote a quick "help etiquette" email on what groundwork I expect all team members to do, so they respect other people's time and like you said, get a resolution faster. That said, you don't need to immediately take this step and escalate and try a few additional things first:

• Pull them aside in a 1-1 and bring up the example you mentioned, state what your intentions are and how it benefits them, then be assertive in stating how it made you feel - often times they are also dealing with some issues and not considering all POVs
• If you still can't come to an agreement, I find having another senior person speak to them (who they see as a friendly/peer) usually does the trick
• After trying the above, you may want to engage the project lead or their manager to mediate - frame the conversation around making the work smoother for everyone and driving alignment while remaining open minded to alternative approaches

There's are some good responses within Taro already, I've linked a few below:

https://www.jointaro.com/question/5vEWajcZlSi7nlohTGtJ/what-does-it-mean-to-not-require-handholding-anymore/

https://www.jointaro.com/question/0Im1Kcgso1fJ8eAX3oOO/how-do-i-not-bother-people-when-asking-for-help/

https://www.jointaro.com/lesson/YIL3iK8fmSwhWP0PASqe/asking-questions-is-not-a-sign-of-weakness/

It seems like you're a well-meaning senior engineer who's being genuinely helpful - Great job on your mentorship and time investment so far!

That being said, my immediate thought here is to go to your manager. It's the manager's job to help, well, manage people and bolster relationships within their team. There's no hard obligation for you to continue mentoring this junior engineer - It seems like they can be more appreciative of feedback.

That being said, this feedback angle goes both ways. Feedback is always a gift, and I'm generally careful about responding to feedback with feedback of my own as that can come off as deflecting or defensive behavior. Of course, your feedback for the mentee is valid, but I would strive to find additional ways to address their feedback without completely shifting the burden to them like:

• Finding a "backup" mentor they can go to if you're busy like another mid-level or senior engineer on your team
• Giving them the tools to ask their questions in more public forums instead of always seeking 1 on 1 help
• Walking through past questions they have asked in detail and explain how they could have been improved

It also seems like this junior engineer is too dependent on you - This isn't great for their growth path towards mid-level engineer. Hopefully these resources can help there:

• "How to ramp up a slow learner?"
• "How can I help juniors?"

However, this resulted in her passive aggressive behaviour towards me. One such behaviour example is in code review - when I commented that local environment specific initialisation code shouldn’t be in the main classes, she responded that she doesn’t see any problem and it’s just unnecessary.

I probably need more context here, but this doesn't seem like passive aggressive or even negative behavior, just a disagreement about code (which happens all the time). Some things to think about in this interaction:

1. Did you sufficiently explain why that local code didn't belong in main classes? Did you provide examples?
2. Did the mentee sufficiently explain why they didn't believe it was a problem? Did they provide examples?
3. What was the tone when the mentee replied to your comment? Was it tentative and/or appreciative? Or did they just say it wasn't a big deal and reject the suggestion?

You know this person better than I do, but that disagreement on a code review change doesn’t seem particularly passive aggressive to me personally.

Again, I wasn’t there. So I can’t speak to that instance, but I will say that it’s difficult to read tone charitably in written text sometimes.

That being said, there are a few things you could do to ameliorate the issue.

Speaking with a superior - Whether it’s a PM, Team Lead, etc. Communicating your difficulties to them might help to reduce issues with this team member.

Working with this person less by gradually moving to a more hands off approach in teaching - This might not be a practical option for you, but choosing to work with this person less and trying not to engage with them more than necessary could help you with not having to deal with their behavior. To move towards that goal, you could gradually begin to decrease your current level of assistance by just nudging this junior in the right direction as opposed to directly giving her the answer to her issue. It’d be better for you and better for her growth as a developer to have to find the right answer on her own.

Seeing if another person on the team can assist the junior - Since you’ve already provided a significant amount of guidance and the high-level design, a less senior developer on the team might have the bandwidth for you to delegate the assistance of this junior developer with you only needing to provide assistance as needed.

These are just a few things you could do that might help to address some of the difficulties you’ve been encountering with this junior developer and do keep in mind that these options aren’t mutually exclusive either. You might find that applying all three to be the solution or only 1-2 that do the job.

In either case, I wish you the best of luck with your situation. 🙂👍🏼

Agreed with the existing responses, I'll just add one thing.

Equally important to stating what you do intend is stating what you don't intend.

Example: "My intent isn't to be a blocker or an annoyance during PR review, it's to work together on the code in a way that works for both of us and ensures consistency / maintainability."

The "your actual intent" part can be modified how you like. The first sentence is the "what you don't intend part" and it opens the other person up.

In their head, they may have a "story" that they created about you. It might be something like: "This person is just an annoying blocker that I don't want to deal with when I put up code reviews." Expressing what you don't intend helps to start canceling out the story they've built up in their head, makes them come back down to earth, and realize that you are just a human trying to make things better together

I really like what's been provided already. For myself, I've certainly always had issues of other engineers time at one point or another, but I'm going into founding of my own company, so this becomes less of an issue for me personally.

I usually keep most of my mentees self-sustaining to the point where they don't need me and if anything that's what a good mentor should do. What I do do for them though is provide them the resources I want them to learn from to close gaps in their knowledge so they can be a better partner to me.

I've definitely seen varying amounts of uptake on what I provide and I really like to work with the folks who put in the large amount of work to close the gap. What's 3 days spent reading the 7th Edition Kurose and Ross networking book if you work heavily in an area that utilizes it? Furthermore, it saves the friction on my schedule when I have to dive in and help. Not that I won't help, but I'm not the one with the knowledge gap.

In your case, I'm not sure I'd really enjoy walking them through the details of a high level design to a super meticulous degree. I usually put an architecture diagram in mural, put all relevant details to explain and complete the tasks, and then divide out the work into stories we can tackle in serial or in parallel. Keeping the onus of whose knowledge needs to develop to complete the task I think can make them more independent.