As an intern, how can I ask for real work?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.