How does one manage an intern effectively?

Question

An intern will be starting with us soon for a couple months before going off to university. The intern is straight-out of high school and has some programming experience, but has never taken a university level computer science course or held a programming job. In addition, the intern has never used 99 percent of the technologies at our shop. As team lead/manager, I know there are a hundred different programming tasks that the team needs to get done. I don't want to overload the intern, but I still want the intern to be useful.

From someone that has had a similar experience how did you manage the intern in regard to:

1. Did you micro-manage the intern or were you easygoing?
2. Did you explain parts of the code-base or leave it up to the intern to figure out?
3. Did you give the intern access to source-control or did you manually commit their changes after checking them?
4. Did you enforce coding standards/rules?

Please answer the questions and mention what you thought worked best for 1-4.

Did I forget anything?

Answer 1

Did you micro-manage the intern or were you easygoing?

The project we were on was reasonably highly stressed, so we wanted to get that across to the intern, but we didn't want to stress them out too much. So we were pretty easy-going.

The tasks we assigned needed to be done, but were low priority. That meant the parts they were doing were "off the critical path".

Having said that, I did spend quite a bit of time with the intern in the first while. Whether this was "micro-managing" or just "bringing up to speed" is hard to judge.

Did you explain parts of the code-base or leave it up to the intern to figure out?

Where we started was with automating some tests. The code-base was Qt, but the libraries we were using could be wrapped in command-line tools. We had a couple already done, but needed several more (different parts of an API), so we walked the intern through the existing ones and showed what needed to happen for the new ones.

Did you give the intern access to source-control or did you manually commit their changes after checking them?

For the first weeks we got them to work outside of source control, but after a while it just turned out to be double-jobbing, so we gave them direct access. Sure, they blew it a time or two, but no more (or less!) than the main development team.

Did you enforce coding standards/rules?

Definitely. This was a real project. We had some tools that allowed easy adherence to some parts of the standard, but other bits just had to be learned.

---

Did I forget anything?

Not really. The only thing I would add is that you should treat the intern as a professional. Perhaps not a professional developer (yet), but as a professional. That means trust them, and make them aware you are trusting them. If they make a mistake, that's fine; if they betray (or misuse) the trust, that's a problem.

Make them aware of any problems as soon as you are aware of them. Again, professionally.

Answer 2

Well I'm not an employer but rather an intern right now so I thought I could give you something from my perspective. I just finished my sophomore year and I landed an internship with a team of people that do the web development for a supply company (like manage the databases and all that fun stuff). I don't know how experienced your intern is but I have had a couple years of object oriented programming classes so I had the basics somewhat down. The funny thing is that I had just about no server side programming experience and that's what this team of people did. I had to learn a lot of new concepts. When I was hired they even said that they know I don't have any experience with that so it will be a learning experience.

It is a very research oriented internship, and I think most programming internships are because the student may not have any experience with the technology they got hired for. They encourage me to use Google and the StackExchange websites when I hit a road block or just want to learn about something new. That being said, I don't think you should have to micro-manage your intern because if he or she does not want to learn everything they can about said technology then they probably shouldn't be working there. I think programming internships should be fairly easygoing as long as the intern or employee shows the want and willingness to learn and evolve.

Even though I already had experience with the .NET framework, on the first week my mentor took me to the training room and we went through as much of it as we could. We started with the very basics and when we came to something that I already knew or was comfortable with I let him know. Don't get me wrong, we didn't waste time by going over every little thing, but it was important to get a refresher in certain things.

As for your question with the source control it is probably up to you, or how well you trust the intern. Personally I have access to all of the companies development databases and most of the things that my team/mentors have access to. But I think before I commit any major changes I have to let them do it, so it might be best if you commit their changes after checking them.

Programming is not about memorizing syntax and being able to crank out lots of code, and I think that's what a lot of starters like myself are learning. There are certain things that my mentor shows me and he specifically says that this is the way he likes to do it, and that there are other ways to do it. He said that there are multiple ways to do something, but that there are also wrong ways to do something. So I think it is important to try and get the intern to understand the concepts behind the code, but to also make sure that they know that your way is not the only way to do things.

I'm only in my third week of my internship and it's been an awesome experience so far. I hope this helped a little.

Answer 3

The same as you manage anyone:

• Find out how much direction they need and give it to them.
• Give them the information and guidance they need; set them up for success.
• Make sure they don't have blockages (internal or external) that prevent them from getting things done.
• Give them support to learn and grow.
• Set expectations for their behavior and how they will interact with the rest of the team.

Interns are not categorically different from other employees. You should treat them like an individual with their own competencies and character, just as you do with other employees.

As to version control: let them commit to their own branch(es). With a distributed system (like git), everyone should probably be committing to a branch anyway.

Answer 4

My method is to start the intern on a task that I know they can do, but I know will be useful to me. Some examples are cleaning up some HTML, making minute changes to the code, etc.

I taught them how to use source control right from the start, and I checked their work as they finished it. If they finished the task successfully, I gave them a new one that was slightly more complex. I've found that the easiest way to get people to learn a new code base/ tool / language is to give them real things to do and then point them to the resources they need to be successful.

The single most important thing you can teach an intern, in my opinion, is how to learn on their own. I give them enough information so that they understand what to search for and where to look for their answers, but I stop short of spoon feeding them. If you gradually up the complexity of the tasks you give them, you'd be surprised at how quickly they can get up to speed.

