TL;DR — My question is... how do I learn to ask the right questions? 😂
Hi everyone! I'm hoping this question doesn't sound too basic/vague but it's definitely something that brings me anxiety in my brand new job search.
I recently graduated from a coding bootcamp and now I'm beginning my job search! I haven't even applied anywhere yet but one thing I'm struggling with is the concept of asking questions as a junior developer on the job (wherever it winds up being!)
I recently attended a few workshops aimed at helping early-career devs interview and approach the first six months of their new job. One thing that was stressed over and over again was the concept of "asking good questions", especially during paired programming.
Now that I'm ready to actually start interviewing, I'm realizing that I don't know the first thing about how to ask good questions to my more senior colleagues.
I'd love to know if anyone has some pointers for how to ask efficient, "good" questions while I'm ramping up.
I'm assuming this is a skill that will be evident to interviewers, too so I want to make sure I have my head wrapped around it before applying anywhere. Thank you in advance!
Oldest comments (4)
This is a great question!
Here's how I ask questions. Quick aside, I definitely struggle with "when" to ask questions. I'm starting to lean towards asking the question earlier rather than later. But let's get into the how!
Just ask the question!
This is especially true for an async environment. Rather than asking "hey can you answer this question" and waiting for a reply. Post the question and let others answer it. If you're in an in-person environment, it might be better asking if the person has time to answer a question first. But you'll be able to see if they're focusing hard on something.
Question structure
Try to structure your question with here's where I'm stuck, here's what I did, what do I need to do to get unstuck.
You want to have done some research on the topic before asking the question. The amount of research is very dependent on what you're working on. If you're new to a codebase, it's okay to not have too much detail in the question. You're still trying to figure out how things work. But it's important to try to answer the question yourself beforehand. Doing so will get your brain primed for the answer by your co-worker - which in terms helps you retain that information better.
Also, doing your research could highlight some outdated documentation that you can fix and make an immediate impact to the team!
Rubber duck
I've been in situations where I've wanted to ask the "perfect" question. I felt this way because the team was busy and I didn't want to interrupt them.
First off, you should ask anyway! Getting unblocked is better than being stuck for hours or days on end.
Secondly, it might be worth rubber ducking the question first. Try to explain it to a rubber duck, or dog, or child. Someone who doesn't understand your context. Make the explanation as simple as possible. Slowly step through your problem. Going through this process can help you polish the question you want to ask. Or you might find the solution!
Interview questions
Interview questions are a bit of a different beast. You still want to follow the question structure. But the "what do I need to do to get unstuck" will be replaced by "what am I looking for?". Ask questions that relate to your values. For example, you might care less about the product than you do about teamwork.
There's a bank of generic questions that people ask like "what is your day to day", "what are some challenges you have" etc. While these questions aren't bad, try to put your own spin on it. Pull in supporting evidence if you can. E.g. instead of "what are some challenges", you can say "I looked on linkedin and it looks like you're scaling their engineering team, what have been some of the problems you've had with team growth, and how are you addressing them?"
Hopefully, these tips helped!
Oh man, this is SO helpful Jonathan. Thank you so much. I really like the tip of "rubberducking" before asking questions — and also structuring my questions so that they are easier to answer for the recipient. Thank you, Jonathan!
Anytime, glad I could help!!
Hi guys,
I thought Jonathan gave a great response.
There are several things I would like to add (or re-iterate, lol).
When people say, 'Ask good questions' to me it means;
Do some homework on the company. It sounds cliche, I know, but it's true.
Do more than going to the company website and read the public relations piece for investors. See if you can find out what technology the company is focused on. For example, If the company uses NoSQL and SQL read up on the topics!
Don't go in and say; I heard this is a cool company. lol, Ya'know.... ;)
I have been reading StackOverflow recently. I have learned something about good/bad questions.
A. Some people post huge error messages without even giving it a quick read! Some people give up too early. Stop, Read and Think, even for a second. ;)
B. Other people blurt out a question too quickly. How about going to the docs first and spend some time on them. Then if the docs don't make sense say so. Being intelligent is also knowing Where to find info.
C. The third point, a good question, gets to the point Quickly. Others do Not want to know the history of your project. Ask your question concisely.
You may say this is garbage and Not related to interview questions. There is overlap. When I interviewed people, I liked to see people think rather than blurt out a Wrong answer quickly. Stop for a moment, breathe & think. It's ok to pause and have dead air. You have learned how to use a hammer (or program). Now, what can you make/build with that hammer?
HTH
P.S. It is ok to say; I don't know. Just use it wisely.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.