My favorite is "tell me about a recent development project you worked on?" Ask that and let the interviewee speak, but look for passion in HOW they answer. Does he/she get wide-eyed and animated as they describe the project?

Other ones I like that will tell you if they keep up with the latest knowledge in the field:
"Tell me about a recent software development book you read".
"What do you think the next big trend will be in 3 years?"

Good luck finding your candidates!

Look for interest outside of college/university:

• What was your first computer (and what age)?
• Did you program on it?
• What was your first language?

Additionally:

• Are you involved in any open source projects?
• Which ones?
• Personal projects?
• What kind?

Ask them what their current reputation value is on StackOverflow.

My experience from teaching is that most students (in the degree or afterwards) always write code from scratch based on a very accurate spec. They have limited experience in understanding existing code, playing nicely with it, and figuring out vague requirements or asking followup question.

In reality, however, most of their work will be modifying or adding to existing code, and the requirements will not be clear.

Therefore, find some code in your program that is not super straightforward, ask them what it does. Then, ask them to make a modification or write something that uses it. that will tell you a lot.

I agree that you should avoid the usual cookie-cutter algorithm / data structure questions that every company uses and that college students collaboratively build databases on. In a short summer, you want to get the most bang for the buck, and more importantly, with minimal damage to your product. A bad intern is worse than no intern at all.

A good one for me has been "What's the last cool thing you learned?". This one works on both sides of the interview table, BTW.

A few months ago, I was interviewing for a position. It was the dev team interviewing me. The interview was going well enough, but something was just... not right. I asked this question of the team and they just all stared at me. The interview went south at this point, and I felt this was just as well. It would not have been a good fit for me.

From JoelOnSoftware ^[1]:

In the past, I’ve used “impossible questions,” also known as “back of the envelope questions.” Classic examples of this are “How many piano tuners are there in Seattle?” The candidate won’t know the answer, but smart candidates won’t give up and they’ll be happy to try and estimate a reasonable number for you. Let’s see, there are probably… what, a million people in Seattle? And maybe 1% of them have pianos? And a piano needs to be tuned every couple of years? And it takes 35 minutes to tune one? All wrong, of course, but at least they’re attacking the problem. The only reason to ask a question like this is that it lets you have a conversation with the candidate. “OK, 35 minutes, but what about travel time between pianos?”

“Good point. If the piano tuner could take reservations well in advance they could probably set up their schedule to minimize travel time. You know, do all the pianos in Redmond on Monday rather than going back and forth across 520 three times a day.”

A good back-of-the-envelope question allows you to have a conversation with the candidate that helps you form an opinion about whether they are smart. A bad “Aha!” pirate question usually results in the candidate just sort of staring at you for a while and then saying they’re stuck.

Since any good program is well organized piece of information I suggest to ask about passion to organize things (books, files, anything), passion towards good names (variable names, web domain names, file names, ...).

You can learn a lot by asking what features and aspects of software annoy the candidate, and how they would change them.

As a college student, they should have more to complain about than praise; I know I did. By asking this you can gain insight into a few things:

• Reluctance to issue criticism (will they continue to let a co-worker perform poorly? reflects teamwork)
• Willingness to improve (are they willing to inherit code and maintain it? Most college students would rather throw code away and start over)
• Attention to details (you can't be annoyed by what you don't notice)
• Ability to think of a way to improve software (do they have ideas of their own?)
• etc.

Not only will the answers be beneficial, but also the attitude they take towards it. A person should be passionate towards the things that they feel they could improve.

Also, take note of the candidates that ask questions themselves. Always allow them to ask questions. Hopefully they will ask about:

• Source control
• Languages Used
• Development environments
• Working environments
• Anything that can't be gleamed off your website...

Just be sure to avoid people who only ask "how much will I be paid?"

Get their reaction to this:

A good candidate would get the joke.

A great candidate would wonder why they weren't doing other related tasks, such as writing documentation.

I like to get a feel for personality as well when I'm interviewing, so I try and make my interviews as conversational as possible. Questions I like to ask:

1- What is your most favorite project that you have ever worked on? Doesn't have to be programming related. --I like to see them show some passion and get a feel for if the passion is driven by the work (e.g. I love painting), the results (e.g. the room looked pretty), the impact of the results on others (e.g. the poor family got a new house) or the impact of the results on themselves (e.g. I learned how to use a paint sprayer.)

2- What will you do if software development doesn't work out for you? --Again, this is just to get a conversation rolling. I like to hire people that can appreciate the "business problems" being solved as well as the technical and be able to communicate across domains. Here I'm looking for interest in fields beyond software as that is sometimes indicative of more flexibility when it comes to problems solving.

3- Describe to me a very frustrating experience and, if you got through it, how? --Working in software is frustrating in most places. I want to see patience.

A question I have used:

• When working on a project with others, have you ever had an argument over what the solution should be and how did you manage this scenario?

This is a common scenario even in college and being able to convince your teammates of the merits of your solution, or having the grace/wisdom to accept the merits of the other solution are very important abilities. I think in HR-speak it's called "conflict resolution".

If you're looking for passion/nerd-ness in young students how about asking them what tech related web sites and pod-casts they visit? It's a conversational open ended question that could tell you a lot.

