If done right, undergraduate research is a mutually beneficial collaboration that leads to great results. If done wrong, it can make people feel undervalued, discouraged or even disgusted with research.
I’ve had the privilege to mentor nearly a dozen undergrads over several years. We’ve done great work together and published several papers at top venues, but I consider our biggest success to be the strong collaborative relationships that we’ve built along the way.
Here is a mentorship strategy that I have found to be effective.
Note: I work in machine learning, so the advice is in the context of research on algorithms and computational methods. Some elements may apply more broadly, but traditional lab-based scientific fields differ in critical ways from computer science. See the note at the end of the post to understand the relevant differences.
Before we talk about how to mentor students, we first need to understand the goal of the mentorship process. What are we trying to achieve?
Undergrads primarily benefit from the research experience by learning new skills. They can:
There are also costs. Research can be time-consuming and stressful when the student also has a demanding course load or part-time job. Undergrads might also face opportunity costs when choosing between research and an internship, elective, study abroad, co-op or other program.
Mentors benefit from the results of undergrad work but also develop new skills through the mentorship process.
Of course, training represents a substantial up-front cost for the mentor. In some fields, it can take months to teach the skills needed for a meaningful research contribution.2 Inexperienced researchers can make mistakes that hamper progress and incur large financial costs.
The goal of undergraduate research is for both parties to benefit from the experience. The benefits won’t always be equal, but everyone needs to be satisfied with the arrangement. We want a mentorship strategy that maximizes the chance of this happening.
My plan for a mutually beneficial research experience goes through five stages.
Each phase requires a different focus. During recruiting and project matching, we want to inspire prospective students, impart a high-level overview of the field and provide context for the student’s potential contributions. The next phase will see the student learn new ideas and develop essential skills, ideally in parallel with actual research assignments that make progress toward the project goals. As they gain confidence and autonomy, the blockers of progress shift from lack of knowledge to lack of resources and direction. Therefore, our mentorship focus needs to smoothly transition from teaching skills to managing milestones. After enough progress, we may want to write a research paper. As this requires a completely different set of skills, we must return to a teaching focus.
Undergrads can get involved in research in several ways. One successful method is to recruit students directly from an undergraduate course. This is how I originally got involved in research, and it’s particularly effective when the course involves an open-ended project. During my PhD, many undergrads joined our lab by extending their final project beyond the scope of the course.
If this isn’t an option, I’ve known groups that advertise with student email lists, posters and word-of-mouth. While it’s tempting to impose course pre-requisites or other criteria on applicants, I believe that motivation is the single most important factor among candidates.3 A highly motivated student will find a way to learn what they need to contribute.
No matter where we find our prospective students, it’s critically important to have an orientation meeting. After the meeting, students should understand the following items and be excited about the possibilities within the group. This should take about an hour.
At the end of the meeting, I ask the student to schedule a meeting to discuss possible project options. During the meeting, I make sure to hit the following points.
I begin by pitching undergraduate research as a great experience. Students already have an idea about why they want to participate in the lab, but it’s helpful to explicitly mention the benefits - after all, they may not have realized all the advantages! I reinforce this by mentioning the success of past undergraduate alumni. For example, we’ve had first-author undergrad publications at NeurIPS and sent students to PhD programs at top schools.
This is also a good time to extend a warm welcome to our group and to briefly explain the kind of research that we do. Our lab works on problems that are very important to industry, so I usually highlight the transferrable skills that students will learn. For example, many rewarding roles in the tech industry require the candidate to implement algorithms in C++ / Python and clearly communicate the results in writing.
Different students hope to get different things out of a research experience. By understanding what the student wants, we can often improve their fit within our group.
For example, if the student plans to apply to PhD programs within six months, we can maximize the chance of publishing by having them help with an existing project rather than explore a new idea.4 If a student has multiple years before graduation, it might be better to select an open-ended project with many possibilities for extensions. If a student is a freshman, we may need to allocate more time for teaching fundamental skills.
When possible, I try to have this conversation on an individual basis. My goal is to tailor the experience to be as beneficial as possible for each student. Here are some useful questions to ask:
The orientation meeting is also a good time to address concerns about authorship and author order. While it may seem premature, I think it’s best to agree on a policy from the beginning so that everyone knows what to expect. It goes without saying that undergraduates should be co-authors on any paper that uses their code, ideas, results or writing. Also, the graduate student mentor is usually the first author, since they’ll probably carry the project and write (or rewrite) the submission.
However, I recognize two levels beyond co-authorship that signify higher contribution levels. Here is my authorship policy for undergraduate researchers.
There are three situations where I deviate from this authorship policy. The first occurs in fields like theoretical computer science, where the author order is alphabetical. Second, it’s standard practice for the mentor to take the last author position if they are not a graduate student or postdoc. Finally, senior undergraduates may occasionally approach you about advising a project based on their own ideas. This should be treated like any other research collaboration, where they set the authorship policy.
It is important to establish a baseline expectation for the amount of time the student will dedicate to research. I have found that progress is unlikely with less than 10 hours of focused work every week. The ideal situation is 20 hours a week, or the equivalent of a part-time job.
The reason is that a large amount of research exposure is required to learn the skills, build confidence and ultimately become a productive member of the lab. I encourage attendance for anything that increases this exposure - including lab meetings, guest lectures, training sessions and thesis defenses. These events are beneficial even if they do not directly relate to the project the student is working on.
We will take a deep dive into project timeline and scope when we get to the project selection phase, but the orientation meeting should briefly address the amount of time needed to get results in the field. Many machine learning projects can go from a validated idea to a publication draft in 6 months (with an additional 6 months for submission and revisions). Life science papers often take several years to be published. We need to be honest about the timeline so that students do not have unrealistic expectations.
Most undergraduate institutions allow students to earn elective credits toward their degree by working in a research lab. Some labs are also able to pay undergrads with grant funds. Of course, students can also volunteer without being paid or getting university credit.
Our job as mentor is to make sure that students are aware of the options and expectations surrounding compensation. The expectations can differ depending on the type of compensation. For example, if a student is volunteering then there is usually no problem with taking a week off to focus on midterms and finals. If the student is being paid, then we expect them to be present during important deadlines and experiments. If the student is getting credit, we might need to prepare a report for their final grade evaluation.
Note: If you are a graduate student mentor, do not promise compensation or credit unless you can deliver. At the same time, make an aggressive effort to compensate and care for your students. One way to make them feel supported is to let them see your efforts - for example, by including students on emails with HR, IT, tech support and your PI.
Project selection is probably the most important step of the process. If we pick the right project, the goals and results will naturally flow in the right direction. However, not all projects are alike - some are much better candidates for a new researcher than others. How do we find a good project?
The project selection phase requires some time investment from the mentor. Fortunately, most of the work can be done once and re-used with multiple students. Here is what we need before scheduling a project selection meeting with a student.
Uncertainty: Research is unpredictable, and there’s no guarantee that a project will work out. I would estimate that less than 5% of my actionable ideas develop into a successful project. This is the reality of research, but it can derail a student’s enthusiasm. For this reason, we need to screen ideas before offering them to undergrads. The prep work is designed to improve the success rate and give students a good experience.
The screening process doesn’t need to involve extensive experiments or results. We just need to confirm that the project is free from any easily-avoided roadblocks that make it impossible. An experienced researcher can often form a conclusion within two days that would take a new researcher two months. For example, I usually validate algorithms on toy problems in Python before asking undergrads to implement the system at scale in C++. We can often calculate simple data statistics or run tests to determine whether a result is possible. We might spend an hour searching the literature to confirm that there are no serious hang-ups.5
By doing this simple screening process, about 50% of my projects with undergrads have had good results. This is still unpredictable, but it’s much better than a 5% yield rate.
I’ve found it’s best to offer people a choice in how they’d like to contribute. While it isn’t always possible to accommodate student preferences, I start the project matching phase by asking about their background. I often use the following questions (specific to computer science fields).
Based on the student’s answers, I select 2-3 project options from the list and present them during the project selection meeting. This meeting takes about an hour and serves as a detailed introduction to the work the student will do.
Sometimes, this isn’t a practical way to match a student to a project. They might want to work on a specific topic, but our options all focus on different areas. It’s also possible that we only have one opening available, so we can’t offer a meaningful choice. In these cases, it’s still a good idea to ask what the student thinks about the project. Even if there is ultimately no difference in the outcome, people feel a sense of ownership and autonomy when they are presented with a choice rather than an explicit work assignment.
It’s great when we can perfectly match someone’s pre-existing skills and interests, but this is ultimately not very important. New researchers are still developing their interests and area of expertise. I’ve found that if someone is excited about one idea, they’ll probably also be excited about many other topics that they just don’t know about yet. What matters is that you ask for their input, because this makes people feel that you are taking their perspective into consideration.
It should be possible to complete a minimum viable project within six months. The end product does not need to be a paper capable of getting into a top-tier publication venue - the project just needs to be reasonably complete. For example, we might ask the student to produce a bug-free (but not optimized) implementation of an algorithm, but leave the extensive comparison with state-of-the-art methods for later. In the life sciences, we might expect to have an experimental setup that has been validated by reproducing basic results. If the student continues to do research in the lab, they can build on this result. If the student leaves the lab, the result should still be useful to someone else.
Eventually, the student will begin to set their own research goals. However, it’s good to have a few early milestones planned out at the beginning. In my field, a good early milestone is often to load a dataset or implement a baseline method. In my undergrad lab, my first milestone was to measure the electrical properties of a sensor.
The project should not be urgent. It will take a month or two before a new researcher can contribute in a way that saves time overall. If the project has an upcoming deadline, someone with experience should do the work.
Finally, the project should not include a literature review. The mentor should have already completed a literature review and determined the idea to be novel and reasonable. Literature reviews are a boring and passive way to begin a research project. While new researchers do need to find and read scientific articles, this can be learned in parallel with practical lab skills that provide essential context for the literature.
First impressions: This meeting is a chance to make a good first impression. As mentors, we want to come across as accessible experts with solid research plans. I try to wear a nice shirt and bring an organized set of project notes on a clipboard.
Project choice: It’s possible for the mentor to strongly influence project choices (e.g. by flat-out suggesting a project or by highlighting the advantages of one option against another). This is fine, provided that it’s done with the student’s wellbeing in mind. For example, it is fine to advise the student against pursuing an exciting but difficult niche project where they may struggle to make good progress. It is not okay to misrepresent the opportunity to get help with labor-intensive experiments.
Running the meeting: Project selection meetings should last about an hour and cover 2-3 potential projects in depth. When introducing the projects, focus on the broader impact and skills that can be learned through the project. The meeting is best done in-person with a whiteboard, but they can be done remotely. For remote project selection meetings, it helps to make a few slides for each project.
Call to action: After the meeting, I typically email the project descriptions and literature references. I ask the student to select an option and schedule a recurring weekly meeting. At the next meeting, we begin work on the project.
Once we’ve selected a project, the next step is to guide the student through some early milestones as they build their skills and confidence.
I typically do this through one-on-one weekly meetings. These meetings don’t have a fixed agenda - we use them for general advising, teaching and project updates. Most of the early meetings will be informative in nature, with the mentor answering questions and giving short lectures to explain the parts of the project. As the student progresses, the focus will shift to weekly goals and progress updates.
Some labs (and companies) subject new contributors to extensive training before they are given a real task. I’ve experienced this approach from both sides, and I think it’s a slow and ineffective onboarding method. Ideas are introduced without context or motivation, and people don’t feel like they’re contributing anything during the training process.
Instead, I think it’s best to learn while working toward early goals. We can encourage this by setting a modest but meaningful first goal, such as successfully using a piece of lab equipment or getting some software to run. Some students want to build a solid foundation before applying the ideas, which is understandable as this is how most undergraduate courses are structured. However, cutting-edge research requires so much background knowledge that a student can spend months learning prerequisites that might not be relevant until much later.
Metaphor: I envision background knowledge as a giant snowdrift that we need to cross. We can take a methodical approach, shoveling away all the snow in strips and chunks. Alternatively, we can cut a straight path to where we want to go. We’ll get where we’re going a lot faster if we only plow the path we need - with enough crossings, we’ll eventually clear the rest of the snowdrift anyway.
In my experience, it is better to exhibit a strong bias toward action and begin working as soon as possible, learning only the materials needed to take the next step. After enough steps, we’ll have both the background knowledge and progress. There will be gaps in the background knowledge, but a good mentor can identify and fill these gaps when there is an opportunity.
Note: In lab-based sciences, safety trainings are often required before the student is allowed to set foot inside the lab. Sometimes, there are also formal trainings for specific lab instruments. Obviously, these skills should be learned ahead of time when the training is offered. However, the vast majority of research skills can be learned as needed.
Our goal is for students to develop deep intuition and understanding, but this can only come with experience. At the beginning, there will be some parts of the project that are complex and overwhelming. In most cases, those parts can be skipped or at least deferred until later.
For example, theoretical research is fairly abstract and requires a strong math background. The answer to a theoretical question is often a proof technique that a student hasn’t seen before. While it’s definitely possible for students to discover these techniques on their own, it’s often more advisable to select practical tasks where they can begin making progress right away.
The difficult parts of the project can almost always be postponed until we have more background information. By prioritizing easy progress, we quickly build confidence and knowledge.
Here’s an incomplete list of skill categories that you might want to consider teaching. Readers from other disciplines should note that many topics are specific to machine learning.
Many teaching sessions will organically come from questions asked by the student. Our goal is to teach everything that’s needed to take the next step and meet the next milestone (and no more).
Progress rate: Progress will start out much slower than expected. For example, it might be two weeks before a new researcher can load a dataset or train a model. Productive experiments will take at least a month. It’s tempting to accelerate progress by doing some of the work yourself, but teaching and training are better long-term.
Milestones: Try to avoid setting ambitious milestones, at least at the beginning. It’s better for a student to find the first few tasks easy than for them to be overwhelmed. Remember that straightforward tasks can still be difficult when you’re doing them for the first time. In computer science, even something as simple as SSH server access or GitHub can present a challenge for someone who has never done it before.
Provide context: New researchers lack the context that comes from years of working in a research field. They’ll quickly grasp what to do, but they often won’t know why things are done this way. We can provide context by exposing students to older techniques and methods, explaining the long-standing problems in the field and teaching the theoretical ideas that form the basis for their work.
Make things explicit: Experienced researchers take lots of steps without realizing how much they are doing. Junior researchers can get hung up on steps that the mentor finds obvious, such as finding research papers and using the standard tools of our field. The solution is to be as explicit as possible and encourage questions.
Anticipate needs: Every project is different, but some needs will be common among all students. For example, everybody needs access to lab spaces, servers, equipment, safety training and other resources. It’s best to start on this in the first few weekly meetings before they become a bottleneck.
No bad questions: People need to feel secure when asking questions. As mentors, we need to work hard to foster a non-judgmental environment where questions are encouraged and handled respectfully (no matter how basic the question).
Over time, the focus of weekly meetings will shift from teaching and providing literature references to planning experiments, reviewing data and suggesting future directions.
Some people benefit from the structure of a weekly report. Written reports have the following benefits:
My undergraduate mentor insisted on a 1-page weekly Word document, which worked very well. This document-based meeting strategy is also a core part of Amazon’s meeting policy, and I’ve used it in my own meetings for several years. However, with undergrads I often relax the requirement to an email, since the process of writing a full report takes time that could be spent elsewhere. The two times that I insist on a written document are when reporting experiment results and when working on theoretical proofs. Here, it’s indispensable to have a written resource for reference.
Some mentors request a few PowerPoint slides every week. I find this ineffective because students put too much effort into making and delivering the presentation. In a meeting, slides can almost always be replaced by notes, screenshots, figures and whiteboard drawings. Reports are more productive because we can spend the entire meeting time in discussion.
Tip: Make sure the student understands that the weekly report is just for communication. A few bullet points will suffice. Students should not feel pressure to write a long, polished report every week.
Early on, we set lots of small, highly-specific goals. As the student develops expertise and independence, a more collaborative approach is in order.
It’s important to recognize that not all students want to become independent researchers - some people are happy to take directions and help out with experiments. But undergrads don’t have to design experiments or choose research directions to benefit from autonomy.
My strategy is to slowly increase the scope of the weekly goals. Where before we set a weekly goal to run a specific computational method, now we might ask for multiple runs on several datasets. Going forward, we might ask the student to construct an easily-run benchmark that compares several methods on multiple tasks. Once the student has been exposed to the scientific literature, we can even ask for short summaries of papers. None of these tasks constitute independent research, but they all contribute in greater ways to our project.
Ambitious students might eventually want to tackle their own research problems. We can prepare them for this by exposing them to recent ideas in the literature. For example, we might ask them to identify (and implement) the leading experimental methods for a problem, or to compare the results from recent studies. Ideas that arise during this process can be integrated back into the weekly goals, to allow students to pursue some of their own hypotheses.
Ideally, every project ends by submitting a paper to a top venue. However, students should document their work even if the research experience does not produce enough material for a full article submission. I start this conversation about a month before the student’s projected end date.
I ask all of my students to prepare an internal report at the end of their research experience. The goal of the report is to explain their work with enough detail that someone else would be able to reproduce the results. Because undergrads are already familiar with writing reports for class, the format can resemble a term paper or final project report. This is beneficial for the following reasons.
Note: If you are planning to write a paper with the undergrad, the report can serve as raw material for a first draft. There is absolutely no harm in writing one, unless you need to write the research article directly due to deadline pressure or timeline constraints.
Undergrads should be invited to participate in the writing process if possible.
Technical writing is a skill that improves with practice. While not every undergrad will need to write peer-reviewed research articles, everyone will need to clearly communicate complex ideas. If they want to attend graduate school, they will need to write papers, reviews, letters, proposals, abstracts and research statements. If they plan to get a job, they’ll still need to document their work clearly.
That said, writing can be stressful and time-consuming. In computer science, conference paper submissions often involve insane amounts of overtime around conference deadlines. In other fields, a manuscript can require months of work and a half dozen drafts before it’s suitable for a journal submission.
Note: By “research article,” I mean a full-length submission to a publication venue. In some fields, publication is done through journal articles that may be submitted and reviewed at any time. In others, it’s done through a series of conference proceedings that have strict deadlines throughout the year. Smaller venues, such as computer science workshops and conferences in other fields, are typically much less intense.
This advice is heavily biased by my own writing process. My approach is to begin with a loose outline and write as much content as possible, then reduce the volume through aggressive editing. After several cycles of writing and cutting, we are left with a high-quality manuscript.
This process allows me to easily integrate writing from undergrads at the editing stage. I typically ask students to write the methods and results sections, as these directly relate to their work and do not require extensive background knowledge of the literature.
If the student has strong writing skills, large portions of this content will be directly usable. If not, they’ll still benefit from the practice. What’s more, students get to see the changes that we made to their writing, which acts as a form of feedback.
My undergrad mentor handled writing much differently. He simply asked that I submit a complete paper submission draft for his review, which took me several months to write (as it was my first time). He provided extenensive comments, which I addressed in a revision. After 5-6 iterations of this process, we submitted the paper to a journal. While this method is probably better for teaching writing skills, it takes a long time - nearly a year. I do not use this process with my undergrads due to the aggressive conference submission deadlines in computer science.
We’ve presented a five-step plan for managing undergraduate researchers. In many ways, the undergrad mentorship process resembles the apprenticeship process used in graduate school to train PhDs. The scale, however, is smaller and the teaching is typically much more hands-on. We begin by exposing students to the advantages of research, providing the context for their work and teaching essential skills. We finish by efficiently managing the project and setting goals for the student, culminating in written documentation of the work.
We need one meeting for orientation, a second for project selection, and a third meeting to establish a pattern of weekly advising and updates. The first three meetings act as a form of onboarding that helps students quickly find their place in the group. Once we are past onboarding, things generally settle into a pattern of weekly goals, questions, teaching and progress updates.
When a project finishes, consider taking the following steps.
This post was written based on my experience working in computer science - specificially, on machine learning research. Different fields have different norms that can substantially affect the undergraduate mentorship process.
Some research fields have a high innovation cost. For example, a biology researcher can consume $15k of reagents in just a few days. In this kind of setting, it’s hard for undergrads to explore ideas due to the financial risk associated with an inexperienced researcher. One way to offset this problem is to have undergrads perform data analysis. Many analyses can be done cheaply on a consumer laptop, allowing for experimentation and exploration without large financial costs. This is particularly effective when we have already collected a large dataset because data analysis can generate new insights without needing to engage in expensive data collection. When I joined a bioengineering lab as an undergraduate, my ideas focused on new software methods to analyze existing data. This allowed me to skip a 2-3 year data collection delay and begin exploring my own ideas immediately.
Some research fields require a long time to run experiments. For example, microbiology studies often require cell cultures that take weeks to mature. Longitudinal studies in healthcare can take years or even decades. To study communication systems or microprocessor architectures, we have to design and manufacture electronic circuits - an expensive and time-consuming process. For this reason, it is common to see undergradate-led computer science projects but rare to see primary undergraduate authorship in other fields. In these fields, undergraduate contributions often take a different form.
Computer science largely follows a conference publication model. In this model, conference papers are the primary driver of scientific dissemination and career advancement - journal articles are generally an afterthought. This has important implications for undergraduates because we get paper acceptance decisions within three months of submission. Although the norms are slowly changing, there is no concept of revision or resubmission. After a one-page review response (and at most a single paper revision), we simply submit to a different conference.
This fast-paced publication process means that a student might experience three or four review cycles per year. A large research group can submit several papers in each cycle, allowing undergrads to join projects at any stage of completion. Students can pick up lots of writing experience and try several different project options. In contrast, journal-based fields might have a review cycle that may last several years. For example, several papers that I wrote as an undergrad were not published until I was halfway through graduate school. In these settings, undergraduate researchers can expect more skills training and far less writing.
When I was an undergrad, I had a truly exceptional experience with Asghar Lab at Florida Atlantic University. Our work led to multiple papers (two of which were based on my own contributions). I developed algorithms that won awards in entrepeneurship competitions and were later patented by the university. But the most important results were the programming, product design and research skills that I learned. These skills laid the foundation for my career. ↩
For example, it took me six months to develop the dexterity and hand-eye coordination to assemble microfludic devices and manipulate a multichannel pipette. ↩
I started doing bioengineering research when I was 17 with a ton of enthusiasm but absolutely no background whatsoever. Within two years, we had written three papers. I’ve seen similar situations play out with freshmen and sophomores that I’ve mentored. ↩
In my field, projects take roughly six months to go from a promising idea to a viable first-draft. In other fields, the timeline is even longer - biology projects often take years to mature. ↩
In my field, it is beneficial to check for information theoretic lower bounds and to read the workshops of negative results at NeurIPS and ICML. If you can mathematically prove that a result is impossible or find someone else who ran a similar experiment, it can save a lot of work! ↩