advisor - What are the key components of being an effective supervisor of undergraduate researchers?

Quite a few tenure-track job ads I've come across recently have mentioned supervising research of undergraduate students as one of the position responsibilities specifically. I have had plenty of opportunities to supervise graduate student research activities, but have no experience supervising undergraduate research.

Personally, I never took advantage of opportunities to do research as an undergraduate (as an engineering undergraduate student, I was more focused on doing internships). So, unfortunately, I don't have any personal experience on "the receiving end," so to speak, to draw upon for what makes a good (or bad) approach to undergraduate research supervision.

My question:

What are the key components of being an effective supervisor of undergraduate researchers?

If the field of study matters, this is in engineering (in particular, electrical engineering, and some of the job ads I've seen combine research supervision of both the electrical engineering and computer science undergraduates).

Somewhat related:

What are the main differences between undergraduate, master's, and doctoral theses?

Answer

I have had some pretty good success advising undergrads by:

• Making sure that the problem is extremely well-defined. That is, don't throw them into the water and see if they swim. Think a lot about what the expected outcome will be, and what the foreseeable steps, challenges and problems will be. Yes, this is a lot of work and means that you could (almost) "do the work yourself" in the same time, but for undergrads you can typically not yet expect that you can just drop them a research question and see them run with it.


• Have regular meetings. Make sure that there is progress, and if there isn't, make sure that you know what the blocking issues are. Don't expect them to necessarily come to you first with any issues. In my experience, undergrads often are a bit shy about asking for help, and sometimes get stuck on (for you) relatively easy problems unnecessarily.


• Make sure that you would be able to do the project yourself given enough time. I know that this is somewhat controversial, but for grad students, I am perfectly happy to accept projects where I myself wouldn't know how to do every part myself. That is, I expect a grad student to be able to solve her/his own problems. For undergrads, I do not do this. I want to be able to help undergrads in a meaningful way if they get stuck, technically.


• Conversely, make sure that the work is not just random grunt work. In my experience, the best way to make sure that the undergrad research project is not interesting for the student is by letting them do something that everybody else either considers unimportant or terribly tedious to do. Undergrads are not yet experienced, but they are still colleagues and not some sort of scientific minions.


• Somewhat related: make sure that you are excited about the project, or at the very least be able to convincingly pretend that you are. Again, having the feeling that nobody cares about their project is a surefire way to make for a terrible research experience.


• Integrate the undergrads into the lab. When there are talks, the undergrads are invited (i.e., expected to come). When the grad students are expected to regularly speak in the internal seminar, the undergrads need to do this as well. If there is a regular lab beer night, the undergrads are invited as well. If the lab usually goes to lunch together, the undergrads are asked to come along. You get the idea.


• If at all possible, give them a fixed work place in the lab, and require them to be there at least some percent of the time.

To summarize, the best undergrad projects in my lab always worked on a well-defined project, which was still an integral part of the research agenda for the lab that others were enthusiastic about. On concrete example from my research: some members of my lab are currently working on benchmarking compute cloud providers. That typically means hacking up some automation scripts, deploying benchmarks, gathering some data, and analysing the results. This is rather tedious and error-prone work. Hence, I got a computer science bachelor student to build a web-based platform, which students could use to define, schedule and execute benchmarks using a relatively simple DSL (domain-specific language). The platform the student built technically wasn't terribly complex, but the solution worked well, tackled a common community problem, and most importantly saved multiple grad students a ton of time. We also published the tool as open source software and wrote a small paper about it, allowing to student to go to a conference to another continent. During the conference, a number of professors asked the student for details on his tool, and expressed interest to also use it for their research.