How To Effectively Ask For Help as a Junior Software Engineer

Learn how to get the support you need as a software engineer while also boosting your reputation.

How To Effectively Ask For Help as a Junior Software Engineer

I'm Jian, and I'm here to share some valuable insights I learned while working at a fast-growing startup as a junior software engineer. While the essential skills and techniques in this article are especially applicable to junior software engineers, they're also crucial to anyone at any stage in their career.

In fact, these strategies helped me excel as a junior software engineer, and got me top scores during my performance review. I achieved this by applying a combination of soft and technical skills to rapidly unblock myself at work.

In this post, I'll share why it's important to ask questions, and how to do so effectively.

The "Cost" of Asking Questions

Junior software engineers are often overwhelmed by information -- it's difficult to glean what to learn, let alone how to learn effectively. If you add the fact that your coworkers are often "too busy" to help, you're left with an overwhelming fear of not knowing what to do.

This might result in over-learning to compensate for your imposter syndrome or being too afraid to ask for help because you're worried about wasting someone's time. However, it's this very mindset that's preventing you from further growing. Meanwhile, your coworkers are zooming past you with little time to waste, like the Rabbit, in Alice in Wonderland – so what do you do?

Reframe Your Mindset

The first step is identifying the mental barriers that are holding you back. Let's consider the mental fallacy above: The belief that your coworkers are too busy to help you. The term "busy" implies an absence of spare time, but in truth, time management is a flexible practice. It lies in the choices you make -- a dynamic process that changes as priorities reallocate towards what you deem most valuable.

Consequently, if you can present a compelling case for why someone should help you, they will likely shift their priorities, especially if it would benefit them as well.

At the end of the day, everyone wants their team to succeed, especially more senior engineers. If you are able to clearly define why unblocking you is important, and frame your request for support effectively and respectfully, your teammates should be more than happy to help you.

Do Your Homework

The first thing before you ask for any help is to ask yourself: "How do I make it as easy as possible for another person to help me?"

The person trying to help you is often far removed from your situation. They're not a mind reader, so your goal is to clarify what you don't understand to make it easier for them to fill in those gaps. It's much harder to help someone who doesn't know what they're searching for than to help someone who does. The way to receive effective help is by first reflecting on what you don't know.

Here were the questions that I asked myself when I was blocked:

  • What are my knowledge gaps? What am I uncertain about, and what do I need to learn to gain clarity?
  • Are there low hanging fruits to reduce my knowledge debt before I make any asks?

You want to gain a sense of what you're unaware of, and do the pre-work of priming yourself. This means exposing yourself to the problem, so that you can rapidly map out what you know vs. what you don't. The goal isn't to know everything: it's to get your feet wet and assess any blockers you'll face; it's figuring out all the questions you'll need to ask, prior to your meeting.

When it comes to coding issues, here are some techniques to deepen your understanding:

  • Skim through methods to gain a high-level picture of the system
  • Command-click through methods to learn the exact execution flow
  • Run the program/service while printing log statements
  • Search for existing code that already solves the current problem that you're facing
  • Git blame code to see which coworkers could help you
  • Keep track of important questions as you explore — sometimes you might run into conceptual gaps, other times there are procedural gaps in how to set up the environment, etc – batch the questions you plan on asking to save as much time for your coworker.

Don't Be Afraid To Meet People

At some point, you're going to hit a wall in terms of what you can figure out vs. what you can't. The point is to prime effectively, so don't spend too much time here. Just having a well-defined list of questions is more than enough.

In any case, figure out your knowledge gaps as quickly as you can, ideally with a meeting. Work with your teammate to clarify any gaps by asking  everything you're missing, along with any popup questions that might show up during the conversation. Get it all out there at once!

The quicker you pay down knowledge debt -> the faster you can navigate code -> the faster the code velocity. This all equates to having higher confidence at work.

I liken this process to exploring an RPG game — you traverse through the world, and the relevant parts of the minimap light up as you explore new territory. Over time, you get familiar with locations you explore and remember where to go when you need certain resources. Likewise, when you're having the conversation with your coworker, you want the minimap to light up as much as possible, and you can only do this by asking as many questions as needed to bridge the gaps of your understanding. If you do this correctly, the neurons in your brain should be firing as you're enlightened by your new understandings. Take the meeting as an opportunity to become an expert in what you don't know.

Getting Full Value From Everyone's Time

There's really no point in asking questions if you're not growing from them. Asking questions costs time, and you want to make sure it pays off. A good outcome from asking questions means:

  1. You have high knowledge retention and you can replicate your understanding through explanation or application.
  2. You never have to ask the same question twice.
  3. If you do ask a question, it's always different and always with the intention of further deepening your understanding.

If applied correctly, your questions should increase in quality as well as your depth of knowledge. Now that you're having this meeting with your teammate, you can do the following to maximize value:

  • Ask relevant follow-up questions to further increase your knowledge depth around the problem. This effectively enhances the depth of your knowledge tree and increases your knowledge retention, thus making your understanding more nuanced, and easier for active recall. If you don't get something, don't ignore it -- continue pushing the envelope until you truly learn the subject.
  • Reflect on your understanding, especially if your knowledge foundation is weak, and get validation from the other person before moving onto next topics. Repeat in your own words what you think they are saying, and get feedback to see if you're going in the right direction. You want to make sure you're not developing false knowledge, and since your goal is to build knowledge as quickly as possible, focus on clarifying your understanding through active engagement.

Remember To Give Back

Assuming all went well, you were able to rapidly unblock yourself and finish the project/deadline. You should have been thanking your coworker for their time during the unblock session, but as the fruits of your labor have finally landed, now it's time to really give back to your coworker:

  • Give them a shout-out (the more public and detailed the better) so upper management is aware of their impact (alongside yours).
  • Tell their manager personally how awesome they were. Make sure that it gets reflected in their performance review.
  • Buy them coffee or tea. Be creative!

By really investing in this gratitude portion, your teammate will be more willing to help you in the future -- this is on top of your proven track-record for success and your ability to learn very quickly. Your reputation will improve and others will see you as a worthwhile investment.

All in all, capitalize on giving back and people will help you succeed even as a junior software engineer.

Being a junior engineer is scary, but it doesn't have to be. As long as you're bold enough to put yourself out there and get the support you need, you'll do just fine!

If you like what I have to say, I would love to connect with you on LinkedIn:

If you liked this article, I'm sure you'll like Taro, the premier resource for growing as a software engineer. If you're interested in Taro Premium, you can get a discount by using my special referral link here: