57

So, I just started an internship, and I'm worried that I'm asking too many questions. My mentor assigns me projects and helps me learn all the company's technologies and methodologies. However, there's so much new material for me to learn while doing this project that I have a lot of questions. I generally ask questions over instant messages or E-mail (those are the primary modes of communication for my company).

I'm trying to be careful not to ask too many questions: I don't want to come off as annoying or dumb. How many questions are appropriate to ask? Once an hour? More? Less? Keep in mind, my mentor is also a fellow programmer who has his own responsibilities.

4
  • 13
    I think it's less about how many but more about "when". If I'm available, feel free. If I'm busy, ask in a later time or to someone else. It's only annoying if you stop thinking on your own and just keep asking everything: always do your own research before asking!
    – Vitor Py
    Jun 16, 2011 at 4:02
  • 14
    You could always just ask your mentor how they prefer things. They will give you a better answer than we can. Jun 16, 2011 at 4:13
  • 1
    I think it's grammatically correct either way. Rephrase it as a statement and not a question: It is appropriate to ask n questions per day. Or: n questions are appropriate to ask, each day. The second one sounds more awkward in non-question form, but I'm pretty sure both are correct.
    – Tyler
    Oct 3, 2011 at 4:23
  • possible duplicate of What should I expect from my first programming job? Feb 7, 2012 at 2:38

11 Answers 11

99

Be respectful of your mentor's time by keeping a list of questions and asking them in batches, to the extent possible. Don't actually interrupt your mentor until you literally cannot make any forward progress without help.

A lot of times you'll learn a lot by struggling to find the answer yourself, even in cases where your mentor can teach you something in 10 seconds. For example, if you want to know where something is in the code, you can ask them (10 seconds), or you can spend four hours studying the code and trying to figure it out yourself. The advantage of the "four hour" option is that you will actually be learning 200 new things about the code, all of which will help you later on. Struggling to find your own answers can be a waste of time, but it can also be a way to learn a big complicated code base.

Needless to say if it's a programming question that doesn't concern your company's own proprietary code, you should try to figure it out yourself using the internet.

5
  • 4
    Thanks for the suggestions! I definitely like the batches idea and will give that a shot. However, given my company's instant messaging culture, I wonder if it might be a little weird to fire 5 questions at him at once. I also like the "4 hours" idea (I definitely went through some of that today and learned a lot about their software). The only problem with the "4 hours" idea is that he told me he'd like me to have a project done by the end of the week. Since this is my first project, I definitely don't want to miss this deadline! Jun 16, 2011 at 4:07
  • 1
    +1 Nothing gonna be better than this
    – V4Vendetta
    Jun 16, 2011 at 5:00
  • 1
    That is something that I'm trying to explain to my new hires, when they complain that they are stuck and frustrated, that I prefer that they would investigate on their own for an hour or two, and only then come to me for help, rather than me pointing at the file and solving their problem in 5 mins, exactly because they will learn a great deal more about the application on their own.
    – Miki Watts
    Jun 16, 2011 at 10:58
  • +1 For advocating self-improvement over merely getting by Jun 16, 2011 at 16:42
  • @Casey Patton: If he's experienced with interns, he likely added time for you to research yourself and ask questions to the factor of when he wants the product done. Where I work, it's not unusual to give an intern an early project and expect them to take a week what someone familiar with the code could do in a couple of hours. You just simply cannot be as productive before you've learned the codebase, and that takes time. Jun 16, 2011 at 21:42
29

As a senior who has seen juniors asking all kinds of questions, I would say it's not a matter of how often you ask, but what you ask.

You need to feel it yourself, but generally the rule is: Show your interest and ability to think and work independently.

It's OK to ask general questions to set context for the low-level detail investigation that you do yourself.

It's OK to ask questions about everything that is not code and is not documented - the process, team culture etc.

Whatever you do, show that you put some thought to it and made an effort to understand or solve the problem yourself.

Don't be afraid to ask though! You can use it to show interest and deeper thinking, as well as spare the team some pain by not following their practices or making inappropriate decisions that will require time to disentangle later.

Just do not cross the line and ask them to code for you, tell you exactly what to do every time, explain syntax and copy documentation, and so on.

6

I think a lot of the answers given so far are right on the point: don't be afraid to ask questions (that's what internships are for, after all), but make it clear that you have tried to find the answer yourself before asking. I for one don't mind questions at all, but I do mind questions where it's clear that the person asking is asking only because it's more convenient for them to interrupt someone else. It's okay to come with a simple question if you've tried, as long as it doesn't happen too often, but it's not okay to not even try for yourself first. And even with simple questions, have both a simplified case and the gory details ready. Think SSCCE - Short, Self Contained, Correct/Compilable Example. I had someone stop by and start asking about dynamic SQL, when the real question was about extracting data from code executed through a SQL EXEC. That's a pretty big difference.