Answer 5

I am speaking from personal experience of an being an intern less than 10 years ago.

1. A lot was expected out of me from the day one but I was never micro managed. I was tasked with making custom enterprise modules from the first day that were important strategically but not high priority. My boss was demanding but fair when it came to time management and deliverables. I appreciated being treated as an employee and not as a hindrance.

2. The greatest impact my boss had on me in my in my internship was when he asked me to stop asking questions without thinking through what I was asking. He asked me to thoroughly research to see if I could answer the questions myself. This made me afraid to ask questions for a while it taught me to research and analysis skills that in the long run made me a better programmer and more effective employee.

3. My code was reviewed before being applied to any production code. I highly recommend establishing a safe testing environment for interns.

Answer 6

Two words for you. Pair-programming. Pair him up with a senior member of the team. If your senior guy is any good, it won't be a hindrance, if the intern is any good, he'll be contributing after a few days of observation. Great way to determine if you should invite him back next year too.

Answer 7

Did you micro-manage the intern or were you easygoing?

1 - Easy going will show that you trust the intern, however, set frequent checkpoints and milestones. Daily scrums also work very well for touching base on where they are.

Did you explain parts of the code-base or leave it up to the intern to figure out?

2 - Save both of you some aggravation and explain the broad strokes, and explain where you think some of the harder parts might be. Beyond that, let the intern take the lead, and make it clear that you are available for questions (and then, be available). The better documented your code is, the less of an active role you need to take.

Did you give the intern access to source-control or did you manually commit their changes after checking them?

3 - I think that the manual commitments will give you a chance to review the code for your quality standards BUT ALSO provide a great chance for real world feedback to the intern and suggest routes for improvements (don't make it a nit pick session however). In this case, due to the lack of experience of your intern, I probably would rather review than to allow the commits.

Did you enforce coding standards/rules?

4 - Yes. Internships should be about learning what is expected in the real world. The work produced must be acceptable to you to be valuable, but also has to be valuable to the intern.

It is fine to expect professional quality output, as long as you fundamentally accept that the intern is going to require more time, guidance, patience and assistance to produce that output.

Hope this helps

Answer 8

I would start them off by giving them the simplest of tasks that you need done, then progress them onto more complex tasks as they get more proficient.

To manage them effectively:

1. Check on them periodically, but give them some room to learn and discover on their own.
2. Explain what they need to know at a high level, but leave something up to them to figure out.
3. Definitely give them access to your source control, but have them check with you first before they commit their changes. This is a good opportunity to do a code review and explain anything that isn't up to snuff. Later on when your code reviews uncover less issues, have them commit their changes without checking with you first, but then check on the work they did yourself by reviewing the changes they made in your source control.
4. Definitely enforce the programming standards and rules that other developers on your team adhere to.

Overall, mold them into what you need them to be, but give them the time to learn on their own. Make yourself available to them because they will have questions for you.

Answer 9

We had a situation like this once. The intern came on for the summer just before starting university. He was going into a computer science program though.

We didn't actually let him code on his own. We started off with him shadowing other developers. When I shadowed him, we did some pair programming which he seemed to enjoy. This gave him the chance to write some code while also asking questions. It was a good learning experience for him.

After rotating with people, we decided to put him on the QA team. The lead QA walked him through how to do test plans, how to write up tickets for defects, and how to do various tasks in the QA environment, and he took to it really well. He turned out to be one of the best QAs on the team actually.

As for your questions.

1. Easy going. But then we weren't expecting too much from him
2. Explained as he never worked on it without a dev present.
3. We did give him access to source, and we did do some coding on his computer, but then he was supervised.
4. Yes, we got him to read the coding standards for our company during his first week.

Answer 10

Another intern's perspective.

I work for a company that did not do software development as the business. There is however an IT department which is responsible for solving Technology related problems. I've done two internships here and I'm now a part time employee since I'm still in school.

When I started there were 4 other "programmers" of which 2 were contractors that dealt with SQL reports mostly and the other two and one of the contractors as well dealt with a legacy system which the entire company was still tied to the hip with.

When I came in my boss wanted me to work on all of these projects he had in mind, but simply didn't have the resources to work on. Since then I've dealt with automizing tasks and and pulling data from some software we use and making it available via a live updating web platform. Additionally I've been working on an iPhone app for our customers and other projects to help bring in money to the company by reaching out to our customers through web platforms.

For the most part I've been unsupervised when working, just showing end results and taking feedback on what I've done. Additionally I've been throw into the deep end quite a bit with lots of projects using technology I'm not familiar with such as programming for the iPhone.

I would say 1. Don't micro manage and be easy going on your intern. Give them some room to explore and see where they need help. Don't just breathe down his or her neck from the get go. Be easy going but know that results are expected.

2.This is really a "it depends" kind of question. If you're going to have your intern writing code which will need your existing code base then yes, you will have to explain it to them for them to get it. If they are working on something which doest not used the existing code base and is somewhat separated from the rest of the project then I can't see the benefit in explaining the code base to them.

3.Source control allows revisions right? It might be good to have someone go over his code before he submits it, but allow him to submit it. It seems like it would be tedious for other members to have to submit code for your intern.

4.Yes coding standards and rule should be enforced. The intern is there to learn!