This document collects some common-sense rules for interviewers. It is particularly aimed at graduate students who wish to hire an undergraduate researcher (also see my notes on collaborating with undergraduates in research), but most 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.
Before the interview, I ask the candidate 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 weeds out some people who don't care about the position enough to provide the info.)
Talk to the student's TA in any relevant class, and ask for a recommendation (especially if the class is still ongoing and so the student has not yet received a grade). For instance, would the person make a good undergraduate researcher? Is the person one of the top 3 or 4 in the recitation?
I send the candidate a summary of potential research projects, to help them understand my current interests and needs. Their work will likely be related to one of those areas.
Avoid any candidate who didn't score near the top of the relevant classes. As a corollary, avoid students who have not yet taken the relevant classes. (For my research group, this is CSE 331 at UW.) A student who is not well-prepared won't be able to make good progress in the research, which will mean more time, effort, and frustration for everyone. You will find yourself tutoring the student in material that is more efficiently conveyed in a class. It is a service to the student to ask him/her to focus on classes for one more term, and then to do research when he/she has the time and skills. It's OK to interview someone who is currently taking the class, to start research when the class ends.
There are exceptions, such as when a student has extraordinary experience or an excellent story about why they didn't excel in the class, but these should be rare.
The goal of an interview is twofold: to learn about the candidate, and to let the candidate learn about you and the research.
You want to learn the following facts about the candidate, in order of importance:
Communication is most important because if there is someone who cannot explain his work, including both successes and problems, then you cannot understand it either and they might as well not even be working with you.
Intelligence is next most important, because a smart person can pick up new skills, is fun to work with, and is most likely to achieve a lot. Furthermore, it is extremely unlikely that anyone already has exactly the skill set that you need, and many people eventually work on something other than their initial project.
Especially for a short-term project, or one that requires use of a particular programming language or toolset, knowledge of specific tools may be a prerequisite. 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 in the job.
I do not have a specific script that I follow in each interview. Rather, I have a set of general questions and then let the conversation flow to learn what I can about the candidate.
One revealing question is what the candidate is interested in (enjoys, is passionate about), and why; when some topic fits in the intersection of a person's competence and interest, then the person usually does very well at it.
I also like to ask the student to explain a previous project. If they can explain something technical, explain why it is interesting, and answer detailed questions about it, then they both understand it and can communicate; those are the two key intellectual facilities and can usually be transferred to another topic, such as programming.
Let the candidate ask questions too. This tells you a lot about them. Are the questions thoughtful? Are they formulaic? (I'm so tired of hearing someone ask for a summary of all of my research, after I had already emailed them a summary of it.) Or are there no questions, which is also a bad sign?
Jeff Perkins has a similar philosophy to mine. He says: “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. If a project has a shorter time period, a more specific background match might make more sense.”
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.
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. This also applies to undergraduates who attempt to hold a TA and a research position simultaneously.
We have no interest in people who only want to work for the summer or for only one term. A single term or summer isn't enough to get up to speed on an interesting and valuable project. Anyone with a short-term attitude toward the project is less likely to be committed and to do good work. There's no guarantee of future employment, of course, but if all goes well, our goal is always to continue the research.
Significant commitment is required on your part, as well. See my notes on collaborating with undergraduates in research.
I always encourage students to consider multiple research groups. The reason is that — regardless of how understaffed my own projects are — I am most interested in finding an excellent match for the student, where the student will enjoy the work and produce great results. Sometimes, talking to another potential adviser confirms to the student that my work is the most exciting; this helps the student to avoid “buyer's remorse”. Other times, the student finds a different group, but that is a success too.
Don't make a hiring decision (positive or negative) on the spot — both because snap decisions are not usually the best ones, and because instant rejection is unnecessarily harsh to the student's ego. Instead, give each party time to think about the interview. Agree upon a concrete timetable by which each of you will let the other know whether you are interested, and stick to your end of it.
Be conservative in taking on new colleagues. A top-notch team member will move your work forward, but a poor one will require more time to manage than the benefit that anyone gains. Accepting a mediocre candidate is a common but costly mistake; avoid it! Be especially conservative when you are just learning to be a manager. You will get better with time, but you might as well not make the same rookie mistakes on a whole set of students.
Your organization (such as a university research group) should record a summary of each candidate anyone in the group has interviewed. Before you interview someone, 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 to your adviser, and include the full name, email address, and year in school along with the comments.
Back to Advice compiled by Michael Ernst.
Michael Ernst