Asking Great Questions [Part 22] - Learn To Fish

Getting the answer to your question isn't enough: If you want to respect the person who helped you, make sure to follow through on the end-to-end learning. This lesson teaches you:

- A common mistake engineers make when getting an answer that's too shallow
- What engineers should do to follow-up on an answer and get full value
- Why it's better to potentially annoy your helper with more questions now instead of later
- The difference between knowledge and mastery, why the latter is so critical for your career, and how asking great questions is intrinsically tied to mastery-building

Asking Great Questions [Part 21] - Follow The Golden Rule

There is no free lunch, and this is certainly the case when it comes to asking favors. Favors in the tech industry are often harder to get as well given that they're higher leverage: A strong referral or a 1 on 1 meeting could easily be worth +$100. This lesson teaches you:

- What it means to follow the golden rule with your favor request question, explained with an in-depth example
- How to share equivalent value with 3 common favors that software engineers ask for
- A simple 3-step process you can use to add value to anyone and make them want to help you more, particularly when you can't return equivalent value

Asking Great Questions [Part 20] - Make Fulfillment Easy

In order to get what you want, you need to know *exactly* what you want. This can be harder than many engineers realize. This lesson teaches you:

- The importance of reducing fulfillment friction, presented through the perspective of the person fulfilling the favor
- What it means to make fulfillment of your favor easy, shown with an in-depth example covering a common engineering ask
- How the spectrum behind fulfillment friction reduction is actually incredibly deep, especially if you're creative
- Ideas to make fulfillment easier with examples covering 3 more very commonly asked for favors

Asking Great Questions [Part 19] - Give Them An Out

Most engineering favors don't get fulfilled. If you're cognizant of that and incorporate it into your question, you can counterintuitively *increase* your chances of getting the favor. This lesson teaches you:

- Why making it easy for your favor to be turned down increases your standing with the person you're asking for a favor from
- What it means to give the helper an out with your question, explained with an in-depth example

Asking Great Questions [Part 18] - Put Them On A Pedestal

If you are asking someone for a favor, they are almost certainly special in some way. This means that they're probably getting asked for favors from many, many people besides you. So how can you stand out? This lesson teaches you:

- An easy and free way to make your favor request stand out
- Why putting someone on a pedestal is so powerful
- What it means to put someone on a pedestal in your question, explained with an in-depth example

Asking Great Questions [Part 17] - Target Domain Experts

A big part of getting great answers quickly is to ask the right people, especially with technical questions as different engineers specialize in different things. This lesson teaches you:

- Why targeting makes it more likely for your question to be answered
- What it looks like when you target domain experts in your question, explained with an in-depth example
- How to find domain experts to tag in your questions

Asking Great Questions [Part 16] - Attaching The Code

Code is heavy, especially when viewed outside the context of an IDE or code review platform like GitHub. It's critical to keep this in mind when you're asking questions about your code. This lesson teaches you:

- The most common failure mode when it comes to attaching code to questions
- What it means to gracefully attach code to your question, explained with an in-depth example
- A trick you can use to share a lot of code without overwhelming your question

