Contents:
This document is aimed at graduate students who wish to collaborate with undergraduates in their research.
There are many benefits to collaborating with undergraduates (or others). Many hands (and, especially, minds!) make light work: you can accomplish more if you are working with colleagues. Having others to brainstorm with, or to keep you honest by asking questions about your ideas, is also valuable. Advising is an important skill you will need to learn at some point (and that you will probably never stop learning), so getting practice is valuable. There is great satisfaction in introducing others to the joys of research, and in helping them to grow professionally.
Using an undergraduate in research is not that different from using a graduate student as a researcher. How do you enjoy being treated, and what makes you effective? Duplicate these traits for your undergraduate colleagues, keep their perspective in mind, and both they and you will be happy.
You should avoid working with more than one or maybe two undergraduates at a time. You can build an empire later, when you are a professor.
There are two aspects to choosing an undergraduate collaborator. First is locating an individual (and convincing him or her that your project is interesting), and second is satisfying yourself that the person will be a productive colleague.
If you have been a TA, you know about good undergraduates and can ask them directly. Another traditional way to find undergraduates is for a faculty member to refer them to you, filtering for quality, interests, and working style.
I looked up TAs for all the relevant courses and emailed them asking for recommendations of outstanding undergraduates who might be interested in research. Then I emailed those students telling them a little about my project and asking them if they had any interest. If so, I sent a list potential projects they could work on (described in two sentences each), and set up a meeting.
When advertising for students or contacting them after getting a reference, it is very helpful to to write a blurb about your project. As with all writing, get some feedback from your friends about what you have written: how does it come across? A good guide will be what you would yourself enjoy doing. Make sure that you make the project sound interesting: people would rather be involved in a project where they are active participants than one in which they will be mere implementors, and they would rather do something new than merely re-implement or maintain an existing project. They are also more likely to be compelled by a project with practical and realistic impact or goals. Some undergraduates don't like projects that are too open-ended: at that stage in their career, they may prefer more direction. When you have your marketing hat on, be honest: don't promise the world in your blurb. It's unlikely that an undergrad (especially one just starting on a project) will end up with complete freedom — not even grad students have that, and they are grateful for the feedback and direction from their advisors.
If you are at MIT, you should put your blurb on the PAG projects page (http://pag.csail.mit.edu/internal/projects.html, accessible from the mit.edu domain). That should also be linked form the CSAIL MEng projects page, which (as of Sept 2004) is maintained by Jordana Riley <jordana@csail.mit.edu>.
You should definitely send your blurb to Anne Hunter <anneh@mit.edu> in the EECS undergraduate office, asking her to forward it to her “jobs list”, which reaches essentially all undergraduate computer science students at MIT. When sending a message for Anne to forward, make sure that you make it clear what you are looking for (typically “UROP/AUP/MEng”) — both because that is useful information and because Anne Hunter may reject it otherwise. If you include a reference to http://pag.csail.mit.edu/pag/projects.html, be sure to note that it is accessible from the mit.edu domain or via MIT certificates only, or else people will try to view the page and give up, typically without telling us about the problem.
Also see my notes on interviewing undergraduates.
At the meeting, I answered questions, discussed the projects and logistics (like how many hours per week, for money or for academic credit, how long and whether it would continue to summer), asked what classes they had taken, what grades they got, and who their TAs were, and gave my own references, such as undergraduates I had previously worked with. Essentially, this was an interview; how they interacted with me, whether they asked good questions, etc. was a big part of my evaluation. You should know (and make clear to the student) what skill set is required. This encourages ones who might otherwise have been overawed by the problem and discourages those who would not be prepared.
My approach is to offer a palette of options to the student. Be prepared with a list of at least a half dozen potential projects, each described in a brief paragraph, and be ready to expand on them. See which one(s) the student is most interested in. This guarantees greater interest and buyin on the project (not to mention selection of one for which the student is better qualified), and it shows respect for the student, who is not just a lackey to be ordered around (more on that later). I always also said, “and if you have an idea, I would be happy to have you work on that as well.” They never did, but that kind of gamble could pay off big, and it again shows respect. Beware of students who are interested in everything. That really means they are interested in nothing. You should send them to one of your colleagues working in a different area where the student might find his or her real love and be far more productive than with you.
There's a tradeoff between telling the student what to do and asking what he/she wants. The former may be better for undergraduates (and early-stage graduate students). I think that “you will do one of these n things” is a reasonable tradeoff.
I strongly recommend that you choose a standalone black box for the student to implement and which will work with the rest of your system.
When choosing a project, be sure to know what the goal is, what you need to do to accomplish it, and what you hope to learn. (It's not necessarily bad to have a desired outcome, so long as your research is honest and fair.) This is good at giving the big picture and letting the undergraduate know why he/she is hacking on the code, when an alternative approach is acceptable (and when it would defeat the purpose), and why the work is important.
Should you choose a project on the critical path? You should probably avoid it. It might be OK if you have enough else to keep you busy (that is, you really need it in three months, but you don't really need it now). If worse comes to worse, you can always just do it yourself (though that may hurt the student's ego).
Should the project be research or “just implementation”? Even you don't know what interesting problems will come up in the course of the work. It's fine to give something that seems straightforward (though avoid really grody stuff — if you think you can do it in two days, the undergrad might be able to do it in a couple of weeks but may not have much fun at the task), because you may find really interesting results. Even if the initial project is straightforward, understanding/interpreting the results may not be, and the undergraduate should be involved in that. Don't give a detailed design, just a specification of the task. Let the student do the design. You might be pleasantly surprised, that is fun work, it increases buyin and enjoyment, and it teaches the student something.
When you hire the student, settle on issues like how many hours per week the student will work. Confirm that in email. This is important to fix in both of your minds. Watch out for overcommitted undergraduates who are taking too many classes or have other jobs, etc.; you may wish to ask about this in the initial interviews.
I believe that working over the summer is better than during the term. You get the full attention of student. Distractions (such as classes) are the kiss of death, but 40 hours of productive work is a huge amount. It may only be feasible to start during the school year, which also helps both parties scope one another out and figure out whether a summer commitment is worthwhile. Be upfront about the possibility that it will not work out, either for you or for the student. However, have the expectation that the relationship will last for some time and be a success all around.
I prefer paying money to offering course credit. It's quite rare for a good student to be short on credit (except, in some cases, for double-majors). Students appear to take the work more seriously, and to spend more time, if it is for pay. Money requires accounting of time spent on the project (and students are used to delaying work on classes until the very end). Turning in a timecard is a good reminder about the student's obligations and a check on whether they are being fulfilled. Spending even a little time on the project in a steady way guarantees progress, and failure to make steady progress is perhaps the biggest potential problem in a project. (Another alternative may be to do credit and pay; this is possible, just like RAs get money and credit.)
You need to accept upfront that advising a student will take enormous amounts of your time. However, people matter, and they can tell whether you care about them, so this is time both well and productively spent. For instance, you may need to teach them tools such as Emacs, a debugger, and so forth; but their work will more than reflect your investment. It's possible to advise a student with very little time; however, I don't think either party will get much out of the relationship.
Using the student will probably save you a small amount of time overall. However, it might not (or it might turn out to be a huge win). This is especially true in the first quarter. Students will become more productive as they climb the learning curve. Don't view a student as a guarantee of results, but as a gamble.
My skin crawls whenever I hear someone talking about “my student” who is “working for me”. That should be “my colleague” who is “working with me”. This is not just a matter of semantics but a fundamental key to your relationship and the respect accorded. You're likely to get what you expect, so don't expect second-rate work from someone who can't make a real contribution intellectually.
Others, though, recommend to set a clear tone that you are the manager (not just a colleague, but not aspiring to the role of advisor, either). This means there is clear authority and hierarchy, so you get to make final decisions and the student feels worse about disappointing you.
The professor is often involved in choosing research projects, but need not then meet weekly with the undergraduate. (Inviting the undergrads to a weekly research group meeting is a good idea.) This lessens the load on the faculty. Involving a professor somewhat is a good idea because it lends credibility and raises the importance of the project in the undergraduate's eyes. The student may find it much easier to disappoint or blow off a graduate student than to do the same for a faculty member. And the faculty member will be a better writer of recommendation letters.
It's important to set a good example. Be honest in your dealings with people, in your measurements, and in your writing.
Use the same rules as for choosing the project. If you have the student write, make it just a section or two, and then edit it afterward. (Everyone is bad at a task the first few times they do it.) I've occasionally had bad luck even getting my junior colleagues to read the papers their names are on.
Essentially all problems in the world come from lack of communication, at least among well-meaning parties. (This is an overgeneralization, but is close to the truth.) Thus, your primary goal should be to ensure frequent communication. Make contact with the undergraduate at least once a week — more during the summer. (During the summer, it's good to drop in occasionally, since you know where the student will be and when; this is a great way to keep the lines of communication open.) Frequent communication keeps them on track: they can't claim progress when they haven't made any and their guilt about lack of progress is increased. Equally importantly, it alerts you to when they are no longer on track, so that you can take action (from redirecting them to working intensively with them to jettisoning them). In order to understand the progress (and to help the undergraduate), you need to understand the approach and the implementation, at least at some level. Don't be a Dilbert manager.
Students should be both able to tell you what they have done (do they understand it well enough to clearly communicate it) and to show you what they have done (are there tools, documentation, or other artifacts that you can actually use?). Neither one alone is usually enough. Having both makes it clearer what has really been accomplished and keeps everyone honest.
One potentially serious problem with undergraduates (and others!) is that they may believe it's OK to finish things at the last moment. That's only OK if your aim is to equal the quality of an undergraduate project that was finished at the last moment — because that is what you are guaranteed to get. Don't let this happen; communicate frequently, have milestones, and know the current status of the project.
Other problem-avoiding strategies were described elsewhere in this document, especially in the “Advising” section.
Finally, be sure to get other people's opinions besides mine. Their experiences, too, can help ensure that working with an undergraduate is rewarding for all parties.
Back to Advice compiled by Michael Ernst.
Michael Ernst