5

I am a postdoc and I would like to know how to mentor PhD students:

Goal: Make the student as productive as possible so that he can reach his highest potential and provide us as much results as possible.

The student is smart, has no big personality flaws as far as I know. I was told by my boss that he is into gaming and that I have to push him so that he delivers. I do not want to micromanage him, I have heard that doing that is bad. Some say that we have to let the students figure things out on their own. However, when I let the student figure things out on his own, he will get stuck for days on something trivial. When I find out what he has been trying to do, I think

"Why did not you ask me before, you wasted days on this and we could have solved it in a few minutes"

So, there is this potential of the student wasting time but also the fact that they need to do it themselves to learn. Also when I go through his code I find stuff that I do not like, that is not well done. So I want to change every little thing he does, this is again micromanaging. On the other hand I do want things to get done properly and if I am going to change everything he does, then I might do everything myself, because it pretty much takes me the same amount of time. Then I do not know why we would pick a student to help us. However we cannot do this alone, it's too much work and we are supposed to mentor students and produce PhDs, it's even good for my CV to show that I mentored students.

I am not sure how to deal with this, there are many factors at play and I would like to know how people here deal with these problems.

Cheers.

2
  • 1
    What field? What part of the world?
    – cag51
    Aug 3 at 2:25
  • "I was told by my boss that he is into gaming and that I have to push him so that he delivers." Are these supposed to be related? Or just two different thoughts? Aug 3 at 15:30

2 Answers 2

2

I am a PhD student who is currently polishing up his thesis for submission. Here is how I think it should have been done.

Assume that they know nothing about academic work. You can even tell them that, if you do it in a nice way, they will understand that you are simply take care that they know the basics. Unless their Bachelor/Masters program specificaly teaches how to work in academia, they will have absolutely no idea. At our university only psychology students actually understand the scientific method, and only molecular medicine/biochem students are prepared to work in their respective fields. The rest learns facts and math. What I mean by that specifically is:

  • They do not know how a paper is structured and why it is done the way it is in your field. What belongs in the introduction? What belongs in the discussion? Andy why? Etc. Take a good paper, and go through it. Then take a couple of bad ones (maybe student submissions), and make them point out mistakes to them.
  • How do you find a research idea? (Relevant only after the first project)
  • How do you actually research a question? Some might never have used google scholar, and do not even know that you can look up "cited by". Why should you always try searching for a review? How do you stay up to date in a field? What are the top journals/people to pay attention to?
  • What tools are there? They might be obvious to you, but they are not to them. Google Scholar, Connected Papers, Zotero with all Plugins, etc. Whatever you use, show them.

Then, to start them off, give them a clear project, with a clear goal. They have no idea what is relevant in the field, and neither should they. A review of a very narrow field might be a great place to start.

My personal preference: Allow them to send you rough drafts. My prof wanted to see an almost polished version of everything, which meant that I wasted so much time ...

Once they wrote the first paper, they probably should be able to come up with original ideas and be very productive, and you will not need to guide them, but will be instead working as peers.

Make sure they are not afraid to come to you with ideas. If they have a very stupid one, explain why it is not feasible, instead of dismissing it. Never use your taste/experience as a reason to dismiss something without a good explanation. If they are afraid to come to you with ideas, they will not be having fun, and you will not be happy, trust me. This also goes for teaching. If they want to try a new method, either explain why you think it is not feasible, or just let them try it, and maybe crash and burn.

1

The title question is certainly too broad for an answer here: books have been written on effective mentorship. Instead, I'll focus on your comments about micromanaging.

I was told by my boss that he is into gaming and that I have to push him so that he delivers.

Set frequent goals. Let's do X by tomorrow and Y by the end of the week. If they meet these goals (or have convincing reasons for what they tried, where they got stuck, and how they tried to get unstuck), then there is no issue. As they come up to speed, they will start setting these goals for themselves and you can step back.

If they are frequently turning up with minimal progress, then you might consider some set working hours (e.g., 1-5 on MWF). This is not meant to be punitive, but helpful -- if they are just down the hall from you, you can check on them often and probably greatly speed things up. If there are other peers they can sit with, so much the better. Once the project starts moving, it becomes fun, and they will likely stay engaged on their own.

However, when I let the student figure things out on his own, he will get stuck for days on something trivial. When I find out what he has been trying to do, I think "Why did not you ask me before, you wasted days on this and we could have solved it in a few minutes"

Beginning students do not know what is trivial, what is tractable, and what is hard. They similarly do not know what already exists versus what they need to do from scratch; so, they may spend far too long reinventing the wheel. Some inefficiency due to this is inevitable.

The solution is frequent, brief check-ins and/or asynchronous chats. Impress upon the student that if they're spending more than a few hours doing something, you should know what it is. That doesn't mean you need to micromanage their time -- if they are reading a paper and implementing it, that could take a week, and all is well and good; schedule a follow-up for a week later. But if in the course of this, they spend more than a couple of hours trying to understand a particular equation, they should ask you about it and get your concurrence before spending additional days trying to figure it out on their own. They'll eventually get a better sense of when to come to you versus when to dig in on their own.

Also when I go through his code I find stuff that I do not like, that is not well done. So I want to change every little thing he does, this is again micromanaging. On the other hand I do want things to get done properly and if I am going to change everything he does, then I might do everything myself, because it pretty much takes me the same amount of time.

Code is tricky for the reasons you mention. I have found a few guidelines.

  1. Never debug your student's code.

    • If the code doesn't work at all, they should figure it out on their own or with their peers. At most, you can have them explain it to you; this may reveal conceptual problems that you can explain on the whiteboard.
    • If the code does work but the results are not reasonable, you can ask for cross-checks. Explain why you are skeptical and suggest some tests that will either make the error apparent or will allay your suspicions.
  2. Never edit your student's code.

    • In most fields, most code is "private": everyone writes their own. This holds also for your student -- they should be giving you only qualitative outputs like charts, figures, or tables. The code they use to generate these is entirely their own; you never edit it, download it, or (in most cases) even look at it.
    • In other fields, some/most code is "shared": the lab has a complex codebase that everyone contributes to. In this case, your student's code will have to meet the group's quality standards -- but again, you should limit yourself to explaining what the problems are. You should be able to articulate the problem, even if it's just stylistic, and they can fix it from there.
  3. Give lots of feedback

    • Similar to your comments above, students can spend hours writing a simple script that you could have written in minutes. Part of this is experience, but much of this is workflow. Students won't even know what a good workflow is until someone shows them.
    • "Research code" has its place, but it would be good if students had at least a vague awareness of higher concepts such as data structures, memory management, scalability, profiling, version control, IDEs, Linux and its native tools, advantages of different languages, etc. It is a real shame when students spend thousands of hours coding but never really get beyond functions and loops.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .