Error: no such theme PatternSkinTheme

Tips for CS Tutors and Mentors

Thanks for serving the CS department and your peers by serving as a tutor or mentor. You make a big difference in making our program more successful. We hope that this document will make your job easier.

Report Forms

Before You Begin

Different courses have different policies on how much help is appropriate. Make sure that you check the ClassPolicies page to see what help is appropriate.

All CS courses require that students cite the help that their tutor or mentor gave. Please be sure to remind the student to cite you.

Remember that although students will want you to just "solve the problem", your main goal is to help them develop the skills to help them solve future problems on their own.

Expectations of CS Evening Tutors

Read the course Web sites for CSC 151 and 161 regularly so that you know what material has been covered to date and what students are working on. (If you are getting questions for CSC 105 and 207, you should also check those pages.) Please do not teach students material that has not yet been taught in the course. (E.g., Don't have them write a recursive solution if they have not yet used recursion. Don't use pointers if they haven't learned pointers yet.)

Your primary goal during your hours is to support your peers. If your shift is quiet, please spend some time reviewing the current assignments in 151 and 161. Once you've done that, you may do your own work. However, if it seems quiet, please stop frequently to check the room. Someone might need help but might not want to interrupt you.

Please make sure that everyone checks in. It's important that we keep track of usage!

If, for some reason, you cannot attend one of your shifts, please find another tutor who can cover your shift for you. Please inform Allison Vosburg [vosburga] and Samuel A. Rebelsky [rebelsky] so that they will be able to match hours worked.

At the end of each session, you should send a short report on your shift. You should report on the number of students you helped (approximate numbers are fine) and the types of questions the students they asked.

Reflections on CS Tutoring and Mentoring

As you may know from your own experience learning CS, finding the right way to approach problems with programs can be difficult because problems can be due to anything from a flaw in the design of the algorithm to a bug in a library function. You are also dealing with a domain in which there is rarely just one right answer to a problem, so you as tutor/mentor must be prepared to adapt your help to the student's approach, rather than encouraging the student to use your own approach. You should also be prepared to deal with different levels of problems, from students who feel like they've done most of the work but just need help tracking down a bug to students who are not sure where to start a problem.

Following all of our recommendations will be difficult to do in practice! You may find it helpful to think of each tutoring shift as a training session for you, as you strive to improve not just your tutoring skills, but your own problem-solving skills. You may find it helpful to focus on a particular skills during a shift to help it become more natural.

When you are working on tracking down errors, in most cases you will find it helpful to use something like this sequence of steps:
  • Ask the student to restate the goals of the problem. What are the inputs? What are the outputs? What is their relationship?
  • Ask the student to run the algorithm "by hand" on a few examples to better understand what approach the student is taking.
  • The student should have translated the algorithm to code. You may find it useful to have the student run the code by hand on a few examples.
  • Encourage the student to use a debugger when possible. (We usually don't use debuggers in CSC 151, so you'll have to just run code through by hand or to insert output statements at strategic points.)
You may also find it helpful to write out the algorithm in words not code.

Teaching Good Programming Habits

When the opportunity arises, please try to encourage students to follow good programming habits. Here are some that might apply.

When writing any non-trivial program, write it in stages. Write small pieces of code, compile them, test them, make sure they work correctly, and then repeat. (You might also encourage students to write documentation and tests before they write the code.)

When debugging a program, be sure to understand the problem before trying to fix it. (Trying a sequence of semi-random changes can quickly trash a program that was nearly correct.)

Ask Questions!

You will find that you give some of your best help by asking students questions. Here are some that you might use for various situations.
  • Can you explain the problem to me?
  • Have you seen a problem like this before? How did you address it last time?
  • What is the syntax for this? Where can you look it up?
  • What do you expect to happen? Why do you think this will happen?
  • What actually happened? Why did it happen?
  • What error message did you get? Can we figure out what that means?
  • What are the pre-conditions and post-conditions?

Some General Tips

When faced with error messages, try to help students read and understand the messages rather than jumping immediately to fixing the code. This approach may help students handle similar issue on their own the next time.

When you see a logic error in a student's code, try to help students trace values through the code so that they can discover the error themselves. Try lots of different examples, not only one, to better understand the bug. Be sure that the student thinks about what answer to expect for each example before trying it.

As you help a student find an error, try to point out the clues that you notice. Learning to recognize the clues will help the student long into the future.

When faced with logic errors, it is often useful to ask "What are your assumptions?" and then help students test those assumptions. Because a bug is generally the result of an invalid assumption (either about the code or the problem itself), learning to flesh out this simple philosophy of debugging is often a handy technique.

Never type for a student on their keyboard. Students should always do things for themselves.

If you find that the student is just transcribing what you're saying, you're probably giving too much advice.
Topic revision: r7 - 2016-01-24, SamuelARebelsky

This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback