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?


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!

  • 1
    Nitpicking: you say guys, but I don't think there's a gender bias among students that excel at programming and having the drive to get things done. – Steven Evers Jun 14 '11 at 16:34
  • 4
    Ahem. I actually went with "them" for most of the pronouns in order to avoid anyone mentioning this, but it would appear that one slipped through. In my colloquial slang of choice "guys" doesn't necessarily refer to people with dangly bits, just a group of people. I wasn't trying to imply any form of gender bias. – Ed James Jun 14 '11 at 16:42
  • 1
    I think SnOrfus is nitpicking a little to much. What do you guys think? – Michael Riley - AKA Gunny Jun 14 '11 at 19:30
  • 1
    Pretty clear that Ed was using a colloquialism I thought. Do you only use "guys" to refer to "males" in Canada, SnOrfus? – Carson63000 Jun 15 '11 at 3:21
  • 2
    @MichaelDurrant Not just a USA thing, I'm English, and I picked it up from my German CompSci professor at University who always referred to nodes on a graph as "these guys"! :D – Ed James May 11 '12 at 11:06

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.

  • Thats reassuring, we do not have a full time QA so more QA testing is badly needed right now. I just don't want to be that ****head who ruined the kids summer when he would rather be coding. I will be upfront with him about this. – maple_shaft Jun 14 '11 at 16:51
  • We fell behind in keeping up with automated unit tests, do you think this is something he could benefit from if I were to give him this assignment? – maple_shaft Jun 14 '11 at 16:53
  • 1
    @maple Yes, I damn well would! Do you think it is "beneath you" in some way? – Neil Butterworth Jun 14 '11 at 17:05
  • 1
    @Neil, I test my code to the best of my knowledge but sometimes the user does bizarre things that I never anticipated. A second pair of eyes are sometimes the only thing that will catch these kinds of problems. – maple_shaft Jun 14 '11 at 17:08
  • 1
    C'mon Neil, I have never worked on a project that had 100% automated unit test coverage. It is something I strive for believe me but nobody has that kind of time anymore. And even if I did, automated unit tests are NOT a replacement for FUNCTIONAL TESTING! – maple_shaft Jun 14 '11 at 17:43

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.


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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.