Most advice about mentorship addresses one side of the relationship and assumes the other side will figure itself out. That's a gap worth closing, because the skills that make someone a good mentee are almost entirely different from the skills that make someone a good mentor, and most engineers will spend real time in both roles over a career, often simultaneously with different people.
Being a mentee: bring a specific question, not a general one
"Can you help me get better at backend engineering" is a request nobody can act on well, including a mentor who genuinely wants to help. It's too broad to produce anything but generic advice. "I keep underestimating how long database migrations take on my team's schema — can you look at how I scoped my last two and tell me what I'm missing" is a request someone can actually engage with, because it's grounded in something concrete they can examine.
The habit worth building is showing up to mentorship time having already done the thinking a mentor would otherwise have to do for you. Bring the specific decision you're stuck on, the two options you're weighing, and your current leaning — not just the raw problem. This respects a mentor's time and, just as importantly, produces better advice, because advice given in response to "here's what I'm considering and why" is almost always more useful than advice given in response to "what should I do."
Follow up afterward on what you actually did and what happened. Mentors rarely get to see the outcome of advice they give unless a mentee closes that loop explicitly, and that feedback is what lets them calibrate their advice for you specifically over time, rather than giving the same generic guidance to everyone.
Being a mentor: resist solving it for them
The instinct when someone brings you a problem you already know how to solve is to just solve it — hand over the answer, move on, feel useful. It's fast, and it's usually the wrong call if the goal is actually developing the other person rather than clearing your own queue of their questions. The more useful response is almost always a question back: "what have you tried," "what do you think is happening here," "what would you do if I weren't in the room." This is slower in the moment and produces someone who can solve the next three problems like this one without you, instead of someone who's learned to bring you problems.
This doesn't mean withholding answers as a rule — sometimes the fastest, kindest thing is to just tell someone the answer, especially when they're blocked and the concept isn't the point of the exercise. The judgment call is distinguishing "this is a learning opportunity worth the extra time" from "this is just a blocker that needs clearing," and good mentors get better at that distinction with practice, not by applying one rule uniformly.
The part both roles share
Both sides of a mentoring relationship benefit from treating it as a two-way exchange rather than a one-directional transfer of wisdom. A mentee who only ever asks and never offers a different perspective, a piece of context from their own experience, or even just genuine engagement with the mentor's reasoning, makes the relationship feel extractive over time. A mentor who never learns anything from the relationship — a fresh perspective, an unfamiliar tool the mentee is using, a question that makes them reconsider something they'd stopped questioning — is missing half of why the best mentoring relationships tend to last. The strongest pairings tend to look less like teacher and student and more like two people thinking out loud together, with one of them further along a particular path.