How to Ask Senior Engineers Good Questions

Asking questions? Easy peazy, right? Right. But let's sketch out a rough analysis to see if it's worth investing the energy to make sure. We'll make these few assumptions,

• Asking questions is indeed a skill, mastery of which will return some value to a career

• It's fairly easy to master

• It's a fairly often ignored skill

Given that, it makes sense that there's some advantage to be had by anyone who chooses to practice this skill over engineers who ignore it. Specifically, an advantage that engineers are notorious for lacking - strong communication. If it's easy, and it gives you a leg up, why not?

Have you ever heard that phrase and wondered what it actually meant? Communication skills - fluff and buzz words, right?Nope. It's real. And in case you're as lost as I was on what that really entails, I'll make it explicit. In part, it means consistently having productive conversations with other engineers and non engineering employees, perhaps by asking really strong questions in a thoughtful, systematic way...

The value of having a few strong comms moves, like asking really good questions, in your back pocket to help get your point across can't be overstated. Especially as companies are WFH and our interactions are limited to Zoom or Hangouts or Slack. Getting face to face time with senior engineers is hard enough and rare enough for many and that's only amplified now. So, it's worth having our ducks in rows before beginning those interactions.

The Ducks

When you're new - new to the stack, the business, or new in general - and you're hitting a wall it's super wise to ask for help. You'll learn the lesson either way, and you'll keep the ball moving on your task and your team's goals. But of course there are a couple of things to do first.

Try
Seniors want to see evidence of a struggling attempt.

How do I know? In the time before COVID I sat immediately next to my manager. He has been and still is extremely helpful. But because of our proximity and his helpful nature asking questions became my crutch. I'd hit a tiny road-bump, lean over and ask. Needless to say this wasn't good for my development, or for his stress levels. He didn't enjoy being asked about every tiny problem (who would) and it became a minor annoyance that had the potential to cascade into a perception problem for me. Luckily, he corrected it. One day, I asked a question, once again out of convenience more than out of frustration. He looked very intently at me and said, "I don't know. Is that what the documentation says." Notice the lack of a question mark. I read between the lines, hence the inspiration for this post.

Anyway, It won't be difficult for veterans to glean the level of effort you've made. They've been through it themselves or have guided others through it before. Elon Musk said about his hiring practices,

Usually, someone who really had to struggle with a problem, they really understand it and they don’t forget.

This is true even for small, new-engineer problems, and effort expended will be obvious. So, be ready with

• a clear explanation of your goal

• a clear understanding of what you've tried so far

• a clear understanding of why you thought those ideas might be a solution

It's wise to write these down (maybe before you attempt the solutions actually), since it takes all of 30 seconds and helps refine and crystallize your thoughts. This is an opportunity to turn asking for help into demonstrating a diligent thought process. Part of great team communication getting on the same wavelength as the other engineers and that is done by understanding their thought process and by being understood. It's worth the effort.

Check the docs
Documentation is a pain point for most engineering orgs (or so I hear, I've only been at one) and yet it's a pre-requisite to operating autonomously. Engineering teams live and scale by their ability to work autonomously. If engineers had to take time to explain everything they've done to one another it would take almost as long as everyone figuring it out for themselves. Good documentation is a huge unlock. It unlocks autonomy, speed, and reliability. Some great engineering companies do documentation really really well and it's a huge, proven benefit.

A new face on the team is the best stress test for documentation. Finding and filling gaps in those docs is real value that new engineers are especially well positioned to unlock, to the benefit of everyone else.

And if the answer to the problem at hand isn't there then maybe there's a hint. And if there's no hint then we know it for sure.

Know your question
So there's only one major faux pas I know of when it comes to asking questions. All of the above is additive and makes you better, but I suppose it's not necessary. The one item that is necessary is a question.

And yet plenty of teachers, senior engineers, and other managers are hit with a vague "I don't understand this.", or "I'm not sure where I'm going wrong, can you help me?" all the time. This is where help-me-help-you comes into play. A clear, specific question, or several, that attempts to remove ambiguity from the conversation can be handled easily by answering the question(s). A vague statement about being lost requires the helper to retrace everything you've already done - to find you before they can give you direction. No one enjoys coaxing words out of anyone else. It wastes time, energy, and costs you some reputation. In short, it's not cool to walk into a conversation only to introduce more ambiguity by stating that you don't even know what you should be asking. It can always be narrowed down. At worst, "What specific step should I look into next to get me going? Why?"

A Small Utility

I read great articles filled with golden nuggets of wisdom pretty often. But I forget that wisdom just as often. It has made me elevate my standard for what I consider "knowing something". It should be harder to forget a lesson that I really, truly knew. Understanding an idea is easy. Most people who can read or listen can understand an idea. Now, I don't consider a lesson learned until I've put it into practice. To that end I often create small templates that guide my adherence to whatever idea or lesson I'm trying to master (don't underestimate the power of boilerplate). Here's the template for how to ask good questions. When I started using it I'd fill it out completely. Now I get by with glancing at it before asking. Hope it helps.

Ask Good Questions

I'm trying to (1)[accomplish this specific goal], but I'm hitting a wall when (2)[attempting to complete this step]. Have a few to help me through it? (3)[Maybe some chatter or syncing of calendars] I tried (4)[my first approach] thinking it would (5)[work for these reasons].

1. Important to show you understand the goal and to give the helper context from which to reason
2. Identifies the specific problem
3. Whatever happens here it's wise to remember where you left off, to estimate if 1 and 2 were received or if you need to repeat, and to continue with 4
4. A chance to show my thought process
5. In order to vet the assumptions I made when deciding on 4

INIT CAREER is a my small newsletter about starting a career in software engineering. The first series, What I Learned This Week as a New Engineer, focuses on the less technical stuff.