To learn how to isolate relevant code, take our debugging masterclass: [\[Masterclass\] How To Become A Debugging Master And Fix Issues Faster](https://www.jointaro.com/lesson/ioR6WzamAIUTpySLAr7o/masterclass-how-to-become-a-debugging-master-and-fix-issues-faster/)

Asking Great Questions [Part 15] - RFC Pull Requests

As a software engineer, you're inevitably going to have to ask a lot of questions about your code. This lesson teaches you:

- A natural tactic you can use to share code context with engineers you want to help you
- What a quality RFC pull request looks like, shown with an in-depth GitHub example
- Why pull requests are so powerful and organic when it comes to attaching technical context 

Level up your code quality here: [\[Course\] Level Up Your Code Quality As A Software Engineer](https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/)

Asking Great Questions [Part 14] - What Have You Tried?

If you don't do it right, asking questions can seriously damage your reputation among the team and mark you as a low-performer. This lesson teaches you:

- Why engineers in particular are extremely allergic to low-quality questions
- How low-quality questions can put you in the target of a PIP (performance improvement plan)
- A simple way to identify if a question is low-quality or high-quality based on its overall vibe
- 3 core tactics you should try if possible before asking a question
- What it means to masterfully incorporate what you've tried into a question, explained with an incredibly in-depth example

Asking Great Questions [Part 13] - Please Don't Do This: Leading Hello

A lot of what we're taught growing up doesn't translate very well into the software engineering world, and how we greet people is one of those things. This lesson teaches you:

- Why a standard solitary "Hello" or "Hi" is a terrible way to get help digitally
- What being polite actually means in the engineering world
- What you should do instead of leading hello

If you want to join the cause of "No Hello": [https://nohello.net/](https://nohello.net/en/)

Asking Great Questions [Part 12] - Length Balancing

One of the most important attributes of a question is its length, and the reason why is simple: The length of a question is directly connected to how much time a helper needs to spend answering it. This lesson teaches you:

- Why questions that are too short are bad
- Why questions that are too long are bad
- What to do if your question seems too short
- What to do if your question seems too long
- What a healthy question length is, demonstrated with a real-world example
- A tactic you can use to keep the length of your question in-check while still including a lot of important context

Asking Great Questions [Part 11] - Avoid Question Ping Pong

If you want better answers faster on your question, the goal is simple: *Make it dead simple to answer your question*. But how do we do that? This lesson teaches you:

- A simple mental framework you can apply to your question to understand if it's good
- What a bad question looks like when it violates that mental framework
- How to use that mental framework to determine the quality of a question

Asking Great Questions [Part 10] - Put Yourself On The Line

When you ask a question, you are asking some human(s) out there to spend some time providing you with an answer. To make this process go better, you must do everything you can to prevent the interaction from being one-sided in the wrong direction. This lesson teaches you:

- How to swap the time dynamics behind a question in your favor
- What it looks like to offer your time within a question, explained with an in-depth example
- When and how to take the more extreme route of offering synchronous time, explained with an in-depth example

Asking Great Questions [Part 9] - Be Appreciative

The people who give the best help often have some degree of altruism. When you learn how to appeal to that altruism, you supercharge your chances of getting great answers quickly on your questions. This lesson teaches you:

- How many engineers view showing appreciation incorrectly, seeing it as a transactional action instead of a proactive action
- When to show appreciation proactively
- What it looks like weaving appreciation into your question, explained with an in-depth example
- A lazy way of showing "appreciation" that you should definitely avoid by spending an extra 10 seconds

Asking Great Questions [Part 8] - Explain The Impact

Every great software engineer faces the perpetual problem of *"Too much to do, not enough time"*. Great software engineers are who you want answering your questions, and you need to make a case as to why they should use some of their time to answer your question. This lesson teaches you:

- How to empathize with helpers when it comes to how they choose who to help
- Why showing the impact of your question is critical, especially at high-performance tech companies like FAANG
- What attaching the business impact to your question looks like, explained with an in-depth example
- A bonus type of impact you can illustrate with your question

Asking Great Questions [Part 7] - Diversify Your Asks

It is tempting to stick with what you know. When it comes to asking questions, this means asking the same person again and again after they have helped you before. However, this isn't the way to go when it comes to your growth. This lesson teaches you:

- How repeatedly getting help from just 1 person can strain your relationship with them
- The tech industry-specific danger of only having 1 person to answer your questions
- The tactical survival benefit of diversifying the pool of people you ask questions to
- How getting help from a lot of people builds up a huge career asset with long-term social capital, which is crucial for more senior engineers

Asking Great Questions [Part 6] - Be Clueless In Public

The best software engineers are those who embrace their lack of knowledge. This lesson teaches you:

- Why it's better to ask your question in a broader audience
- The difference levels of visibility when asking a question with higher being better
- A huge, often unknown benefit that comes with asking questions in public which allows even junior engineers to become leaders
- Why you should always try to create a record of your question and its answer(s)

Asking Great Questions [Part 5] - Figure It Out Or Get Help?

As a software engineer, you need to figure out a lot of things on your own (that's why you get paid the big bucks). However, you don't want to go the extreme where you endlessly run yourself into a wall by not getting help. This lesson teaches you:

- When to figure it out on your own vs. get help
- The dynamic behind solving complex engineering problems
- How to identify if you're stuck
- When to ask for help earlier instead of later

Asking Great Questions [Part 4] - Make Questions Your Superpower

Many engineers see asking questions as a sign of weakness, which is why they don't do it. What these engineers don't realize is that if you do it properly, asking questions can actually become your *strength*. This lesson teaches you:

- The different levels of skill when it comes to asking questions
- The *massive* career benefits you can get when your question asking skills are truly top-notch, particularly around mentorship
- How expertly crafted questions build up your trust and reputation

To learn more about how to attract the best tech mentors: ["How does one attract a sponsor who is invested in their growth?"](https://www.jointaro.com/question/pRX7I8QC5YPOEDNX5q87/how-does-one-attract-a-sponsor-who-is-invested-in-their-growth/)

Asking Great Questions [Part 3] - The Key Behind Questions That Don't Suck

There are good questions, and there are bad questions. One of the main ways to thrive as a software engineer is quite simple: *Ask **good** questions*. So how do we do that? This lesson teaches you:

- The key concept behind asking a truly good question
- Why empathy is an engineering superpower in general
- The concrete way to identify a bad question
- The concrete way to identify a good question

Tech Career Growth Videos

Our instructional videos provide software engineers with insights needed for career growth. Masterclasses go incredibly in-depth on a specific tech topic while case studies are real examples from established engineering leaders.