Asking Technical Questions


Prepare to Engage

Whether you are starting your day with this activity or wrapping up a long day of technical work with this, take a moment to ground yourself in why you became a student at Turing. This Career Development work is arguably the most valuable component of your education that will lead you into your new career.

Take a moment to reset if needed, meditate, or do some physical stretches/movement to get yourself into the space you need to be in to engage in this work. Some optional guiding questions follow.

  • Why did you come to Turing?
  • What is the thing that will motivate you to keep going on the days/weeks you feel most challenged at Turing?

Asking technical questions may seem so easy when one is a beginner - “I know so little, how could I NOT have questions?” However, effectively asking questions is a skill. It takes a lot longer than you expect to write a good question, but you’re guaranteed to get a better answer when you ask a better question. How a developer asks questions communications a lot about their overall effectiveness. This skill will be essential in your success - not just at Turing, but on the job hunt and on the job. During your time at Turing, you will continue to hone this skill.

Best Practices

Information to include in every question:

  1. What were you trying to do?
  2. What were you expecting to happen?
  3. What happened instead?
  4. What have you attempted/googled/read to find a solution?

Your goal is probably to get an answer ASAP, and a secondary goal should be to document this issue/challenge to help someone who may encounter the same thing in the future. Formatting your question well supports both of these goals. Some things to consider:

  • Code snippets should not be formatted as plain text. Very short snippets should be formatted as inline code and …
    longer snippets 
    should be formatted 
    in code blocks.
  • Screenshots of Terminal output are usually helpful (if Terminal output is relevant).
  • A wall of text isn’t something most people want to read. If you have a lot of context to provide, give a TL;DR in the main channel, then thread your details in manageable chunks. Another strategy is to use bold text and/or emojis strategically to highlight key information or questions.

Examples and Non-Examples

Robyn & Arrays

The question that follows, from Robyn, isn't specific and puts a lot of work on the people potentially answering the question. Not only will people not completely know how to answer this question, the answers also won't help Robyn's learning much. If an employer saw a question like this from Robyn, they'd learn that they aren't resourceful and don't communicate their needs well. An employer might conclude that Robyn will be a costly employee who won't contribute much.

Bad Question 1

After receiving some feedback, Robyn re-wrote their question. They provided a code snippet, shared the error message in their Terminal, and told the group what they'd tried. This question is quite easy for someone to read and answer quickly, demonstrating Robyn is an effective communicator in a technical environment.

Good Question 1

Kaitlyn & Homework Help

Kaitlyn's initial question for help on her homework puts a big demand on the reader, and probably doesn't set her up to learn a lot. Most companies prefer asynchronous communication until live communication is necessary; seeing that Kaitlyn isn't communicating a clear question in writing could be a flag that she won't work independently.

Bad Question 2

After she didn't get any responses, Kaitlyn DMed her instructor, who gave her some feedback about why she likely didn't get responses. She re-wrote her post to make a specific ask, demonstrating she did her due diligence to learn a concept but wanted to confirm her understanding. This type of message demonstrates that Kaitlyn can problem-solve and communicate her needs for technical support.

Good Question 2

Asking Questions

As you prepare to ask questions—in written form or in live communications—think about how you can best present the necessary information to get your question answered and to demonstrate that your are an effective communicator in a technical environment. Things to be prepared for, and ok with:

  • It’s not always easy to write up a question. It might take several minutes to find the words to describe the scenario. Part of the job as a developer is asking questions, so it’s ok to take time on it. Budget this into your time estimates for projects and work.
  • This usually prompts what we call “rubber ducking”—or talking through the problem to yourself or an inanimate object. The act of talking or writing through the 4 components of a good question will often help you answer it yourself. In that case, it’s definitely something to celebrate and not a waste of time. If you didn’t answer the question yourself and still need to ask, that’s ok too!

Check For Understanding

You won’t submit anything in the submission form for this topic; but you will be asked to ask at least 1 question in your Slack small group daily (or, if not necessary, share what challenge you had and how you overcame it). And, you’ll be asked to reflect on questions (asked by you and peers) in some of your reflection prompts. So, keep this in mind - come back to this document when you go to Slack to type of a question or keep a sticky note on your desk with the 4 best practices - whatever it takes to build a strong habit for yourself!