Research mentorships are the basic building block of productive industry-university relationships. We asked four mentors from around the globe to tell us about the challenges, rewards, and strategies of serving as a mentor.
Linking a student’s research goals with the experience of a Red Hat software engineer is at the crux of the Red Hat Research program. Even formal partnerships with universities boil down to the one-on-one relationship between student researcher and industry mentor.
To find out what is involved in being the non-academic mentor of a computer science researcher, Red Hat Research Quarterly interviewed a few Red Hat mentors to discuss the hows and whys of these connections. Our mentors (see bios in insets) range from very seasoned to very new, and they work with students at universities in the US, Israel, and the Czech Republic on an array of projects.
Learning more about the dynamics of mentoring research projects will help us better understand the benefits and areas for improvement in research mentorship programs. After all, these relationships are uncommon in both commercial and academic settings. But they do important work by bridging these two spheres, translating knowledge and experience into insights that help student researchers’ work become more immediately relevant to applied computer science.
In the questions and answers that follow, we synthesized some of our findings while letting each mentor speak from their unique experience.
Josh Salomon is a senior principal software engineer at Red Hat working as an architect on Ceph storage systems. Based in Israel, Josh has worked on projects with professors and students at the Interdisciplinary Center (IDC) Herzliya.
Viktor Malik is a Red Hatter based in Brno, Czech Republic. Viktor has assisted thesis candidates at the Brno University of Technology, where he recently completed his PhD. His areas of mentorship range from VMs to kernel analysis and security.
Marek Grác is a senior software engineer at Red Hat Czech who has lent support to thesis projects at Masaryk University in Brno at master and doctoral levels on topics including networks and AI/ML.
Uli Drepper is a Red Hat Distinguished Engineer working on multiple projects as part of the Greater New England RIG. Uli currently advises on ten theses/dissertations at Boston-area universities, many of which are in the area of programmable hardware and the Linux kernel.
How do you package your advanced technical knowledge so that it’s shareable with students?
Mentors have a wealth of information to share, but they aren’t classroom teachers. Imparting what they know to their mentees is a matter of individual communication styles, learning styles, and coding styles that will likely differ in each mentor relationship. We asked mentors how they like to illustrate complex ideas for students. In some instances, merely simplifying the explanation of a concept is enough. Often, however, mentors find that showing rather than telling is a more effective way of helping a student learn a new idea.
Uli Drepper, for example, likes to write up code that implements a concept, then let the student have at it. Students can work with the code themselves until the concept is grasped to the point where they can apply it in their work. This is a very practical approach: it leads to results very quickly, something students appreciate because it gets their projects off the ground quickly too.
The problem is that students often end up with a basket full of cherries only to remember that their original goal was to collect apples. Even very talented students can get distracted easily, and it is the mentor’s role to keep them on track.
Josh Salomon prefers using the whiteboard to provide high-level diagrams that explain everything he needs to about a project. The whiteboard has long been one of the most natural ways for an engineer to explicate a concept. Unfortunately for recent mentorships, that option became a casualty of the pandemic. After COVID-19, he provided these explanations remotely, with a heavy reliance on documents and written explanations.
When a mentor has more actual teaching experience, their starting point might not be the subject matter, but the students themselves. After assessing students’ technical knowledge, Viktor Malik shapes explanations to match. He believes strongly in showing everything through examples of code so that the explanations are not abstract. Instead, students can see how something works in practice and start applying it to their own work.
Except when they can’t: sometimes complex concepts take repetition. When that happens, Viktor breaks things down into smaller steps and moves through them more slowly. “Students can become distracted by complexity,” Viktor said. But once they are able to move through the problem independently, “I’ve been surprised at students’ creativity and resourcefulness. Sometimes they come up with solutions I hadn’t considered that ended up being much better than my approach would have been.”
Even when allowing students to figure things out for themselves, there is a role for mentorship. Marek Grác likes to create a context for students to puzzle through a problem, which is also a great way to test motivation—are students willing to put in the work it takes to grasp computing concepts? Marek provides consistent support along the way by providing pointers as needed. According to Marek, “The best kind of knowledge I can provide is not necessarily the details of a particular subject, but a larger understanding of how to propose a hypothesis and then how to support it.”
With this approach, the mentorship is really based on dialogue: the mentor may provide suggestions, but conversations are mostly a back-and-forth sharing of ideas. That kind of collaborative mentorship can lead to unexpected results. For example, one of Marek’s mentees was working on a thesis about an idea for which Marek was the original researcher. Rather than playing the expert, Marek sent the student off to do their own exploration, which led to the student discovering new issues that Marek had been unaware of. Success!
How do you know when to step in and when to step back?
Finding the sweet spot between direct knowledge transfer and independent discovery takes patience and a bit of self-control. The temptation to make students’ lives easier by providing shortcuts or quick insights can be great, especially when a mentor is excited to help the student’s project come to life. The mentors we interviewed had clear ideas about when their assistance made sense.
Setting the design and technical parameters of a project is often done in a collaborative manner. A mentor has to realize that they might have their own vision for how a technical problem can be approached, but they need to allow the student to bring theirs to the table as well. Mentors preferred taking a hands-off approach to the students’ work once the big picture and goals were clear. The most common reasons for offering more direct guidance were to help navigate complex or unfamiliar elements of the open source process and to help students focus on the practical, applied outcomes of their work. After all, students choose to bring academic work to the Red Hat Research program explicitly because of this practical aspect, with the hope of having their work become part of actual enterprise solutions via the open source channel.
Once mentors have helped identify which open source project best aligns with the student’s work, they can help increase the likelihood that a student’s work will be accepted by the project’s maintainers. Some open source projects are quite complex, with multiple subsystems and layers. Students benefit from having someone to guide them through where to put the code, how to build it, and so forth. Josh, for example, is deeply knowledgeable about the Ceph project, but he was nevertheless grateful that one of the core Ceph developers was very keen to assist his student and guide her through the contribution process. However, how she actually wrote the code and solved technical issues along the way was up to her.
It is the nature of academic research to drill into a particular aspect of a problem and thoroughly understand it, but the student’s ultimate goal while working with Red Hat Research is to prove a hypothesis and finish the project. Marek finds himself reminding students of this goal as a way of bringing their focus back to the project at hand—and to the student’s long-term academic and career goals. It might not be in the student’s best interest to follow interesting research threads if their plan is to finish their degree and start working for a technology company. “When students are working on an open source project, they find that there is a big gap between what academia wants and what the open source community wants,” Marek said. “The community wants something that works well, and in academia they want something that is explained well.”
The student can then make an intentional choice whether to spend less time explaining a problem and more time on the practical solution; in the end, the practical application will have more impact for more users once it has been contributed to an open source project. For example, one of Marek’s students was working on reducing the energy consumption of a Wi-Fi chipset. His solution is now part of the Linux® kernel, which means it is implemented on millions of computers—indeed, every computer that is running Linux. From an academic point of view, this may have been an average thesis. But judged by its impact, it was an extraordinary technical contribution.
Marek also clarified that there doesn’t always have to be a conflict between practical and academic accomplishment. His solution is to have students take their more theoretical hypotheses and build an actual proof of concept as part of their projects’ outcomes. For example, a current project around optimizing bytecode in Java will probably take years to be implemented to the standards of the Java community, but a student can create a working prototype to prove out the solution.
What are some of the common challenges, and how do you help students surmount them?
Our mentors found that students’ work habits are another area where they can offer some useful guidance. Naturally, some students tend to procrastinate, leave things to the last minute, and then try to finish everything in a short span of time. Another common problem is students who try to do everything, which often leads them to stray from their original project intent or goals.
For procrastinators, mentors have tried a variety of strategies. First, mentors can help by leading students toward a realistic timeline. Students often don’t know how much time it will take to complete such a long-term task, and it frequently takes more than expected. Mentors can help set appropriate expectations from the start, for example, by requiring thesis projects to run at least two terms (one year). Second, task management and regular guidance are important, especially with students who tend to wait until the last minute, so they don’t fall behind. Setting shorter-term milestones for the overall project and providing counseling as needed can make a big difference. Actually passing these milestones and getting the work done, however, is left purely to the student’s own dedication.
Trying to do everything tends to be a problem of overeagerness, and it is a much more pleasant problem to have. “Many students like to build things from scratch,” Uli observed, “which has obvious benefits, because it takes away constraints. But in real-world work settings, few people get to do that.” Most work in IT consists of building on existing foundations. Uli added that a mentor should remind students that they need to ground themselves in doing a few things really well rather than many things badly, and go step by step to achieve that.
Marek usually discourages this type of student from being too creative once their goals have been set. When a project begins, there often seems to be lots of low-hanging fruit. The problem is that students often end up with a basket full of cherries only to remember that their original goal was to collect apples. Even very talented students can get distracted easily, and it is the mentor’s role to keep them on track.
While mentors emphasized encouraging independent work, one of the most common issues they have is that students are afraid to ask questions, typically because they think they will look silly. A mentor can be a great informational resource, but to get the most from the mentorship a student needs to get over this fear. Instead of pushing students to ask, Marek turns the situation around. His students know a lot about certain subjects, so he simply asks them. That shows them that he, too, doesn’t know everything, and that we are all learning.
What’s the reward for you?
Red Hat’s entire academic program is built on the work of volunteers who have to find time to carry out all these mentorship tasks. So why do they do it?
The first answer was unanimous: our mentors enjoy teaching. That is no surprise. “Helping people succeed comes with immense satisfaction,” Viktor said, and most mentors would likely agree. Marek added that he enjoys staying in touch with new ideas, and that often means straying off the beaten path. Mentorship allows him to see what’s happening in different disciplines and not concentrate too much on one thing. “The world needs not only experts, but also connectors,” he said.
Uli noted another benefit that has long been a part of our academic programs: connecting demand with supply. The IT industry has no shortage of problems that need to be solved, features to be added, or tasks to be completed, and engineers often have to prioritize which are the most critical to the success of the project, product, or company. This leaves a lot of problems to be solved in the backlog.
The mentorship relationship creates a win-win situation: many items on engineers’ backlogs will never become a high industry priority, but they can be a basis for an interesting project and a learning experience for a student, especially under the proper guidance of a mentor who understands the problem. The work gets done, and the student comes out with valuable experience working on something real that may even get into the upstream. This important connection between university and real-world engineering would not be possible without a mentor’s help.
To learn about the projects that are currently supported by Red Hat mentors, visit the Research Directory.