In grad school, I’ve had the privilege to do research with UW’s extraordinarily talented undergrads. Some of these relationships have been successful and a few have ended in utter disappointment. Here are a few obvious-in-retrospect lessons I learned along the way.
Why Undergraduate Research?
There are two obvious (and great!) reasons for working with undergrads:
- The student gets useful experience. They get an exclusive preview of what grad school might be like.
- You should get more work done than you could by toiling alone.
It’s important to keep both purposes in perspective: if one takes too much precedence and comes at the expense of the other, one or both of you will be unhappy and nothing will get done.
One implication is that you need to be careful about how to organize mundane logistics. Meeting too often—every day, for example—will make you feel like you’re putting more energy in than you’re getting out. But if you never see each other, the student can easily start feeling like they’re not making any progress.
Level of Autonomy
Choosing an appropriate project is the most difficult and most important decision in making undergrad mentorship work. I’ve found it useful to differentiate between two kinds of undergrad projects:
- Simpler endeavors where someone fills a specific role in an existing project.
- Bigger projects where the student explores a new direction.
Another way of putting this is that you need to decide who will be in charge: either you’re in charge and getting an undergrad to write code or run tests, or they’re in charge and your job is to guide them through the process.
Clearly, the former is easier to get going and manage. But the latter can be potentially more rewarding and it’s not as far-fetched as it may sound: with enough guidance and choice of project, sufficiently ambitious senior undergrads are certainly capable of “running the show.”
The student’s background should of course influence the level of ambition for the project. But also be sure to ask how much time they will have to devote and how much time you will have for advising.
Project Scope
Before meeting with an undergrad to start a collaboration, write down a few concrete ideas that you can “pitch” as possibilities. (I’ve had predictably little success with asking students to just work on “whatever they’re interested in.”) Here are three guidelines for deciding the scope of these ideas:
- It should be okay for the project to fail entirely or to go slower than you expect. So you should find some work that won’t be on your critical path: something where the student can work at their own speed. This will avoid overconstraining the student into boredom and stressing you out when plans inevitably change.
- If you can, plan out a few “telescoping” stages of increasing ambition for each project. If you have a big idea that could take several months, break it into a few milestones each feel like a completed whole. It’s okay for the first stage to feel disappointingly unambitious: this lets the first feeling of accomplishment come sooner. Getting mired down in the first step is not good for morale.
- In my experience, undergrads often underestimate their own preparedness for a project. So I’d err on the side of encouraging people to stretch: for example, learning new programming languages can be scary but is totally doable.
Feedback
Provide frequent and transparent feedback. The student has probably never done this before, so having as much metadata as possible about how the project is going can help them get their bearings.
There are two kinds of feedback I’ve found to be helpful:
- Frequently (and honestly) tell the student how they’re measuring up to your expecations for rate of progress. Especially when classes are competing for their time, undergrads can think they’re not accomplishing enough and need to be reassured that they can catch up next week.
- Keep the student informed of the plan. Having an actual document (Google Doc? Wiki page?) describing what’s planned next in the big picture of the project can add a lot of clarity to what can otherwise be a bewildering process.