You want to help a junior developer who's stuck. You can probably spot a possible solution faster than they can, and it's tempting to take the keyboard, make the change, and move on. Sometimes a direct answer is exactly what's needed. But when every request ends with you doing the work, the developer misses the reasoning that would help them handle a similar situation later.
The alternative isn't to leave them struggling until they've earned your attention. Helpful mentoring starts by understanding the request, then choosing how much explanation, guidance, or demonstration fits that moment. Keep the learner involved. Make the unclear parts clearer. Use your experience without replacing all of theirs.
This article is about that immediate conversation: someone asks for help with the task in front of them. It's not a training curriculum or a rule that junior engineers must investigate alone before speaking to you.
Understand What Kind of Help They're Asking For
"I'm stuck" can mean several different things. The developer might not understand the requested behavior. They might understand it perfectly but not know where the implementation belongs. Or they might have a hypothesis, tried to test it, and found something unexpected.
Those aren't interchangeable problems. Before giving advice, listen to understand the person's difficulty. You don't need a polished presentation from them. A rough explanation can be enough to uncover the missing piece, provided you're actually listening rather than waiting to announce your solution.
A few starting questions can make the request more concrete:
- What are you trying to make happen?
- What happens instead?
- Which part is unclear right now?
- Are you looking for context, another perspective, or someone to work through it with you?
These questions aren't an interview script. If the person already explained the situation, don't make them repeat it to satisfy your process. Use whichever question would change your understanding.
Imagine a hypothetical developer working on a setting that controls whether users receive notifications. They say they can't get the behavior right. You assume they're debugging the setting lookup. But they don't know whether the setting should affect existing notifications or only future ones. A clever debugging suggestion doesn't answer that question.
The first useful help is clarifying the intended behavior. You might know the answer, or you might need to connect them with someone who owns the decision. Either way, the request wasn't evidence that they needed more persistence.
This is where listening before offering a solution becomes practical. You're not delaying the technical work. You're finding out which technical work makes sense.
Give Help Immediately When the Goal Is Unclear
Asking what someone has tried is useful when there's a clear problem to investigate. It's less useful when the person doesn't know what success means.
Don't ask a junior developer to experiment their way into a product decision they don't own. When expectations are ambiguous, seek clarification immediately. A question about requirements isn't something they should have to earn by wasting effort first.
The distinction can look like this:
| Situation | Useful help | What to avoid |
|---|---|---|
| The expected behavior is unclear | Explain it or identify who can decide | Asking for random implementation attempts |
| The behavior is clear but the system is unfamiliar | Show relevant context and a starting point | Treating missing context as a lack of effort |
| The developer tried an approach and got a surprising result | Explore the reasoning and evidence together | Replacing the work before understanding the attempt |
| The next action could create avoidable risk | Give direct safety guidance | Letting a learning exercise override safe operation |
These are conversational distinctions, not permanent labels for a person. Someone can need immediate clarity and then be ready to investigate independently once they have it.
Be specific about what you're clarifying. "Make it consistent" may sound obvious to you, but it leaves the developer guessing which existing behavior is the reference. Showing the relevant requirement or explaining a concrete example can help them move forward without making every implementation choice for them.
It's also fine to say you don't know. If two interpretations seem plausible, acknowledge that uncertainty rather than delivering your preference as fact. Mentoring doesn't give you authority over every product or technical decision.
After clarification, check whether the developer can describe the target in their own words. You aren't asking them to repeat you perfectly. You're checking that you now mean the same thing before they spend more effort on it.
Ask What They Tried Without Making Help a Reward
Once the goal is reasonably clear, ask about their attempts. The purpose is to understand their thinking so you can help, not to audit how long they've suffered.
"What have you tried, and what did that tell you?" is more informative than "How long have you been stuck?" The first question can reveal a useful observation, an assumption worth checking, or a step they didn't know was available. The second may tell you very little about the actual problem.
Suppose, hypothetically, the developer says they changed a condition and the test still failed. You could immediately tell them to change a different condition. Or you could ask what they expected the first change to affect and whether the failure changed at all. That conversation may reveal that the code they edited wasn't running.
Useful details to surface include:
- The result they expected from an attempt.
- The result they actually observed.
- The assumption connecting that attempt to the problem.
- The next thing they considered but weren't sure how to check.
Don't insist that every request contains all four. Sometimes a junior engineer doesn't know what evidence is relevant yet. Helping them describe an attempt can help you both understand the evidence.
If they haven't tried anything, find out why. Missing access, unfamiliar tooling, and unclear expectations call for different responses from a developer who understands the task but wants reassurance before making a safe change. You can encourage an attempt without withholding necessary information.
Tone matters here. "Show me what you've got so we can figure out where to go next" offers collaboration. "Come back when you've actually tried" can turn the conversation into a test of whether they deserve attention. The broader communication skills involved in engineering apply even when the problem looks entirely technical.
You can also notice good reasoning without pretending the result was correct. "That was a reasonable thing to check because the failure started after that change" is specific feedback. It separates a useful investigation from whether the hypothesis happened to be right.
Let the Developer Drive While You Help
When working together, leave the developer in control of the interaction where that makes sense. They can navigate, make changes, run the check, and explain what they're seeing. You're there to help with the reasoning, not just narrate while your hands do everything.
That doesn't mean sitting silently beside them. You might suggest where to look, explain an unfamiliar concept, or point out an observation they missed. The important question is whether they understand the next action and its purpose.
A hypothetical exchange might sound like this:
- Developer: "I think the value is getting replaced somewhere."
- Mentor: "What would we expect to see if that's happening?"
- Developer: "The original value would be correct, but it would change before the response."
- Mentor: "Okay. Where could you check those two points?"
This isn't a claim that every developer will respond with a tidy answer. It's an illustration of keeping them involved in selecting the check. If they don't know how to inspect the value, explain that missing technique instead of repeating the question.
Ask them what they think the result means after running it. A successful check can still leave the reasoning unclear. Likewise, a failed hypothesis isn't a failed mentoring conversation if they can explain what it ruled out and why another possibility now looks more likely.
Avoid becoming a remote-control operator. If every instruction is "click this, open that, change this line," the developer is physically driving but may not be making decisions. Pause when appropriate and ask them to connect the action to the problem.
The reverse mistake is over-questioning. If you already know they're missing a piece of context, making them guess it repeatedly doesn't create independence. It creates an obstacle. Useful informal leadership is about enabling another person's contribution, not proving that your questions are difficult.
Choose Questions, Steering, or a Demonstration
There's no universal rule that a mentor must never provide an answer. Different situations need different amounts of help, and you can change the approach during the conversation.
Questions are useful when the developer has enough context to reason but needs another perspective. Steering is useful when they have some of the pieces but don't know how to connect them. A demonstration is useful when the missing piece is a technique they haven't seen.
Consider the tradeoffs before choosing:
| Approach | What it can offer | Where it can go wrong |
|---|---|---|
| Ask an open question | Makes their reasoning visible | Can feel like guessing when essential context is missing |
| Suggest a direction | Helps them identify a useful next check | Can become a sequence of unexplained commands |
| Explain the answer directly | Removes a specific information gap | Can skip reasoning the learner was ready to practice |
| Demonstrate a technique | Shows an unfamiliar action concretely | Can turn into doing the entire task for them |
You don't need to announce which category you're using. Just pay attention to whether this kind of help is useful.
For a hypothetical unfamiliar debugging tool, you might demonstrate how to inspect one value, explain why you chose that location, and then let the developer inspect the next relevant value. The demonstration provides necessary knowledge. The handback gives them a chance to apply it.
If you make a change yourself, say why. Explain the assumption behind it and how you intend to check it. Don't let speed conceal the reasoning, especially when the developer asked for help understanding rather than just an immediate unblock.
There are also moments when the task needs direct intervention because of risk or urgency. Be clear that you're handling that situation, not establishing a permanent model for every request. If further explanation is needed, acknowledge it rather than claiming that watching a fast fix provided all the learning.
Finish With a Next Action They Understand
You don't have to solve the entire task together for the help to be useful. An endpoint might be a clarified requirement, a hypothesis the developer can test, or a technique they can now use themselves.
Before separating, check what happens next. "What are you going to try, and what will that tell you?" can expose any remaining uncertainty. If they can only repeat your instruction, explain the purpose again in a different way.
Possible outcomes include:
- They can investigate the next possibility independently.
- They need a specific answer from a different person.
- They can apply the demonstrated technique to the remaining cases.
- You discovered a decision that needs clarification before implementation continues.
None of those requires the developer to pretend they're completely unblocked. It's better to identify the remaining dependency than to end with a polite "got it" that neither of you trusts.
If the conversation reveals a repeated knowledge gap across several developers, that's a different problem from helping one person right now. Addressing gaps in how junior developers understand code may require broader teaching. Don't turn every immediate request into that whole program.
For this exchange, stay focused on what the learner can do next and why. You can invite them to return for more help with what they observe without making return visits evidence that the first conversation failed.
Frequently Asked Questions About Helping Junior Developers
Should I always ask what they tried before I help?
No. First understand whether the goal is clear. If the developer doesn't know what behavior is required, explain it or help them get the decision clarified immediately. Once there's a meaningful problem to investigate, asking about attempts can reveal their reasoning. It's a way to choose useful support, not an entry requirement.
Is giving the answer bad mentoring?
Not automatically. A direct answer can remove a missing fact, clarify an expectation, or prevent an unsafe action. The concern is making replacement thinking your default when the person could participate. Explain the reasoning when it's relevant, and leave room for them to apply what they learned rather than turning the answer into a completed task.
What if questions make the developer more confused?
Change your approach. They may need context, a narrower question, or a demonstration before they can reason productively. You can ask which part of your explanation isn't connecting. More questions aren't inherently better help, and a confused reaction doesn't establish that the person isn't trying.
Should the junior developer always control the keyboard?
It's a useful default for collaborative problem-solving, not an absolute rule. You may need to demonstrate an unfamiliar action or handle something that shouldn't be attempted without the right access or knowledge. Keep that intervention purposeful, explain what you're doing, and return participation to the learner when appropriate.
How do I know whether the help was useful?
Look at what the developer can explain and do next. Can they describe the goal, connect a check to a hypothesis, or apply a technique with less prompting? Those observations are more useful than whether you finished the task quickly. One conversation won't prove lasting independence, but it can show whether the next action is understood.
What if the developer keeps asking for help?
Repeated requests alone don't tell you the cause. They could involve different unfamiliar areas, missing context, or explanations that aren't connecting. Look at the actual requests before concluding that there's a dependency problem. For the conversation in front of you, identify the need, adapt your support, and make the next step clear.
Help That Leaves the Developer Involved
Helping a junior developer doesn't require choosing between taking over and withholding answers. Listen to the request, clarify the goal immediately when needed, and understand what they've already observed.
Then choose the help that fits: a question, a useful direction, a direct explanation, or a demonstration. Keep the person involved in the reasoning and the next action. The task matters, but so does whether they leave understanding more than which line you changed.