Our yearly batch of summer interns arrived last week. I always struggle with how to get a large group of fresh faces up to speed quickly. The challenge is coming up with an agenda that keeps everybody busy with educational, engaging activities without overloading them. This year, I did my best to plan a mix of product demos and classroom-style programming lectures. This year went smoother than years past, but I’d say it was still only marginally successful.
We have a suite of products that I wanted to expose the group to. So, each day, I scheduled a 1-hour demo with a different application. The interns liked seeing the different products but felt that the demos went too deep and provided too much redundant information. Fair enough. I’m usually hesitant to do too many product demos with new hires because it’s so much information that very little is retained. Instead, it might be better give the demos at a much higher level. So that’s lesson number one: talk about the purpose of the applications and their primary modules instead of going through each module and all of its sub-modules.
The other half of my “curriculum” revolved around our development tools, processes, and practices. I covered a different topic each day: Monday was an overview of tools (Visual Studio, SQL Server Management Studio, etc.); Tuesday we talked about object-oriented programming; Wednesday was an introduction to unit testing; Thursday was test-driven development and unit test mocks; and Friday was agile development. I wasn’t sure how high or low level to go with a lot of these because I wasn’t sure how much exposure the interns had to any of these topics.
The tools overview was probably the least useful session. I know that most colleges aren’t working with .NET and Visual Studio, so I wanted to go through the IDE and cover how to do basic tasks as well as highlight some of the less obvious features that I like. The problem here is that the basic functionality is self-explanatory and the advanced features can’t be appreciated until you’ve used the software for a bit. We use SQL Server, too, so I wanted to breeze through SQL Server Management Studio. I had the same problem there–people who knew what I was talking about already knew what I was showing them, and people who didn’t know SQL were nodding along but probably not processing. So at the end of the day, that was somewhat of a bust.
The other sessions went better. When I covered object-oriented programming, I just tried to stress SOLID design principles. I also discussed the important of usability over reusability and quickly touched on code smells. I think the message was clear: SOLID + low odor = good. The introduction to unit testing was good, too. I was surprised to see that more than half of our interns had done unit testing as part of their school work. I’m glad to see this sneaking into college courses. The test-driven session that followed also went well, and it turned into a demonstration of mocks. None of the interns had seen mocks before, and I think they were generally excited with what they saw. The final session of the week was about agile. I shared my thoughts on what makes a good story and how the stories drive work from sprint to sprint. The agile stuff went okay–lots of nodding–but the conversation turned into more of a Q&A for me. The interns were interested in how I learned all that I know, and I was happy to share my experiences and insights that have helped me enjoy a successful career so far.
Overall, I’d say it was a pretty good week. There was still a bit too much time where the interns weren’t sure what they should be working on, but it was a more organized first week than we’ve had in the past. I’m satisfied with how it went, but I have plenty of ideas on how to make it better next year.
I’m interested to know what the first week for interns looks like at other companies. What sorts of activities do you plan? How do you introduce them to your product(s)? What do you do to get them up to speed and productive? And what do you do to keep it fun?
adamprescott.net 