What I Learned from 726 Mentoring Sessions

Across 726 mentoring sessions, one thing stays constant: people come in describing one problem and walk out with clarity on a completely different one.

That is the real job of a mentor. Not answering questions. Reading between the lines. Understanding how someone thinks, figuring out what they are actually looking for, and mixing that with your own experience to find the right path forward. Sometimes that path is a solution. Sometimes it is a learning. Sometimes it is a three line code fix that unblocks a week of frustration.

The first challenge for any mentor is reading the thoughts of the mentee. What are they saying vs what are they actually stuck on. Then deriving what they need from the conversation and steering it toward something that makes the solution resilient enough that it is no longer fragile.

Why Some Engineers Reach Lead in 16 Months While Others Struggle After a Decade

Across hundreds of sessions, I have seen a pattern that separates engineers who grow fast from those who grow at a snail's pace. It comes down to one habit.

The ones who grow fast question things. The ones who don't just follow instructions.

I regularly see software engineers and senior engineers who are afraid to comment on what their architect or lead has decided. They follow instead of questioning. They accept instead of understanding why something is done a certain way. That single habit is the biggest career growth bottleneck I have observed.

Curiosity and owning the next level of responsibility without waiting for a promotion is the very first step. JIRA tickets won't tell you to unlock the next level. Your thinking will. Did you consider how your change impacts the overall system? Did you think in all directions? Did you communicate to relevant stakeholders? Was there brainstorming to validate the solution? That is what differentiates a craftsman from an average developer.

A Real Example: Mid-Level to Lead in 16 Months

One engineer I mentored made the jump from mid-level to lead in 16 months. Here is exactly what they did:

1. Studied how systems are designed. Not just their own codebase. They went wide. Learned the core principles behind common system design patterns. Built mental models for how different architectures solve different problems.
2. Started writing architecture proposals. Without being asked. They would take a first draft, justify every decision with reasoning, and explain why they chose a specific approach over alternatives.
3. Brainstormed with me regularly. We reviewed what went well, what could be improved, and extracted learnings from each design exercise. Every session built on the last.
4. Presented to their company's architecture forum. With solid backing: what went into the design, what comparisons and POCs they ran, and clear results-oriented outcomes. Not slides with buzzwords. Real engineering decisions with evidence.
5. Got the promotion. Not because they asked for it. Because they were already doing the job before the title caught up.

Everyone can write code. But craftsmanship is something only a few will develop. When you start thinking beyond the lines of code in front of you, that is where growth unlocks.

The Team Problem: No One Steering the Wheel

The second pattern I see constantly is teams made up almost entirely of software engineers with few or no middle and lead engineers steering the wheel. There is a pile of tech debt that accumulated over time and a list of architectural improvements that could stabilize production. But nobody has the experience or authority to prioritize them.

This is the sweet spot where a mentor who has worked on enterprise applications can make a massive difference. Navigating and fixing tech debt, optimizing architecture, and making the application resilient. Not in theory. In practice.

How Tech Debt Silently Kills Products

Here is a pattern I see all the time. Users complain that pages take 10+ seconds to load despite having sufficient bandwidth. The team is confused because locally everything seems fine.

Then you look under the hood: unoptimized network calls stacked on top of database issues. No indexing on frequently queried columns. Too many unused columns in tables. N+1 queries firing hundreds of database calls where one would do. No caching layer. Complex business logic riddled with if-else ladders. Unclear transaction boundaries. Stale code that nobody knows what it does but nobody dares to remove.

No unit tests. No automation tests for faster regression. Teams shipping features for two years straight without ever addressing the database layer, then wondering why everything is slow.

Nobody refactors because there is always a next sprint priority. Until one day the tech debt is the priority because nothing else works.

Observability: The Most Overlooked Growth Lever

This is the one that surprises people the most. Largely, no one knows how observability can take an application from zero to hero with real insights that power decisions for optimization.

Without observability, you are flying blind. Your production broke at 12 PM but you find out at 2 PM when your customer starts calling you. With proper alerting, you know the moment it happens. With proper metrics, you know why it happened. With proper tracing, you know exactly where it happened.

The hard part is not setting up Grafana or Prometheus. The hard part is knowing which data points to define, what to look at on priority, and which metrics actually drive decisions. That is where a mentor with production experience makes all the difference. You don't just get dashboards. You get the right dashboards.

What People Actually Ask About in Sessions

Across 726 sessions, the most common topics fall into a few buckets:

• System design and architecture decisions: how to structure a service, when to split a monolith, how to handle event-driven communication
• Production debugging: something broke, nobody knows why, and the logs aren't helping
• Career growth: how to move from senior to lead or staff, how to demonstrate architectural thinking, how to get noticed for the right reasons
• Code quality and tech debt: how to introduce testing, refactoring strategies, convincing leadership that tech debt matters
• Cloud and infrastructure: AWS architecture choices, Kubernetes setup, CI/CD pipeline design, cost optimization
• AI-augmented engineering: how to use AI tools effectively without creating the mess I wrote about in my previous post

Beyond Code: What Mentors Actually Solve

Sometimes we think only coding, testing, and some DevOps is real engineering. But who looks at code quality? Code security? Optimal deployments? Cost management for cloud applications? Observability to unlock improvement opportunities? Engineering processes? How AI can improve everyone's productivity?

These are the most overlooked and neglected aspects that need attention for future growth. There is no doubt about any individual's capability. But looking at a system as a whole, learnings from past experience, and a forward-looking vision is what a mentor brings to the table.

726 Sessions Later

After 726 sessions, if I had to distill everything into one line it would be this:

The engineers who grow fastest are the ones who stop waiting to be told what to do and start figuring out what needs to be done.

That is true whether you are debugging a production issue, reviewing an architecture decision, or planning your next career move. The mentor's job is to help you see what you are not seeing yet. The rest is on you.