Much, but not all, of this information is MIT-specific. Also see my notes on collaborating with undergraduates in research.
At some point you may wish to get help from others in completing a research project; taking on an undergraduate is a good way to do that. Remember that the point of the relationship is not just to advance a specific project, but also to develop the new group member into an independent researcher.
This document collects some common-sense rules for interviewers. It is particularly aimed at hiring undergraduate researchers, but many of the ideas are generally applicable. Different people find that different interviewing styles work for them; you should consider these tips, then apply them as appropriate. Additions, corrections, and pointers to other resources are gratefully accepted.
In the MIT Program Analysis Group, Michael Ernst keeps a list of short summaries of each candidate anyone in the group has interviewed. Before you interview someone for PAG, find out if he or she appears on that list (and the impressions that were recorded). After you interview someone, submit a short (3-4 sentence) description of the person for the list (include the full name, email address, and year in school along with the comments).
Most people who didn't get an A in 6.005/6.170 aren't up to snuff (unless they have extraordinary experience or an excellent story about why they couldn't score in the top third or half of this class). If they're still taking 6.170, talk to their TA, and ask for a recommendation. (For instance, would the person make a good UROP? Is the person one of the top 3 or 4 in the recitation? Is the person clearly of “A” caliber?) Remember that MIT grades on a 5-point scale; a 4.0 GPA means someone who has a straight-B average.
I typically ask candidates to provide a resume, grade report, code sample, and writing sample. I find that these help me to get an impression of the person's interests and abilities. (This also has the effect of weeding out some people who don't want to provide the info, but that's certainly not the point of asking for it: it would be rude to ask for information that we didn't even use. The weeding out probably eliminates a few good candidates along with quite a few poor ones.)
We have no interest in people who only want to work for the summer or for only one semester. A single semester or summer isn't enough to get up to speed on an interesting and valuable project. There's no guarantee of future employment, of course, but if all goes well, our goal is to continue supporting the research.
Hiring the best person for the job is more important than their year in the undergraduate program. However, all other things being equal, younger is better — the younger person will continue to improve, and will have a longer tenure with the group.
I am extremely skeptical of second-semester seniors who are looking for a MEng project. There is no guarantee that one can finish a MEng project in just one calendar year, and it's often necessary to ramp up before spending the year of MEng work. For seniors looking for an MEng position, my policy is that it will take at least one calendar year (maybe longer) to finish the MEng research, and that I never fund the first semester of research, before the student has proved him- or herself. (I do try to fund half of the MEng year, but there's certainly no guarantee of that, either.)
Part-time work with two different organizations isn't a good idea; one or the other project will suffer, and in all likelihood both will suffer. A student should select one organization and commit to it.
I like to start people at the standard UROP pay rate for the first semester, then give them a substantial raise thereafter; but it's usually possible to pay more than the standard UROP wage.
Jeff Perkins says, regarding the interview itself: “My interviewing technique is normally to have them explain something that they have done. If they have undertaken a moderately complex project and can explain clearly what they have done and seem to understand it, that is usually a good indication. I don't normally ask 'quiz' questions (e.g., explain how virtual functions work in C++, or write code to reverse a linked list), but perhaps at this level that makes more sense. I also tend not to focus on specific background (e.g., in-depth knowledge of Java) but rather on overall ability. I figure that good people can learn what they are missing. Again, with a shorter time period, a more specific background match might make more sense.”
I follow a similar interviewing philosophy. If they can explain something interesting, and answer detailed questions about it, then they both understand it and can communicate; those are the two key issues and can usually be transferred to another topic. (Many people end up working on something other than their initial project, after all.) (And those abilities are likely to be correlated with coding ability.) Another thing that I like to tease out in an interview is what the candidate is interested in (enjoys, is passionate about); when some topic fits in the intersection of a person's competence and interest, then the person usually does very well at it.
Most people who come for an interview have at least some minimal level of qualifications. However, sometimes an interview reveals that someone is very ill-suited to the job: for instance, the interviewee has no programming experience, has very poor communication skills, or hasn't even looked over the material you provided. In such a circumstance, you should cut the interview short — it isn't your responsibility to spend another half hour or hour of your time talking with a person who shouldn't have applied in the first place.
Back to Advice compiled by Michael Ernst.
Michael Ernst