Mentoring and Coaching: Guiding Without Telling Phrases
5 exercises on mentoring language. Choose the most natural and professional option.
0 / 5 completed
1 / 5
A junior developer comes to you with a problem. What is your best opening question?
OPENING DISCOVERY QUESTION: "What have you tried so far?" is the foundational coaching question. It respects the mentee's effort, avoids duplication, and surfaces their reasoning — which often reveals where the thinking went wrong. Examples: "What have you tried so far? I want to understand where you got stuck." / "Walk me through what you've attempted — what worked, what didn't?" / "What have you tried? Let's rule out what we know doesn't work before exploring new directions." Option A is dismissive, B removes the learning opportunity, D is a blame-inducing question that undermines psychological safety.
2 / 5
You want to help someone think through a decision without imposing your view. Which question works best?
HYPOTHETICAL THINKING QUESTION: "What would happen if you...?" is a coaching technique that guides someone to discover consequences themselves rather than being told. It builds analytical thinking and ownership of decisions. Examples: "What would happen if this fails halfway through the migration — have you thought about rollback?" / "What would happen if two users hit this endpoint simultaneously?" / "What would happen if the API rate limit kicks in during peak load?" Option B tells rather than coaches, removing the learning. Option C is condescending. Option D redirects rather than coaches.
3 / 5
A junior developer proposes a solution that mostly works but has an edge case. How do you respond?
AFFIRM WITH NUANCE: "That's a solid approach — one thing to consider is..." validates the effort and thinking before introducing a gap. This phrasing is used in expert code reviews and mentoring sessions to preserve confidence while raising the bar. Examples: "That's a solid approach — one thing to consider is the behaviour when the input list is empty." / "Good thinking — one thing to consider is whether this works at scale, or just in the happy path." / "That's a solid start — one thing to consider is error handling if the network call times out." Options A/B/C shut down the conversation and provide no learning context.
4 / 5
Your mentee proposes a technical assumption as fact. How do you encourage them to verify it?
TESTING ASSUMPTIONS: "How would you test that assumption?" is a Socratic coaching question that builds scientific and engineering thinking. It teaches the mentee to validate before implementing. Examples: "How would you test that assumption — could you write a quick benchmark?" / "How would you test that the cache hit rate is actually what you expect?" / "How would you test that assumption in a staging environment before we commit to this architecture?" Option A is a blunt correction without teaching, C is overly broad advice, D deflects the coaching opportunity to someone else.
5 / 5
A junior developer is working on something complex that would benefit from working together. How do you offer help without taking over?
OFFERING PAIRED COLLABORATION: "Let's pair on it" is the professional offer of collaboration that builds skills rather than creating dependency. Adding a structure — "I'll drive first, then you take over" — makes the knowledge transfer explicit. Examples: "Let's pair on it — you navigate while I drive and we talk through each decision." / "Let's pair on this for an hour — I'll show you the testing pattern, then you write the next test." / "Let's pair on the database layer — I've done this migration type before and it'll be faster if I show you live." Options A/D create dependency and remove learning; B abandons the mentee without support.