Another point to consider: can you use e-mail, or some other non- (or less) intrusive form of communication for some of your questions? Then, your mentor can either reply by e-mail or (more likely) stop by at your desk to discuss things when they get a chance. This also goes with the "batching up questions" advice already given, but I personally find it easier to deal with a single question per e-mail message, than a long list of questions that have little or nothing to do with each other all lumped together into one message. One can often be answered in a minute or two, the other can very easily become a half-hour timesink.

5

I wouldn't worry too much about asking (too many) questions. A good mentor will tell you in a friendly way when it is time to stop asking and start practicing. After all, the mentor was assigned to mentoring you and this assignment usually comes with a time budget.

I agree that it is a good idea to prepare a batch of questions and ask for the mentor's attention to discuss them all in one go. On the other hand, it can also be very frustrating (especially for beginners) to try to figure out how stuff works for hours when a simple question and answer would literally settle the issue within seconds.

Try to learn from experience and develop the skill to "read" your mentor to figure out when there is a good opportunity and how you should communicate your want of attention. Software development is as much about interacting with people as it is about staring at source code.

On a related note, encouragement and enthusiasm works in both ways, from mentor to intern and from intern to mentor.

4

This is probably a situation that we have all been through. Being the new guy, whether it's an intern or a regular employee is tricky. It always involves the cold-start problem, since you are in a new place, with new people, new technologies, new methodologies. I totally understand the anxiety of not knowing something and wanting to get to know it perfectly, so that you soon become productive.

Having questions is totally natural. And you can be certain that your colleagues know that you do and will have questions. They've also been at your position at some point, right? And believe me, they HAD to get some help from somewhere.

The tricky part is that not everyone is available at all times, to answer any of the questions you might have. My usual trick when going through code or documents, is keeping notes of things that are not immediately clear, and arranging a couple of short meetings per day, to discuss them with my seniors. Before asking a questions, it's always a good idea to make a small 'research' about it, try to get as many information and hints as possible. Sites like StackOverflow are gold. You might even get the exact answer you are looking for. Your colleagues will appreciate the effort, and will be more happy to help you.

Try hard, study hard, be curious, and ask questions. Remember, everyone has been in your position, and everyone eventually survived :)

4

I am pretty much in your exact situation at this very moment. My supervisor is quite busy and I picked up on my interruptions not being very welcomed quite early. In my case though, I came in not knowing a lot of technologies used. So what I have done is, every time I have a question, I jot it down. If I need an answer to continue my task, I do something else for a while. I read some documentation for some other technology that I know I will use soon enough. Unless the question is critical to complete the task I must be working on, and I can't continue without an answer, I queue it.

If it's code you're writing for example, you can write a comment "todo" in that part and continue writing the rest of the code. You can go back to fill in the todo later.

Then, whenever I meet with my supervisor I unload all questions at once. By then some of the questions I have already answered for myself! Some of the questions also seem dumb after it being written down for a while, so you don't ask them.

Another thing you definitely should do is simply to talk to your mentor about it. In fact that's the first thing I did. I simply straight up asked "Am I asking too many questions?" It gave me straight-forward feedback and I could stop worrying about if and either relax or resolve the issue.


Note: The above only really applies for questions that are not technical or programming related. I spend a long time in Google / Stack Overflow searching for technical answers and you should too. In fact, if you're not googling new information everyday I would almost say you're not learning enough :)

3

I think you are going to run into different types of questions.

For my response I will focus on what I consider WHY questions. These types of questions help you understand why you are being asked to do something a certain way. (ex. Why do we use coding standard X?)

I think it would be good for you to ask your mentor to set aside some time each week to go through these kinds of questions. One idea would be to set aside 1 to 2 coffee breaks a week. By having a set time for these types of questions you show your mentor that you value their time and that you wish to learn why something is done a certain way.

3

As long as you mentor knows that you have tried to find the answer first and tried to find a answer to the question.

A tip when to ask question can be when your mentor goes to the coffee machine, then you know that you are interrupting his "flow".

2
  1. Don't worry about asking too much. No matter that you don't know sth, but capability of studying matters.
  2. Think and Google before you ask.
  3. Since you communicate by IM and E-mail, try to make sure that your mentor understands your questions well.
  4. Once a problem is solved, notes are necessary. We just can't remember everything we learn in detail.
0

I think Casey it is not the matter of questioning..thing is that you are an intern.. you are suppose to ask questions. And personally i feel questioning things is always has its own benefit. Even if you don’t Google in that case your mentor should tell you that you need to study that on your own. Point to remember that don’t get frustrated or don’t be overwhelmed by new work environment with huge code base. It s just time you need to give and should question pretty much everything you want.

happy questioning :):)

0

You know, if you are polite and cheery you can ask ask ask away.

But don't ask those questions that sound defeatist or imply you may be lackadaisical,

Not the answer you're looking for? Browse other questions tagged or ask your own question.