Computer science tutoring · study guide
A computer science tutoring guide for learning to explain, trace, and debug
Strong tutoring does not replace a student’s thinking. It gives that thinking a structure the student can reuse when the tutor is not there.
I have worked as a CS Tutor at San José State University since August 2024. The recurring challenge is rarely a single language feature. Students are usually trying to coordinate several skills at once: reading a prompt, forming a plan, translating that plan into code, compiling, interpreting errors, and checking whether the output matches the original question.
A useful tutoring session makes those stages visible. The goal is not to hand over a finished solution. It is to help the student leave with a method for the next assignment, lab, or exam problem.
Begin with the student’s model, not the error message
When code fails, it is tempting to start with the red text in the console. Instead, start with a short explanation: What is the program supposed to do? What input does it receive? What did the student expect to happen? This reveals the current mental model before the tutor suggests a fix.
Then reduce the task to a trace. For a loop, write the starting values, the condition, one iteration at a time, and the state after each iteration. For a function, identify its inputs, its return value, and any side effects. A trace turns vague confidence into something that can be checked.
Use a repeatable problem-solving loop
- Restate the task. Identify the input, output, constraints, and one small example.
- Plan before coding. Write a few steps in plain language or pseudocode.
- Implement one piece. Keep the first version narrow enough to test quickly.
- Trace a known example. Compare each intermediate value with the plan.
- Read errors literally. Find the file and line, then inspect the smallest relevant region.
- Retest after one change. Change a single cause when possible so the result teaches something.
- Explain the solution back. A student should be able to describe why it works, not only observe that it runs.
Debug by category
Not all bugs deserve the same response. Categorizing them helps a student avoid randomly changing code.
- Syntax errors mean the language cannot parse the structure. Check punctuation, names, delimiters, and the immediate surrounding block.
- Type errors mean values are being used in incompatible ways. Write down the expected type at each boundary.
- Logic errors mean the program runs but produces the wrong behavior. Trace a small input and compare the state with the intended algorithm.
- Edge-case errors appear when input is empty, unusually small, unusually large, or at a boundary. Invent one edge case before declaring a function finished.
This approach is especially helpful for students who feel that errors are random. Most errors are evidence about a particular assumption. The job is to isolate that assumption.
Prepare for tutoring efficiently
Bring a minimal reproducible example: the assignment prompt, the smallest code sample that shows the issue, the exact error or unexpected output, and one sentence about what has already been tried. This does not need to be polished. It gives the session a starting point and leaves more time for reasoning.
Keep a small learning log after sessions. Record the concept, the kind of error, the debugging step that worked, and one question to revisit. Over time, this becomes a personal map of patterns: perhaps loops need more tracing, functions need clearer contracts, or documentation needs slower reading. A record beats the feeling that every assignment begins from zero.
Explain in multiple representations
Code is only one representation of an algorithm. Ask for a diagram, a trace table, a test case, or plain-language steps. This is useful for every student and particularly valuable when syntax is masking an idea the learner already understands. The same principle appears in bilingual computer science education: conceptual reasoning and programming notation should reinforce each other, not be confused with each other.
For students who want a steady routine, choose a small daily practice: read a function and predict its output, trace one loop, write one test case, or explain a concept aloud. Consistency produces examples to discuss in a tutoring session, and those examples make feedback more useful.