As a new engineer, you’ll ask tons of questions. Mentors want you to succeed, but providing quality mentorship is difficult and time-consuming. If you can meet them partway in getting you the help you need, they’ll love working with you.

Here are 3 things to keep in mind when you ask questions:

1. Start with the problem
2. Show your work
3. Think it through yourself

We’ll go through each one and talk through a scenario where you ask a suboptimal question, what you could do to improve it, and example conversations before and after applying the improvement!

Start with the problem

Scenario

You need to get the path from the URL of the page the user is on.

You know how to get the full URL: window.location.href, e.g. https://yourcompany.com/widgets/127, and you want /widgets/127. You’ve heard regular expressions might be a good way to deal with this.

You ask your mentor: “How do I write a regular expression to match the /widgets/127 in https://yourcompany.com/widgets/127?”

Improvement

This regular expression is both hard to write and not what you’re looking for. You’re trying to get the path from the page you’re currently on, so that’s what you should ask about.

It turns out there’s a straightforward solution: window.location.pathname, something your mentor could’ve steered you towards if they knew the exact problem you were dealing with.

This misdirection has a name, the XY problem:

1. You run into a problem
2. You come up with your own solution
3. You ask how to accomplish your solution

When starting out, you won’t have the breadth of experience to know if the solution you came up with is optimal. So don’t start with your solution; start with the problem.

Your mentor might appreciate that you came up with your own solution, so it doesn’t hurt to include it when you ask the question. Just make sure you include the problem too.

Examples

Before

You: How do I write a regular expression to get the /widgets/127 part of a string like https://yourcompany.com/widgets/127?
Them: Hmm that’s tricky, I might need to play around with it.
Them: (A few minutes later) You could try something like string.slice(3).join(‘/’).
You: That works, thanks!
Them: What are you trying to do?
You: Get the path of the current page the user is on
Them: Oh! You should use window.current.pathname instead

After

You: I’m trying to get the path of the current page the user is on. How do I write a regular expression to get the /widgets/127 part of a string like https://yourcompany.com/widgets/127?
Them: Oh, you don’t need regular expressions, you can use window.current.pathname

Show your work

Scenario

You need to query some data from the backend and render it to the page.

It’s not working: the page is blank. You tell your mentor: “I can’t get this data to render. I’m stuck”.

Improvement

If you start with a vague problem statement like “It’s not working”, you’re guaranteeing your mentor will need to dig to figure out what’s going on.

This tip ties into a general principle about being a good communicator: minimize the amount of back and forth needed to resolve your issue. This principle applies even moreso in async communication like Slack, but it’s helpful even in person.

A better way to phrase the question “X isn’t working” is “X isn’t working. I’ve tried W, Y, and Z. I think it might be because Q. What do you think?”

Examples

Before

You: My data isn’t showing up on the page, I’m stuck!
Them: What are you seeing?
You: The data’s not rendering onto the page
Them: Can you try logging the data variable on this page?
You: Already did, it’s null
Them: Did you check your browser console?
You: Already did, no errors
Them: Did you check your server log output?
You: No, how do I do that?
Them: Look at the terminal you’re running your backend in
You: Oh, I see an error there. I’m having trouble reading it though, can you help? [Pastes error]

After

You: My data isn’t showing up on the page, I’m stuck! I logged the variable data on the frontend. It’s null. I also checked the browser console and there are no errors. Seems like the data might not be coming back from the backend, but not sure. Any ideas?
Them: Did you check your server log output?
You: No, how do I do that?
Them: Look at the terminal you’re running your backend in
You: Oh, I see an error there. I’m having trouble reading it though, can you help? [Pastes error]

Note: you still didn’t need to know how to check the server log output or read the error message. This isn’t about knowing more: it’s just about telling your mentor what you already tried.

Think it through yourself

Scenario

You’ve built a new page to filter and display users of your app.

It’s one complicated gigantic React component right now, and you suspect it makes sense to break up into smaller sub-components. You ask your mentor: “How can I break this component up?”

Improvement

The question “How can I break this component up?” is a great question to ask your mentor. Eventually.

Before you do, stop and think through it yourself. There are two key benefits to doing so. First, you’ll demonstrate your initiative to your mentor. Always a plus.

More importantly, you’ll have something to compare your mentor’s approach against. Presumably you’re trying to learn how to think like your mentor. It’s much easier to compare your thinking with theirs and figure out where yours diverged vs. learning how to think like them from scratch.

Examples

Before

You: Done with this feature! It’s one huge component. How do you think I should break it up?

After

You: Done with this feature! It’s one huge component. I’m planning to break it up. The filters definitely feel complex enough to be their own component. Not sure what else though, maybe each card displaying a user? What do you think?

Again, the goal is not to figure out the answer on your own! It’s all about trying and communicating your attempt.

Wrap up

In many of these examples, the outcome will likely be the same, but the process of getting there will be a lot smoother. Communication is tiring. Mentors will appreciate any effort you put into reduce the energy required.

Asking good questions is a skill that you can develop, one that’s worth the effort, even as you move out of the new engineer stage. You’ll be asking questions your whole career, whether you’re talking to engineers, designers, product managers, or other stakeholders. Let your mentor know this is something you’re working on.

Thanks for reading! If you have any follow-up questions or would like to connect with me, feel free to do so on my Twitter, or leave a reply below. Happy asking!

This article was originally published on my blog. Check it out if you’re interested in my older and more personal writings as well!