Tell me about a time you mentored a junior engineer, intern, or unblocked a struggling colleague.

In Simple Words: Effective mentorship is not about giving answers; it is about teaching problem-solving frameworks, providing safe guardrails, and building lasting confidence.

The STAR Response:

• Situation: A newly hired engineer was struggling to make progress on their first major microservice feature and was visibly hesitant to ask questions during daily standups, spending days blocked on asynchronous event handling.
• Task: Help the engineer build technical competence, unblock their feature, and establish psychological safety.
• Action:
  1. Set up a low-pressure 1-on-1 coffee chat to build rapport and normalize that our distributed system has a steep learning curve.
  2. Established a 30-minute rule: if blocked for more than 30 minutes, they should write down what they tried, the expected vs actual behavior, and ping me for a quick pairing session.
  3. Instead of writing the code for them, practiced "driver-navigator" pairing where they held the keyboard while I prompted them with guiding questions.
  4. Co-created a local Docker Compose test environment that allowed them to reproduce async message flows on their laptop in seconds.
• Result: The engineer delivered their microservice feature on time, became the team's subject matter expert on event consumers, and within 9 months was independently leading complex feature implementations.

Practical Script & Summary Template

### The 30-Minute Engineering Unblocking Protocol:
When reaching out for help, formulate questions using this structure:
1. **The Goal**: "I am attempting to achieve [X]..."
2. **The Problem**: "When I execute [Y], I receive error [Z]..."
3. **What I Tried**: "I verified network reachability, checked Redis logs, and inspected payload headers..."
4. **Current Hypothesis**: "I suspect the token validation middleware is rejecting the header due to clock skew."