For example, if a candidate told me they listened to BOL (Cnet's Buzz OUT Loud) or TWiT then I'd assume they were interested in the general trends. If they visit PennyArcade ask them what they like about it.

I would expect an enthusiastic candidate to have a least a few outlets of interest. These sources would not only tell you about their interests but my also prove enlightening to you too!

Describe a creative solution you used in solving a difficult problem.

Look for knowledge, imagination and actual coding skills rather than culture.

Questions:

What current private project are you working on at the moment?

Give an "architect view" of how the problem that is going to be solved during the 3 months should be solved in the best way. What tools to use, ideal language, and so on.

What OS do you use and why? (OS is not important. The reason is. It reflects knowledge and culture.)

What is the best/worst software you ever used? Why?

Tell the candidate they are writing some safety critical code to control machinery on a factory floor. All is going to plan and then someone from the company puts in a request for the ability to over ride a safety feature you have built into the software - Ask the candidate how they will respond to this.

You will be amazed how many people simply say they will add the requested feature.

I agree with everyone saying that "back of the envelope" questions are good to ask.

One question I was asked when I was interviewing out of college was "How many balloons would it take to fill a room?"

It allowed me to ask some questions that I thought were relevant to the answer, and then come up with a solution to how I would figure out the best estimated answer I could. They're great questions to get people to think critically, and you will get to see their problem solving skills at the same time.

Ask them what they are awesome at and why they should get the job.

You should not expect them to have written much code or done many projects. For a weaker sophmore candidate, their total kLOC is under 10. Doesn't mean they are bad, just means they aren't tuned into coding yet.

In Jim Collin's Good to Great book, he talks about leaders not being able to motivate people, but leaders being able to take away motivation from someone. The key, regardless of business role (computer programming, sales, et cetera), is to hire people with high levels of self-motivation. So I would ask in an interview, how does the person define motivation? What is a point in time in which they experienced the highest levels of motivation and what were they doing? And when was a point in time in which they became less motivated. These are all open ended conversations that should lead to a productive and affirming dialogue.

I would consider giving them a functional requirements document and ask them how they would go about building it. Make it a particularly bad requirements document (well that should be easy to find).

What you are looking for isn't the software solution or code but the thinking process - do they accept the bad requirement blindly or ask questions to get more detail, do they ask about what tools they have available to use or how this might integrate with existing projects or do they want to go off blindly developing using whatever they want with no thought that anyone else will need to maintain this code or that it needs a corporate standard. If you specify that they must use some old fashioned tool in the requirement, do they say they would use some other cooler tool, do they try to convince you that the cooler tool is the better idea or do they make their plan using the old clunky tool? Do they think to mention setting up the project in source control. Do they have any ideas at all about how to approach the problem? After all the last thing you want is a slug who will only do exactly what he is told and expect otheres to do his thinking for him.

Now a lot of interns are not going to get the most sophisticated answers to this and that's ok, but you want to look hardest at those who seem to have the best critical thinking skills as well as the most awareness that what they do isn't in a vacuum, but most relate to what others have done or will do. You also want to know that they will ask questions and try to refine rather than just change off blindly on their own.

The biggest problem I've seen from intern work is just that, that they get a little project and ignore whatever tools you have or use and do something in a tool no one else knows about with no source control and which no one will use after they leave. That's nice for them, but really very little benefit to the company. (Of course this also reflects that many companies don't manage their interns well, but that's another whole issue.)

You might also consider what kind of project you are going to give them to do. Ask questions that will indicate if they have an interest in this kind of work. If you want them to write some reports, ask some questions about reporting and what they think about it (also ask about some areas you don't plan to use them in so they don't know which is the main area of interest for you). It's no fun to manage an intern who has no interest at all in the type of project they will be working on. If the person is fascinated by embedded systems, even if he is a great candidate, you may want the guy who wants to do web sites instead if that is the project you will have for him to work on. Try to match thier interests to your actual nees for a small project to wrok on inthe three months they will be there. YOu''l have happier interns, they will get experience in what interests them and you will get better work from them - a win all around.

Since they've majored in computer science, they'll have been in contact with some maths as well. Don't ask them a math question. :) But it probably is valid to ask them to compare (and contrast) mathematics with computer science.

In fact, just ask them what they think computer science is. Of course this is subjective but it will tell you about the candidate.

Ask the candidate about any books or languages or language features he or she really likes. Ask why. See if the candidate is enthusiastic about something in the field.

Although some of these have fallen out of favor, some of the Microsoft questions are still great. They show whether the candidate has a penchant for logical / critical thinking when there is no clear answer... Do they give up? Or do they try and think through the issue one bite at a time?

Things like:

• How many piano tuners are there in the world?
• How do they make M&Ms?
• How many gas stations in the US?

Check out the book "How would you move Mount Fuji" for more insight.

I was once asked: How good are you at making coffee?

I was once asked "what's a recent news bit that you've heard about our company" from a well-known tanking technology company. At the time, I thought it was a good question to gage the honesty of a candidate.

I didn't get the job.

That aside, I think trying to create a good conversation between you and the candidate is a must for recent grads. It eases tension and creates an atmosphere that will minimize the stress for qualified candidates. Unqualified candidates will be screwed either way if you set it up properly.