What are some good tasks to assign co-op students/interns? [closed]

Question

My company is investigating hiring a University Computer Science co-op student (BSc year 3) for a 4- or 8-month work term. (I'm not sure how internationally-recognized the term co-op is - it's essentially a paid internship, after which the student returns to their studies.) My team develops a web application in ASP.NET and handheld thick clients on iOS, BlackBerry, and Android.

For any of you that have brought interns into an experienced development team, what kind of tasks did you find for them to do? I realize that's a hard question to ask since any answer can be quite specific to an individual business.

I'd expect the following:

• Tasks that require mentoring but not babysitting
• Tasks that will take a few weeks to finish (so the mentor can remain productive)
• Tasks that expand the student's understanding of software development

I've considered things like expanding code coverage in our unit tests, or developing a feature that's been designed, or improving/writing missing requirements documentation from features that were added without any supporting documentation.

I never did an internship so I don't know what sort of tasks are valuable to both the student and the company. Any recommendations?

Edit: These are all excellent and thoughtful answers that have helped me a great deal. Thank you all very much. I can only choose one answer, so I'll go along with the crowd and accept the most popular one.

Answer 1

We used to have our co-op students work on internal tools that were not critical to the main application we delivered, but helped in areas such as build automation, making a complex dataset easily viewable in a web application, converting an internal HTML site to a dynamic (and easy-to-update!!) application. I think one co-op student once wrote a log viewer that made it easier to manage logs from one particular application that had a very verbose output. I think some co-op students also got assigned to the testing team, so I imagine they were writing and executing tests.

These applications were great for co-ops because the code-bases were small and easy to get into. Since the projects were only used internally on our team the students didn't have to go through lengthy processes to get approval for deployment and implementation. They got to make their own design decicions (with guidance from senior devs) and learnt quite a lot. Occasionally we'd give them simpler defects from the production applications, but only if there wasn't enough on internal tools area to keep them busy.

Answer 2

I'm going to have to say, it depends both on the co-op and how much time they will be with the company.

We employ co-ops here at my company that range from 4 month terms to 18 month terms. We often invite our co-ops back for another term as well.

You want to treat a co-op like a member of the team. Don't punt grunt work off on them if you can help it. It will not make an enjoyable term for them and could be wasting their skills.

To start off, they are like any other new employee, just without the extra work experience. What would you give a new hire their first week? Assume it will take the co-op two weeks to finish, with some extra guidance.

If they preform well on that task, see if you can give them something more. We have found here that if you give a co-op a task or ticket that is theirs, and make them apart of the team while working on it, it is often beneficial for the co-op and the company. We get actual work done and they learn a lot about how to work in the real world.

Don't throw a co-op at QA unless you hired them to be a QA. Nothing is worse for a co-op coming into a company thinking that they will be developing than to find out that they are just a tester. Unless you put in the posting that is what they will be doing, don't put them on that just b/c it's easy for you.

Of your ideas I would say "developing a feature that's been designed" would be the best one for a co-op. Test cases might work too, depending on the co-op.

At the end of the term, make them feel like they can look at something and say I did that, and I learned a lot doing it. Not, I spent 4 months writing documentation...I hated that place.

Answer 3

Small, completable, modular projects are, to me, the ideal. Something where they can see their project through from start to finish, but get the experience of working with something that will be part of a larger project, rather than just an example toy.

Answer 4

Testing and QA.

It will immerse them into software requirements, Agile development methodologies, writing test cases, working with developers, etc...

On the side though for the programming side of things I will sometimes assign an easy or unimportant feature and see how they do. Most of the time they mess up and then you try to teach them what they did wrong and how they can do it better next time.

Answer 5

I did an internship during my university days (for 14 months).

I was basically treated the same as all other full time members of staff. I was given similar tasks and I did pretty much the same work as everyone else.

It was exactly like I hoped it would be as I find I learn best when tossed in at the deep end.

If I had instead been given menial tasks or expected to just test other developers work I would not have enjoyed it and it would not have left me with a good impression.

Answer 6

I'm a current student of Computer Science, currently doing a 4-month co-op work term. After this term I will start my 3rd year of study, so I guess I'm a year under your target student audience. Regardless, I'd still like to share a little of my (and older acquaintances') experience.

Companies provide different roles to students with different skillsets. Programming in general has a versatile pool of tasks to choose from: for me, I do server maintenance on an internal file management server using VB.NET and C#, building on 7 previous years of other co-op student work. Others have gotten testing (QA) jobs, along with generic programmer descriptions. Like you said, it depends heavily on the business, but depending on the student's skill level, it is highly common to involve them (us) with web app development as well. Whether they're internal or for client use is largely irrelevant to the student's interest, since either way, they'll get the experience they want. Start off with easy tasks drawn from your business's needs, and assign them more / less / harder / easier work based on performance. This makes us valuable to your company in the time we're there, and as far as making the experience valuable to the students, just programming outside of school is useful. Give us code and we'll be happy (as long as it's not Turing or something).

Answer 7

I'd treat a co-op/intern student like any other junior employee. Mostly they are probably there to gain experience working in a software development enviroment, and will need plenty of mentorship on things including 1) source control and codebase structure, 2) bug triage and handling, 3) producing production code with attention to code quality and readability. These are things that probably don't get covered much in CS/engineering school curricula (lots of math though!).

I'd definitely emphasize any tasks that require getting to know bug reporting systems or source control since these are great toolsfor a co-op student to get to know well. They also will indirectly force students to improve technical reading/writing/communication skills and to become more organized. Maintenance programming comes to mind as another task that will be beneficial ("Refactor some the ChildClass methods to better integrate with the new GUIObject interface").

Testing and QA is something else which is good for co-op students. Testing is a good way to get co-op students familiar with the application and the general processes of your workplace, but it may create the impression that testing is "easy" and just something that people who start out with "have to deal with".

Most importantly, as mentioned by other answers here, be honest with co-op students: don't hire one on the promise of being a developer writing code and stick them with a support position or coffee gopher. If you wouldn't do this to a regular new hire, don't do it to a co-op student.