I'm currently a paid intern at a corporate company, and the only intern in my department. The team has been in the planning stages of a new project, so there hasn't been much I've been able to contribute since it's a big project with multiple 3rd party vendors. I go to all the department's meetings, even the all-days with consultants, but haven't gotten a chance to make something useful.

I've asked coworkers if they have anything I can do, and they've suggested learning about technologies they're using but haven't given any sort of task to complete. I've also looked through source code from the old project they're redesigning, but there was little to no documentation.

I've been learning a lot, but I feel guilty for not having anything to contribute since I'm being paid to work. The interns need to make a short presentation on what they've worked on, but the only things I can talk about are things other people in my department have accomplished. On the other hand, I'd feel equally guilty if my supervisor went out of his way to find some task that won't benefit anything.

I mentioned that I'm available to help anyone at the last scrum meeting and a coworker said she'd take me up on that, but I didn't see her for the rest of the day.

How can I find something useful to do?

  • Volunteer to takes notes, get coffee, pick up lunch. I know it is not what you are looking for but it is a start.
    – paparazzo
    Commented Jul 15, 2016 at 22:00
  • 3
    @Pete IANAL but that is not valid global statement. You don't even know the jurisdiction.
    – paparazzo
    Commented Jul 15, 2016 at 22:43
  • 2
    @Paparazzi other interns are working on actual projects, and at our orientation HR made it clear that this wouldn't be a "coffee grabber" internship, and that we were technically employees.
    – user53984
    Commented Jul 15, 2016 at 22:53
  • Then you need to be more like the interns working on projects and the fact that was not in the question explains the question.
    – paparazzo
    Commented Jul 15, 2016 at 23:02
  • @Paparazzi: That's a very good point; I was assuming USA, when I shouldn't have, and I apologize if it's somewhere else.
    – PeteCon
    Commented Jul 15, 2016 at 23:57

4 Answers 4


You have done everything you can do. You aren't hiding in a corner trying to avoid doing anything, you are upfront and asking for work, and if they don't have anything for you that is ok. Keep doing what you are doing, learning what their is to learn and making yourself available to jump in when needed.

When you looked through the source code for the old system were you able to understand it? Maybe that lack of documentation is a project that you can work on.

  • 1
    I was able to understand the smaller pieces and methods, but there was just too much to totally wrap my head around how it all worked together. Among many other things, the lack of documentation is a cause for the redesign that they intend to fix. I think I'm mostly nervous that I'm going to make a presentation to the CEO and execs saying that they've been paying me to read and follow some tutorials.
    – user53984
    Commented Jul 15, 2016 at 20:58

If you just want to write some code, check test coverage and improve it. It's rarely 100%. Javascript tests can be a good target as devs tend to write them less often.


As an intern, I struggled with the same things as you've mentioned above. Your first task is to get to know the workplace and environment better: Who's doing what in the team, what are their responsibilities, then you'll learn about the software they use, the projects they work on, etc. When you can manage these confidently, the "meaningful" work will come. While you're preparing for that, you'll be given tasks from your co-workers which might seem little to no use to the company: like doing small tasks, reading manuals, etc. However, if you view it from another perspective, you free up the department's timetable from the mandatory, yet not so productive tasks. When you gain enough experience doing these, another intern might come to take your place, and more importantly, you'll be given meaningful tasks, and projects. Do not worry about the presentation to your supervisor, your object is simple:

  • state what've done
  • then emphasize what you've accomplished with that.

Corporate companies have their "peak hours" and "downtimes". The latter is nearby lunchtime, after a meeting, and close to the end of the day. Use these times to talk to your co-workers about your concern. Try to ask as many questions about the ongoing projects as you can. Try to figure out if there are any discontinued projects, and why they were discontinued. You might pick up one of those.

You might try to tell your co-workers that you can learn these technologies better in use than in theory. I think there are some small tasks that can be done with these programs, and tools.

Reading codes all day is not so bad: you might notice things that any other, overbooked person might overlook while skimming these.


I'm assuming you aren't an intern anymore as this is almost 2 years later but I started out in a similar fashion only doing mundane user testing for our developers. Luckily one of them got me involved a few months later as I showed signs of being a competent and aspiring programmer. She needed a small program that did x to help her complete a task quicker and however I did it was up to me. After I did that, she gave me more and more little tasks but they involved our main system so I felt accomplished/beneficial.

In your case though, it seems you have reached out the best you could but taking an extra step on top of "learning their technologies" wouldn't hurt. Since you have access to source code, I would read/run the code (if possible, point to a testing db if needed) and familiarize yourself with the existing product, which probably will function similarly to the new one. Many, many of times, there is little to no documentation for code or other tasks involved in IT and you have to be able to work around that. If you cannot run it, try to break it down and write out what you think it does and ask one of them if that is what it does or google parts of the code to better your knowledge if nothing else for post graduation/job opportunities. That way eventually when you attend meetings and see what has been implemented you could be familiar and say, "oh, cool. Did you do this because x and y should do z? I noticed in the old code it works similarly." It would make you more involved and potentially gain rapport with them that you are able to add code in smaller less crucial sections of the new or existing products.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .