Hosting Office Hours

Preparing for OH ("OH prep")

Some common misconceptions you might have are:

• One common assumption is that as OH prep, the TA will redo the entire project. This is not true. In terms of timing, OH prep should take you around one hour. If it takes you more than 1.5-2 hours, talk to the professor(s) and/or an experienced TA (and/or, continue reading through this section!).
• Another common misconception about OH prep is that it simply involves reading the code of the reference solution. This is not enough; you should be engaging in a thoughtful interaction with the reference solution. As a result of OH prep, you should be able to "explain the code” of the reference solution. "Explain the code" does not mean "be able to dictate line-by-line"; rather, you should be able to "explain" in words the idea, or purpose, of how the reference solution handles each task.

So, what should you do? The goal of OH prep is to learn the project. You should almost "study for" the project the same way you'd study in a class, which means that you can employ the same "studying techniques." Some suggestions for things you can do in your OH prep are:

• Make sure you look at the student guide, the TA guide, and the reference solution while prepping (i.e., before OH). One way to read the reference solution is to have two side-by-side windows open on your computer, the reference solution and the TA guide.
• Pick out a few parts of the project that you think are confusing and/or hard to understand, and think about questions that you might have as a student. Outline and think about, and maybe act out, explanations that you could give for each of these parts. The TA guide might already note parts of the project that are more challenging/can be more significant hurdles for the students.
• I (Ellie C.) personally enjoy taking notes on my iPad on the project as a way to prep, because note-taking is a studying technique that works for me.
• You can also look at your own solution from when you took the class and the reference solution side by side. This can help prepare you for the wide range of student implementations that might come in.

What might I find in the TA guide?

The TA guide will generally be an annotated version of the student guide. There will be additional red and yellow boxes at the sides corresponding to different points in the student guide. The red boxes tend to include tips on common tricky bugs or technical issues. The yellow boxes tend to include tips for how you can scaffold explanations to students, as well as additional resources you can direct them to when applicable.
Whenever course leadership releases a project, they should send a message announcing so on discord. That message should include a link to the TA guide for that project.

During OH

Throughout the entirety of OH, you are interacting directly with students. It is important that the students feel comfortable and accepted. Keep a friendly, open demeanor, and avoid alienating students in your explanations (e.g., avoid the words "trivial" or "obviously," as these can make novice students feel uncomfortable and alienated from computer science).

To see more about the flow and mechanics of hosting OH, you can read Hosting Office Hours. Below are situations you might come across during OH, as well as how to handle them.

I'm scared and/or nervous about going into OH.

Totally understandable! One suggestion for handling this is to "fake it ‘til you make it." Prepare well ahead of time, come in with a smile on your face, and when you call a student over to you, act as friendly and confident as you can. The more friendly and confident you act, the more friendly and confident you will eventually be. Additionally, if there's another TA in your timeslot, you can make casual conversation with them to mitigate your nervousness. If you're a new TA and they're an experienced TA (which is likely how it'll be), they will understand and be happy to help you out. (Note that this is not the only viable solution, but is a suggestion for what you can try if you're nervous.)

I'm helping out a student, but I'm stuck.

There are several different cases, described below.

It's a technical issue.

If it's not something you can resolve within a minute, it's not in your job description. This is a case of escalating to course leadership---send a message in the discord server and ping the professor(s).

I have to buy myself time to figure out what's going on in their code.

You can:

• Ask the student to explain their code.
• Ask the student what they’ve already tried and/or what they think the issue might be.

While the student is talking, you have a bit of extra time to look through their code and think. These questions also have the benefit of prompting the student to reflect on their work thus far, so they're not entirely empty questions. In the best case scenario, while the student is talking, they might also realize something. The second question is also a great one to ask in general.

I don't know what's going on; so, I'm debugging with the student.

This actually isn't a problem at all! In fact, it's something you should be clear about to the student: tell them that you're also not sure what's going on, and you'll work together to try to make some progress in debugging.

Two debugging techniques you can use are:

• Print debugging. This is especially useful for debugging with a student during an OH session, as it very clearly, visually shows to the student exactly where things are going wrong.
• “Binary search debugging” through the test. This is useful in the situation that the student is failing one test, but neither of you know why.

You can go to the test file and find which test they're failing from the error output. Then, you can comment out half the test. If the test still fails, you know the issue is in the part you left in; otherwise, if it now passes, you know it's in the part you commented out. You can continuously comment out halves/parts in a binary search for the exact part of the test that fails. Once you've isolated that exact part, you will have substantially more information about what logical breakdown could be happening in the student's code.

I tried all the above/none of the above apply, and I'm still stuck.

If there's a fellow TA in your time slot, there's absolutely no shame in letting them take a look. If it's been 8 minutes and you are still completely stuck, you can pass on the student to your fellow TA and politely let them (the student and the fellow TA) know.

If there is no other TA, you can try your best to give the student the best starting point you can, but be honest about the things you don’t know (i.e., avoid misleading the student).

If no one is able to figure it out, escalating to course leadership is the way to go. Note, however, that if you are constantly escalating to course leadership, that is an indication that you have not prepared enough and is a problem. As a reminder, when you escalate, you need to PING Professor Blank on discord with the issue. The button does not actually send course leadership any information (if this is a technical issue, please make sure the student pushed to their code to gitlab).

The student came to me, but they're not talking. How can I start the interaction?

You can ask, "What can I help you with?" If the students tells you their bug, you can say, "Can we take a look at the error output?" or, "What have you tried already?"

I know exactly what the issue is, but I'm stuck on explaining it with scaffolding to the student.

Below are some socratic questions you can use to guide the student through the process. They are taken from the CTLO's TA handbook (page 21).

• "Can you break the problem down into a number of steps? Which of those steps do you know how to do? Which ones are you unsure of?"
• "How did you get from this step to the next step?"
• "I don’t understand what you did in this part of the problem. Can you explain it to me?" (In a CS context, this might sound more like, "Can you explain what you're doing in this part of the code?")
• "Can you draw a diagram/write down an equation that describes this part of the problem?" (In a CS context, this might sound more like, "Can you draw a diagram for this part?" with you passing the student a marker.)
• "Is your answer what you would expect to get for this problem?" (In a CS context, this might sound more like, "Is this output what you would expect?" or, "Now that you look at this line of code, is it what you'd expect?")

You can also think about the steps of your own debugging process and guide the student through those steps.

I've gotten the student unstuck, and I'm having some trouble ending the interaction without having it awkwardly fizzle out.

You can say something like, "How about you try that out for a bit?" or, "I'll give you a chance to work on that by yourself for a bit."

We've solved the bug, and the student has another bug. What should I do?

Stick to one bug per session. If the student has another bug after you've solved this one, you should kindly ask them to spend some time working on it on their own. If the student comes with multiple unrelated conceptual questions, you can feel free to answer as many of them as time permits.

What do I do if a student is exhibiting learned helplessness while I'm helping them?

Don’t directly call them out on it at first, especially if there are other people in the room. OH is a public space, and directly "calling them out" might embarrass/shame them in front of other students, which would do more harm than good. If the student is very direct about learned helplessness (for instance, they directly ask you to tell them the answer), however, then you can call them out on it directly and immediately. You can say something like, "I'm here to help you and can't give you the answer," or, if they're more persistent, "I need to move on to the next student. Please re-enqueue when you want help, not the answer."

Some phrases you can use to direct them back to the learning goal more subtly include:

• "Have you tried (this thing) out yet?" If they say no, send them to try out that thing. This question is also great to ask in general, not only when students are exhibiting learned helplessness.
• "I want to give you more agency in your code." You can slip this one in among other sentences while asking the student to do something. This one puts a (true) positive spin on curbing the student's learned helplessness, and might work better to encourage the student because of its positive phrasing. The "I" as the subject works to sound less pointed to the student.
• "I don't want to micromanage your code." This one works similarly to the previous one.

What do I do if a student is rude to me?

You are not obligated to put up with it. You can pass them on to another TA, or straight-up tell them their behavior is unacceptable for office hours and tell them to come back later.

If the student is aggressive and you’re alone and/or scared of the student, politely remove yourself from the situation by indicating that the student is being disrepectful or otherwise not following the honor code. Tell the student to please go to another TA's OH, and definitely inform course leadership as soon as possible.

In general, if a particular student is exhibiting unacceptable behavior at OH, let the professor(s) and course leadership know.

What do I do if a student starts crying while I'm helping them?

Put their emotions before continuing to work on the assignment: you should pause any talk of the assignment itself and focus on letting them calm themselves and focus on how they feel. If there is another TA with you, you can have them take care of the OH queue while you handle this student. While you should treat them kindly, you are also not obligated to comfort the student as they are crying: it is not part of your job description. You can offer this student to go to the bathroom to take some time to themselves.

Furthermore, in the rare instance that it might happen, remember that you are not obligated to listen to trauma-dumping. If they do begin trauma-dumping, you can politely interrupt them and say something along the lines of, "That does sound really hard. I'm not trained to help you, however, and I can let you know what other resources I can recommend you to contact." The sequence is: validate them briefly, mention you're not trained to help, and bring up going to other resources (e.g., deans, PAs, the professor(s)).

A student and/or I might have found something wrong with the project?

Nice! Alert the other course staff/course leadership on discord.

I think I see a case of academic integrity violation.

If you see any behavior you think is suspicious, including cheating by TA*, tell course leadership about it on discord privately (not in #ta-chat).

*when a student simply continuously tries to wrangle "the answer" out of the TA during their session(s).

After OH

After each OH session you hold, it is good to do a metacognitive reflection. What didn't go well? Were there any things you missed in your prep? You can go back through to cover the things you missed. For the things that didn't go well, what could you do to prevent them from happening next time? Similarly, what went well? Were there any things you explained particularly well, especially if they weren't explanations you'd thought of ahead of time? Did you notice your fellow TA (if applicable) doing something well? You can apply all of these things to next time.

What do I do if I realize I made a mistake during OH?

If after OH, you realize you told a student incorrect information during OH, you should send an email to the student with an apology and the correct information, and CC the course email. If you realize during OH and the student is still there, you can tell them directly in person as soon as possible.

This should not be a common occurrence.

OH Swaps

The TA discord server will have an #oh-swaps forums channel. This channel serves as a place to find and document OH swaps.

If you are ever unable to make your usual OH slot (life happens), you need to create a post in the channel asking if anyone would be willing to swap. For each hour that you are looking to swap with another TA, please create a new post for it in the forums channel.

To create a post, first click on the channel and then click the New Post button.

You will be prompted to enter a title and a message for the post. Both fields must be filled to create the post. For your title, please use the following format: Requesting a swap from (HOUR-RANGE)pm/am on (DAY-OF-THE-WEEK) (DATE). You should include any relevant information in the message of the post. We have provided an example of a properly formatted OH swap request post below:

If someone is willing to swap, they will confirm with a message in the forum. They will take your slot and you will take some of their OH (at least an equivalent amount of time). To maximize the chances of someone accepting your swap, we recommend that you give a decent advanced notice by creating a post well before the hour you need a swap for.

Once a swap has been confirmed by both parties, course leadership will close the request post.

As a reminder, if you are not able to find a swap, you are still responsible for covering your OH slot.

Furthermore, for courses with DUEs, office hours may not be swapped with DUE hours.