Interview approaches and questions for a software developer intern

Question

What are some good ideas, common approaches and appropriate questions that you would bring when interviewing a software development intern to join your team?

I really don't have expectations of any kind for this person, I understand that as an intern with no prior work experience that he won't have much to bring to the table. I am more or less looking for a good attitude and somebody willing to learn.

What would be appropriate if you intend to put this intern 70/30 (QA Testing/Coding)? Would that be a good internship experience in your opinion?

Answer 1

Don't expect them to be completely useless (they shouldn't be).

Expect them to be able to code well (asking about how to use the array-based collection-of-choice in your language-of-choice (i.e. List in c#, Vector/ArrayList in Java, etc.) is a good start), but expect them to have little experience of things like Version Control, business requirement documentation and QA.

I joined my first company as a summer intern, being given a task that sounded reasonably complex (implementing a csv parsing module for a certain data import). They expected this task to take me right up to the end of my 6-month internship, and I happily finished it in a week.

I understand that most people think that you don't learn anything useful at University, however, you will probably find that the people applying for internships are likely to be guys who excelled at programming and have real drive to get stuff done.

So, ask them about coding. Ask them about what they've coded before that they were proud of. Ask them what they want to get out of the internship (skills-wise).

Hopefully you'll end up with a quality, if inexperienced, worker that you can use for a constructive aim that's beneficial for both you and the intern!

Answer 2

There are a few things we try to find out about interns, but it mostly comes down to aptitude and interest. You want to ask about technical things they've done, either in school or on their own, and decide if they have any real potential and why the heck they're pursuing CS. Back in the day the second bit was a lot easier. Not many people fiddled with punch cards for 4 years if they weren't really into it. Today you get a lot of kids who "like the internet" and decide to go into CS for that reason. God save us.

So I ask things like "what's the coolest thing you've done?" and "what excites you about becoming a programmer?"

Then I make them do automation tasks, manual testing, and coding up a few small utilities for a summer.

Answer 3

I would strongly urge...

"Bring in some code you wrote for either one of your classes or a side project you have and walk us through it"

If they don't have code, they probably shouldn't be interning for a programmer position (yet).
Have them present the problem/project they were working on. Be easy on the intern, but ask about design decisions they made, tradeoffs they faced. What was easy/hard for them. Also then start expanding the scope of the project on them and ask how they would incorporate the changes.

Look for people with good, thoughtful answers. Asking "have you heard of semaphores or mutex'es" if they get stuck on some part is fair, and no problem if they haven't.

This interview can be anywhere from 1-4 hours depending on how deep you want to go. I think in the case of interns, phone screen a few out of the way and keep the interview to 90 minutes (disrupts your team for 2 hours) That seems to provide a good pain/value mix.

Answer 4

I normally ask interns about their school projects during the interview. I give them a chance to explain what they have been working on, design choices if any, what they learned from the experience, etc. It gives me a chance to see how they go about doing their assignments and also allows me make a better decision on if this is someone I could see myself working with and mentoring over the next few months.

Don't treat the intern like they are an intern. Treat them like they are apart of the team, because they are. Give them something to do that they can own and that isn't trivial. It should be advanced enough that they will learn something but small enough that if they foobar it, you won't be left in a bad situation when they leave.

Giving them chump tasks doesn't help them, and doesn't help your company either. If they are unsatisfied with their task it will show in their performance as they won't be happy and will feel as if their work doesn't matter.

Follow up with them to make sure they aren't over their head and do code reviews so that you can see what is being inserted in your code base and so that you can give them suggestions on how to improve their code.