So you’re an undergrad looking to get involved in research—good for you!

Prof. Fox gave a short presentation on “Getting Started in Ugrad Research” on November 15,5:30 pm, in the Woz Lounge, which was well attended. (Thanks to Miyoko Tsubamoto for posting the photo)

The Beehive application, formerly called ResearchMatch and designed by your own colleagues who are alumni of Prof. Fox’s CS169 course under the guidance of Prof. Jeff Bokor in EE,  is designed to make it easy to find listings that match your skills, availability and interests.

But before you browse them, here are some tips that should help your search.

The single biggest failure mode/source of problems in undergraduate research, whether for pay or for credit, is overestimating how much time you’ll have available and/or underestimating the effort required for your courseload or the research project. Spending 3 or 4 hours every other week on a project is essentially wasted time—yours and the project’s—and the project leaders won’t be happy about it.

Continuity: It takes time to come up to speed and begin contributing to a project.  If you’re only available on and off or for a short time, it’ll be hard to hire you.  Usually the minimum amount of time is a full semester (or summer), and many positions are open-ended where you could continue beyond that if things were going well.

Availability:  Contributing to a research project takes time.  Think of it as the equivalent of a 2 to 3 unit CS course.  If you don’t have at least 6 to 8 hours per week available to spend, it’ll be hard for you to contribute.

The right reasons: A good reason to try research is to see if you enjoy it and might want to consider graduate school, or if you want to learn more about an area than what you are learning in courses.  A very, very bad reason is to get the checkbox on your resume that says “I did research.”  The checkbox is not useful unless accompanied by a strong letter from your research supervisor(s), and that letter will reflect your actual contributions to the project.

Dependability: Most groups who hire undergrads to do research actually have work that needs to be done—they’re not creating work specifically for you to do.  That means if the work isn’t getting done, the project is being affected.  Remember that by signing up to do this you’re committing that you will do your best to help.

Persistence:  Faculty and grad students can get really busy.  If you don’t get a response to your email, try again, and again.  It’s nothing personal!

Initiative:  A big difference between research and courses is that research is not driven by the structured deadlines that characterize courses.  You need to take the initiative to bug your research supervisors or colleagues when you run into a wall, or solve a problem and are ready to tackle the next challenge.  Don’t assume that they will constantly check in with you to ask how things are going.  If there is a weekly meeting for the members of the project, make every effort to go so you can stay up to date on what everyone else is doing.

So, what can I do to maximize my chances of being offered a position?

  1. Have a demonstrated track record of working on research projects–even course-type projects–and a research supervisor who is willing to write a one or two line email about how well you did.  That person need not be a faculty member, it can be a graduate student you were working with, a faculty member from a previous institution, etc.
  2. If the problem is one of funding, be willing to consider working for credit initially, with the informal agreement that if all goes well you will be first in line when more funding does become available.
  3. Don’t just show up and say “Do you have anything for me to do?”  Learn about the projects people are working on (often their PhD students’ home pages are more informative than the faculty home pages or even the group/lab home pages, so check all of them).  If they have recent papers that are accessible to you, check them out.  They are excited about what they’re working on, and will react more positively if you are too.  On the other hand, don’t feign excitement just to get the position, because it will quickly become obvious to everyone.
  4. Don’t spam people with identical emails.  If you intro yourself by email, do it in a personal way, offer to drop by in person, and provide enough background about yourself and why you’re a good candidate that you will in fact be invited to drop by in person.
  5. Talk to the PhD students.  They are on the front lines, and besides describing the project, may also have a better sense of what parts of it could use some extra assistance.
  6. Realize that people are really busy.  If you don’t get immediate responses, or the responses or short, don’t get offended and don’t give up.  For my own part, I consider every request individually, but I typically get several such requests per month (more at the beginning of each new quarter).  Sometimes it is not even a problem of funding but of supervisory bandwidth.
  7. For software-intensive projects: I often advise students to be wary of industry positions that make a big deal of requiring skill in a specific language or framework, since a good computer scientist can learn what they need along the way.  But, in an ongoing research project, the other project members may not have time to teach you.  So it’s good to be quite comfortable with a variety of languages and frameworks to maximize your appeal to software-intensive projects.  Working on extracurricular projects (hackathons, Blueprint, DeCal courses, etc.) is a great way to do this.

If I get a position, what can I do to make sure I’m invited to stay?

  1. Understand that whatever work you are doing is not a problem set or a homework.  Failing to make progress on it will affect the whole research group, not just your grade, and they won’t be happy.  Similarly, working 2 or 3 hours a day for a week is not the same as working 14 hours on Thursday night; most research groups rely on some regular progress to gauge what they are doing.
  2. Learn to work with whoever your colleagues are (other MS or undergrad students, PhD students, faculty member, etc.).
  3. Recognize that the group has a research agenda they want to advance.  They probably have spent some time thinking about this agenda.  You may have all kinds of interesting projects you want to pursue, and you should certainly talk to the faculty group leader about that, but at the end of the day their main goal in hiring you is not just to give you a chance to do research–it is to help their own research advance more rapidly.  Keep this in mind: you are part of a group that has an overall goal, and specific subprojects within the group have a specific goal.
  4. Take ownership of your part of the project as much as possible.  Remember it’s your responsibility not only to deliver but to be thinking about what comes next.  Again, the goal is not to “finish the problem set” but to move the agenda ahead.  The number of hours you put in is not nearly as impressive as the results you actually get in moving that agenda ahead, so be aggressive in thinking about where you could be improving.
  5. If there are working-relationship problems, address them sooner rather than later with the group’s leader.  If they are insurmountable, better to recognize that early than after a lot of grief has been caused.  If they are surmountable, the sooner the better.
  6. Everyone knows RAships are a great potential source for a recommendation letter from the faculty member.  But be sure you have done good work before asking for one.  (If you’re doing the RAship just to get a letter, you’re probably doing the wrong thing.)  A faculty member who is happy with your work will be more than happy to write a strong letter and may even encourage you to apply to the PhD program so you can continue in their group.  A faculty member who is not happy with your work will be very reticent to write a letter, and if this is the case, you shouldn’t push it–a weak letter will hurt rather than help your case.