CSE 131 TA Manual

 

Mariah Yelenick

myelenick@wustl.edu

December 4, 2019

 

Table of Contents

 

Introduction. 3

Logistics. 3

Rules of being a TA.. 3

How to get to Urbauer 5

What to expect when you’re expecting (to be paid) 6

Scheduling and absences. 6

Github. 7

Piazza. 7

Exams. 8

Help and Demo Lists. 9

Conceptual Tips. 11

Data types. 11

Conditionals and loops. 12

Arrays. 13

Input output 14

Methods. 14

Recursion. 15

Objects. 16

Sets/Maps/Lists. 16

Teaching Tips. 17

How to help struggling students. 17

How to help successful students. 18

How to be an effective communicator 19

Tough Situations. 20

The student who confides in you. 20

The angry student 20

The stalking student 20

The cheating student 21

The apathetic student 21

Relationships with a student 22

One-paragraph summary of must-knows. 22

Flow chart for when you don’t know what to do. 22

Sources. 25

 

Introduction

Hello everyone, thank you so much for signing up to be a CSE 131 TA this semester. We appreciate your willingness to help teach WashU’s newest computer scientists and we want to make sure you’re all confident in your ability to help students. This manual was created for two main reasons – TAs expressed concerns that they don’t know how to respond in certain situations and students desire a consistent TA experience each day when they show up to class. This manual is not intended to cover every possible situation you may encounter as a TA for CSE 131, but hopefully it will get you on the right track so that when you do encounter something unfamiliar, you have a lot of tools in your toolbox to handle anything that may happen. If you have any questions, please contact the current Head TA(s), Professor(s), or the creator of this document, Mariah Yelenick at myelenick@wustl.edu.

Logistics

Here are some things you need to know to be a successful TA even if you’re a master at the content.

Rules of being a TA

1.     Don’t help or demo anyone you know from outside of CSE 131

2.     Show up on time

3.     Don’t answer questions on course policies

4.     Spend no more than 10 minutes with any given student

5.     Ask for help when you need it

6.     Don’t share your code with anyone (including posting it online)

7.     Don’t help anyone outside of your posted class times and office hours

Explanations/details for the above:

1.     As a rule of thumb, if you have that student’s number in your phone, you should not help or demo them.

2.     We take attendance every day in class and if you don’t show up or show up late, it will be considered into your future selection as a CSE 131 TA. In addition, it looks bad from the students’ perspective and puts an extra burden on the other TAs who show up on time every day.

3.     We don’t answer questions about course policy because the policies change frequently and we want to limit the number of people who could give conflicting information. Think of this as an extreme version of the situation where a child asks one parent and when they say no, they ask the other parent. We want to make sure the course policies are applied fairly and consistently to all students.

4.     Spending around five minutes with a student is ideal, but if they really need conceptual help or are in an extenuating circumstance (read on for what that entails), it is permissible to stay with the student for up to ten minutes. After that, either you as the TA or the student will be frustrated which could lead you to give away more than you should as a TA.

5.     If you don’t know the answer to a question, please find another TA you trust or a Head TA or professor. The students don’t (or shouldn’t) expect the TAs to know all of the answers to every question they might encounter. In that situation, it reflects better on everyone if you ask around until you get the right answer rather than guessing or leaving the student flailing.

6.     Academic integrity is most people’s worst enemy, but very few people think about how they could commit a violation as a TA. If you help a student more than you should or they somehow get access to your code, both you and the student will face academic integrity penalties. This includes your code being put in an organization’s “backfiles” or uploading your assignments to github.com publicly.

7.     Even if they ask for help with a git problem the first week of class, it is unfair to students who don’t personally know a TA if you help them outside of class.

This code of ethics, created by the National Tutoring Association, is a great resource with a list of expectations for tutors or TAs. Please refer to it when you’re reflecting on how you can better yourself as a TA.

How to get to Urbauer

There’s an easier, slower way to get to Urbauer and a quicker but more complicated way. The easy way is to cut through Lopata. To get to Lopata, walk Northeast of Olin library and to the East of Cupples II is a small staircase. At the top of those stairs is the entrance to Lopata Hall’s third floor. From there, walk to the right, past Engineering Student Services, and down one flight of stairs to the second floor. From there, turn right and you will enter Urbauer Hall. Look at the room numbers for your assigned room.

The shortcut to Urbauer involves the door between the Lopata entrance and the East entrance of Cupples II. When you open the door, take the stairs down, open the heavy door, and you’ll land in the second floor of Urbauer.

What to expect when you’re expecting (to be paid)

When you start as a new TA, you’ll have to go through the work authorization process before you can start working. This entails brining two forms of identification or a passport and knowing your social security number and bank account information for direct deposit. The current pay rate for TAs is $10 an hour, and you should log any time spent preparing for CSE 131 in addition to your scheduled hours in lab/studio or office hours. To log your hours, go to hrms.wustl.edu and sign in with your WUSTL key and password. Once you’ve logged in, go to the top left corner and choose Main Menu à Employee Self-Service à Time Reporting à Report Time. For easy future access, now go to the top right corner and click Add to Favorites. Choose the job that says “Engineering Computer Science” and fill out the fields titled “In” and “Out”, with time category as “Regular” and task as “CSE 131 TA”. If you worked multiple shifts on the same day, click the small plus sign on the far right of that day’s row and add your second time entry in the new row. Be sure to fill out the time sheet for the two-week period ending on Saturday by the end of the day Sunday to ensure you get paid on time and the right amount. If you have any questions about payroll or if you forget to log your hours, email Kelli Eckman as soon as possible.

Scheduling and absences

If you know ahead of time that you can’t make it to one of your assigned times, post in the Slack channel titled “schedule” and ask to be covered. Being covered means that another TA will take your shift, or potentially ask to trade shifts if they also need to miss one of their assigned shifts. If you can’t get covered by another TA and your absence is not for an excused reason, it will count as an unexcused absence. If you do get covered, even if your reason is unexcused, you will not be penalized.

Unexcused absence reasons:

·       Job interview

·       Exam studying / Homework

·       Vacation

Excused absence reasons:

·       Illness

·       Exam

·       University-related travel

Github

In CSE 131, we use Github Classroom to keep track of all the students code (and to check for plagiarism). Each student gets a repository for each assignment and TAs can access the assignment via the same link but merely clicking “skip” when it asks you to choose your WUSTL key. From there, you can clone your repository into IntelliJ or any other IDE of your choice.

Piazza

Every TA has access to Piazza (shown in Figure 1) the online forum students use to crowdsource help when they get stuck. Any questions they post can be answered by other students, TAs, or professors. Any time you spend answering questions on Piazza is also paid, so be sure to log those hours as well. Answer questions whenever you get the chance, there’s even an app that can send you push notifications if you want to make some extra money from answering Piazza questions. One word of caution though – be sure you’re right before you post an answer! Private posts are also an option on Piazza so if a student has a question about their grades or needs to include code snippets to ask their question, they must use a private question. Questions about grading should not be answered by TAs, but any coding or conceptual questions are available to anyone who feels comfortable answering.

Figure 1. Piazza as shown on a desktop. The left panel shows all of the posts and when you click on one, it opens in the main/right panel.

 

Exams

TAs have a part in helping with exams as well. We need a few volunteer TAs to help proctor and scan the exams and all TAs have a responsibility to assist in grading the exams as well. Grading takes place on Gradescope, an online tool owned by Turnitin that allows us to grade electronically, quickly, and consistently. During proctoring, the TAs helping will be responsible for handing out and collecting exams from the students and ensuring the exam rules about “sage pages” and academic integrity are being strictly enforced.

Scanning is something relatively new we’ve added to the TA job, but it is optional. Scanning typically takes place the day following each exam and entails two TAs doing some manual labor. One TA will remove the staples from sets of ten exams and the other TA will scan them onto a flash drive which the professor will later upload to Gradescope before grading takes place.

Help and Demo Lists

The help and demo lists take on two forms – electronic and manual. Before I dive into that, I want to explain why we have help and demo lists and what is the difference between the two. On demo days, students are expected to merely show up and show their finished assignment to a TA. However, if they were unable to complete the assignment, they may ask for help and, in this sense, demo days are similar in structure to office hours, with a strong emphasis on demoing. Students who have completed their assignment will put their name on the demo list, and those who still have questions will add themselves to the help list.

An example of the manual list system is shown in Figure 2. It requires use of a whiteboard or chalkboard, where students put their names on the lists in order, and TAs will call from the beginning of the list, erasing once they call a name.

Figure 2. The whiteboard being used for a manual demo and help list.

 

The electronic list is a bit more involved and was created by Alex Baker (TA). The website is 131list.com (shown in Figure 3 and Figure 4) and students and TAs will be able to sign in by linking their *.edu Github account to the website. To change your name from your WUSTL key to your actual name, click on the blue email address in the top right corner and update the value in the box. There are separate join codes for students, TAs, and professors. The process of taking a student off the list is very simple, with the button shown at the top of Figure 4 labelled “Help Next Person.” The website is accessible via mobile phone or laptop. If you call someone off the list and can’t help/demo them for some reason, you can ‘flag’ them in the system so that they will be helped by a Head TA or Professor in a timely manner. The system is very versatile because it can be used in multiple rooms for multiple classes at the same time. The electronic list was tested during office hours in Fall 2019, and from Spring 2020 on, it is the primary mode of help and demo lists during office hours and demo days.

Figure 3. The online help system, shown on a desktop browser. Click on the big blue button in the center to access the help and demo lists.

Figure 4. The mobile version of the online system, shown inside the help list. Click “Help Next Person” to take the next person off the list. Click “Flag User for Help” after filling in the form to add them to the Flagged Users list.

 

Conceptual Tips

This next section will dive into the concepts covered in CSE 131, so if you don’t feel prepared to answer questions about a certain topic, be sure to read that section extra thoroughly.

Data types

There are 8 primitive data types: int, double, boolean, char, float, short, long, and byte. The ones you need to know well for this class are the first four. An int should be used for whole integer-valued numbers, doubles for numbers with a decimal in them, booleans for true/false values, and chars for single characters like ‘a’.

These are primitive because when you look at their spot in memory, you actually see the value. For example, int x = 5; stores the value 5 in a spot in memory labelled “x” whereas a Color c = new Color(30, 40, 50) stores the memory location where the variables r, g, and b will be stored in that order. In fact, if we print out c, it would print out a gross-looking memory address, let’s call it “a”. If we go to “a” in memory and print out the value there, it’ll be the integer red content (30). Spot “a”+1 in memory will give us the green content (40), and spot “a”+2 will give us the blue content (50).

The non-primitive types are called objects. These are easily distinguishable from primitives because they are capitalized, like Color in the example above or String. They can have many properties and methods that can be called on them – this will be discussed in more detail in the Objects section. Because they are not a certain size and can even change in size, their location points to a larger location where all of its values are stored. Think of this as a map (not a Java Map!) where we know where everything is, and if someone is looking for it, they first need the map to find out where in memory it’s actually stored. These map values are printed out when you try to print an object directly.

Conditionals and loops

There are two big concepts in this module – conditionals and loops. I would think of this as a Venn Diagram with if loops on the conditional side, for loops on the loop side, and while loops in the overlap.

If statements are fairly self-explanatory. If the boolean expression inside the parentheses evaluates to true, then the code within the corresponding curly braces is executed. The only other thing about if statements is the “if, else if, else” structure. These statements work together to cover various boolean cases. For example, we could write code like this to print whether a number is positive or negative.

if(x < 0) { System.out.println(“negative”); }

else if(x > 0) { System.out.println(“positive”); }

else { System.out.println(“zero”); }

 

Note here that in methods that use “if, else if, else”, you must return in all cases, so that no matter which if statement executes, the method’s return type will be satisfied. A fun fact about boolean expressions that you might encounter when debugging a student’s code is that the statement if(x = 4) will always execute because assignment operations return true if they were successful.

Loops take two forms – for loops and while loops. For loops have three (optional) parts: for(int i = 0; i < 10; i++). The first part is the declaration, the second part the condition, and the third part the update. If you want to leave any part out, you still need the semicolon to separate the parts. A while loop executes zero times if the condition is initially false, or until the condition becomes false. The for loop that executes exactly like a while loop while(condition) would be for(; condition; ). You can also have multiple updates and declarations in one for loop, separated by commas. If you need multiple conditions, use boolean operators to combine them.

Arrays

Arrays store multiple values of any data type (primitive or Object). Array creation requires knowing what data type you want to store and the capacity of the array. The following code creates an array that stores ten strings: String[] ten = new String[10]. Two-dimensional arrays are merely normal arrays where the data type they store is an array. That means that if we have a two-dimensional array of integers, int[][] example = new int[10][] then the type of example[1] is an int[]. Note that you don’t have to specify the size of each array or the number of columns in the two-dimensional array. That’s because we can fill example with int arrays of various sizes.

In memory, arrays take up consecutive spots where each one either contains the value itself (primitive arrays) or a pointer to the Object stored in that spot of the array (Object arrays). Arrays are by default filled with the default value of what it contains (0, false, or null).

Input output

In this class, we use Sedgewick API for most of our input/output needs. To draw, we use StdDraw, whose JavaDocs can be found here. To read files, we use In, and to get user input we use ArgsProcessor (written by Ron Cytron). The reason we use ArgsProcessor instead of Scanner/System.in is that ArgsProcessor allows us to send in arguments from a JUnit Test and it will think that the user typed in the inputs. It also performs type checking for you.

Methods

Methods are used to make code cleaner and less repetitive. As a rule of thumb, if you ever feel a need to copy and paste code, you should write a method. Methods can have parameters and a return type which can be any datatype (primitive or Object) or void if it doesn’t return anything. Each parameter must have a name and a datatype. When the method is called, it requires every parameter that the method declaration specifies, in the order that the method declaration specifies. Methods can be static or non-static. Static methods mean that you call the method on the class, whereas non-static methods are called on an instance of that class. For example, Math.random() is a static method because it is called on the Math class itself. The substring method for Strings must be called on one specific String. For example, with Strings we might write:

String s = “I love CSE 131!”;

System.out.println(s.substring(0, 6));

 

We would not write String.substring(0, 6) because it wouldn’t know which String to substring.

 

Recursion

Recursion is a logical structure that is not unique to any specific language. It simply means that a method calls itself. If a method ever has a call to itself in its body, it is a recursive method. The classic example of recursion is factorial. The code for factorial is below. Recursion must always have a base case which is when the method doesn’t call itself; without a base case, the recursion would go on forever and you would get a Stack Overflow error.

public static void factorial(int n) {

      if(n == 1) { return 1; }

      else { return n * factorial(n-1); }

}

The execution of factorial(5) is written out below.

factorial(5)

= 5 * factorial(4)

= 5 * 4 * factorial(3)

= 5 * 4 * 3 * factorial(2)

= 5 * 4 * 3 * 2 * factorial(1)

= 5 * 4 * 3 * 2 * 1

Objects        

Objects are used to model real world elements. If I want to keep track of all the shoes in my closet, I might have two classes: a Shoe class, and a Closet class. The Closet class might have an array of Shoes as an instance variable and maybe a size() method, and a contains(Shoe s) method. A Shoe might have a Color, integer size, String dateBought, and integer numberOfTimesWorn. Its methods might include wear(), as well as getters for the variables. Objects also normally have constructors which are methods with no stated return type which creates a new instance of that class. You can have multiple constructors that take in different types or orders of parameters. Similarly, you can have “overloaded” methods which are methods with the same name but different parameters.

Sets/Maps/Lists

Sets, Maps, and Lists in Java are parameterized interfaces. That means that you need to give it a type (or two for Maps) that it will contain. These types must be Objects, and there are Object versions of each primitive type, like Integer or Boolean. Sets are unordered collections of distinct Objects. Lists are ordered collections of Objects that can contain duplicates. Maps are like a dictionary, where each entry has a key and a value. The keys and values could be different types or even other parameterized Objects. The keys must be distinct, so they form a set. You can add duplicate keys to a Map and the prior value associated with that key will be overridden by the new value. The add() method for Sets returns a boolean which represents whether that element was successfully added. It would return false if the Set already contained the element.

In CSE 131, we primarily only use HashSets. Read up on HashSets if you’re curious how they work. The hashing allows you to have constant time lookup. Similarly, HashMaps are the main type of Map used in this class. As for Lists, we have both LinkedLists and ArrayLists. ArrayLists are very similar to an array except that it is dynamic in size. LinkedLists are slightly different from ArrayLists in that to access the fifth element of a LinkedList, you would have to start at the first element and then advance one at a time to the next element until you get to the fifth.

Interfaces represent a common functionality. For example, Shape might be an interface with methods like numberOfSides(), getArea(), and getPerimeter(). Square is a class that would implement Shape and have its own code for each required method and its own instance variables. Triangle would also implement Shape. Interfaces are because we might want to have a LinkedList of Shapes and be able to add up all of their areas. LinkedLists can only contain one type, which can be an interface like Shape. We know that every Shape in the List must have a method getArea()and we can add up all of those results. Without a Shape interface, we would need to have separate LinkedLists for each type of Shape, and then keep track of all the Lists to add up the total area.

Teaching Tips

These sections are not intended to cover or account for every situation you might encounter, but rather to give you some guidelines on how to use the most frequent teaching styles you need to know to be a successful TA.

How to help struggling students

When a student is struggling, it’s important to be kind. They are likely already on edge because they feel behind or inferior to their friends or classmates who aren’t struggling. They might be worried about their grades or something might be going on in their life outside of class. In these cases especially, we must be careful when we help them. With that warning in mind, let’s dive in to an example.

Say you call a name off the help list and the student has just barely begun the assignment which is due at the end of class time. They say they don’t understand recursion at all, and they don’t even know where to start. First thing you should do is make sure they understand the concept. Holding their hand through the assignment won’t be useful for their learning or for their performance on exams.

In these situations, I typically come up with a simpler example than what the lab asks them to do. For recursion, that might be counting how many 2s are in an integer array recursively. It requires they know simple recursive practices and it also introduces the concept of helper methods. For this example, I wouldn’t have any objection to typing some on their computer, as long as what you’re typing is not part of the actual assignment.

Once they seem to understand the concepts, you’ve probably spent enough time with them and it’s time to let them try to work on the assignment on their own. They can always ask for more help if they get stuck, but one of the things I always encourage is to let them struggle as long as that struggling is conducive to their learning.

In less extreme examples, you should make sure to answer any questions the student has, make sure they’re on a learning path (not going down a fruitless rabbit hole), and give them a goal or parts of the assignment they should try to finish on their own.

How to help successful students

The most important thing to know about helping successful students is to make/keep them excited about learning and computer science. Explain to them why what they’re doing is useful other than to help them get a good grade or meet a prerequisite for the next class. Use examples from your own class experiences to motivate the work and come up with your own harder problems especially during studio. The point of studio is not to complete the assignment, but rather to ensure that the student understands that week’s content. If the student already has completed the assignment/studio and understands the content, challenge them!

How to be an effective communicator

Communication is probably the single most important skill needed to be a good TA. Good communication is key with your coworkers, supervisors, and the students you assist throughout the semester.

For students who learned English as a second language (ESL students), there are sometimes additional challenges, especially when it comes to programming. For example, one semester we assigned Battleship as the final project and some students had never played the game or didn’t know some of the specific terminology we were using in describing what each method should do. It’s not the responsibility of the TAs to write the assignments in such a way that non-native English speakers can understand what is required of them, but you may encounter situations related to this. Some tips that other academic institutions recommend include:

·       Write down what you say if the student doesn’t understand

·       Try to rephrase your questions

·       Repeat yourself

·       Ask the student to summarize what you just said/asked

As a rule of thumb, communicate as much as possible. This is applicable in coding interviews as well. It’s much easier for people listening to tune out things that are repeated or not useful to them than to infer what you didn’t say.

Tough Situations

The student who confides in you

You are a mandatory reporter as a TA. This means that if a student comes to you while you are on duty as a TA or comes to you because they know you as their TA and tells you that they are considering hurting themself or someone else or they make you aware of sexual assault, sexual harassment, stalking, or sexual or relationship violence, you are required to report what they said as quickly as possible to a professor. They will handle it from there. It is best to let a student know before they confide in you that you must report whatever they tell you. There are many confidential resources on campus for students, but if a student does tell you something you must report it. In addition, if a student is considering hurting themself or someone else, you need to stay with that student, even if your section is over, even if you need to go to class, even if you suspect they might be joking. Message or call a professor or head TA and do not leave.

The angry student

If a student is angry, do your best to stay calm and professional. If you feel you can’t keep your cool any longer, go find a professor or Head TA and have them speak with the student.

The stalking student

During your time as a TA, a student might take an interest in getting to know you outside of class. If any student ever makes you uncomfortable, do your best to leave the situation and immediately find a professor or Head TA. They will certainly move your shift to another room so that you don’t have any interaction with the student. If the student continues to make you uncomfortable, a professor will meet with the student and file any necessary reports.

The cheating student

If you witness an academic integrity incident or something suspicious along those lines, make a note of the name(s) of the student(s) involved. Notify a head TA or professor with the details. Typically, we rely on MOSS to catch any cases of academic dishonesty, but we still may meet with the student(s) or do additional investigation into that specific case.

MOSS is a program that detects similar code and it is very hard to get away with copied code that’s run through MOSS. In general, it takes less work to do the assignment than it does to get around MOSS. Changing variable names, double spacing your code, or switching a for loop to a while loop will not trick MOSS. Approximately 10% of the class each semester will be found in violation of the academic integrity policy. It is not your responsibility to detect or enforce the academic integrity policies.

The apathetic student

Students who don’t care are probably the most difficult to help. It’s hard to force a student to care about learning, but it is our job to merely teach them the content. This class, like so many others, is one where the student gets out as much as they put in. Don’t be afraid to let the student know that they must try if they want to get credit. They must put in the time and give each studio and assignment the attention it deserves. It is up to each TA to determine whether to give credit on each studio and if a student is texting the whole time or just trying to get out of class as soon as possible, they do not deserve studio credit. If you’re ever unsure how to handle a specific case, do not be afraid to speak to a Head TA or professor about the student involved and they can either give you advice on how to handle it or they will offer to handle it themself.

Relationships with a student

Per human resources, as university employees, we are not permitted to have a position of authority or grading power over someone we are in a relationship with. If you are in a relationship with a student in the class, you must notify the Head TAs and Professors immediately. They will likely rearrange your TA schedule so that you are never responsible for grading the student you are in a relationship with. This means you won’t be assigned to their room/time for studios and labs. Fortunately, because of the way we use Gradescope for exam grading, you won’t know whose exam you’re grading so there’s no risk there.

As for general conflicts of interest, we want to be clear that if you know a student from outside of class, you should not help them or grade any of their work during or outside of class.

One-paragraph summary of must-knows

You can never help or demo a student you know from outside of class. Helping or demoing them outside of your scheduled times is even worse. Show up on time, prepared, and eager to help students learn. Your job is to help teach and reinforce material, not help students complete their assignments. With a few exceptions, you should spend 5-10 minutes helping each student. Answer any questions they have, make it clear that you are not there to hold their hand through the assignment, give them a to do list of things they can work on by themself, and move on to the next student.

Flow chart for when you don’t know what to do

To use this, click on the link corresponding to the choice for each number and it will jump to the next question. Continue this until you get a paragraph response with how to handle the situation.

1:

1a. This student is on the verge of tears or is losing faith in computer science or learning

1b. I don’t know what’s wrong with their code or how to help them

1c. The student wants me to hold their hand through the assignment

1d. The student doesn’t understand the fundamentals

2:

2a. The student is genuinely struggling
2b. The student understands the content and is just frustrated

3:

3. Find another TA and ask them to switch you. Sometimes a fresh set of eyes is all you need. Apologize to the student for not being able to find it but let them know that they’re in good hands. If you don’t know feel comfortable asking another TA, flag them with the online help system and leave a note explaining what is happening with their code that you can’t figure out.

4:

4. First, try to be subtle and ask, “Do you have any other questions right now?” If they do, answer them. If not, reassure them that they’re on the right track and give them some goals of what to work on by themselves. If that doesn’t work, be blunt and say that it is not your job to do the assignment with them, but rather to answer any questions they have and help them if/when they get stuck. If we were to do the assignment with them, they wouldn’t be actively learning (it’s analogous to rereading your class notes versus quizzing yourself with flashcards).

5:

5. In this situation, it’s easy for you (the TA) to get frustrated or snarky. We want to avoid that as much as possible. Monitor your own mood and swap out with another TA or professor if you notice yourself no longer being helpful. Be understanding with the student and work your way backwards asking questions until you find the most advanced concept the student understands. From there, explain one step up the ladder (hopefully this takes about 5 minutes), then tell the student honestly that in order to get caught up on course material, they will need to put in some serious effort reviewing the lecture videos and getting conceptual help at TA or professor office hours.

6:

6. When a student is both losing faith in computer science and struggling with the material, it’s easy to feel helpless. First, do not leave a student who is crying. If you don’t feel comfortable following the steps outlined next, message or flag down a professor or Head TA and they will take over for you. Do everything you can to do this in a subtle way, as the student is likely already embarrassed and doesn’t want to draw even more attention to themself. In these situations, the best course of action is to help them make visible progress on the assignment so that they see that they’re headed in the right direction. Once you’ve done that, be gentle but honest with them and let them know that they can succeed in this (and every) class, but it will likely take extra work on their part. Refer them to TA office hours, professor office hours, Piazza, and free tutoring available through Engineering Student Services if they’re in the Engineering school. After you’ve done those things, be sure to leave them with some encouraging words, maybe reflecting on a time when you struggled when you started coding.

7:

7. When a student is frustrated or on the verge of tears, but clearly is doing well in the class or on the assignment, there’s nothing wrong with feeding their ego a little bit. Ask them why they’re frustrated. It could be something unrelated to the class or maybe they’re worried about their grade. Try to gently remind or console them that they are understanding the content and that’s really all they can control. If they’re frustrated by the class for some reason like they had to wait too long to get help, refer them to a professor or ask them to post privately on Piazza.

Sources

“CIS Introductory TAs @ Penn.” TAs for the Introductory UPenn CIS Courses, https://www.cis.upenn.edu/~introtas/.

“Code of Ethics.” The National Tutor Association, https://www.ntatutor.com/code-of-ethics.html.

“Consensual Relationships.” Human Resources, 13 Nov. 2018, https://hr.wustl.edu/items/consensual-relationships/.

Current CAs.” Stanford Computer Science, https://cs.stanford.edu/academics/course-assistants-cas/current-cas.

Duties.” UW CSE 14x TA Program, http://courses.cs.washington.edu/courses/cse14x/ta/duties.php.

Florman, Jean C. “Handbook for Teaching Excellence.” University of Iowa, ITS Office of Teaching, Learning & Technology, https://teach.its.uiowa.edu/sites/teach.its.uiowa.edu/files/handbook-for-teaching-excellence-7th-edition.pdf.

“Mandatory Reporters.” Title IX at WashU, https://titleix.wustl.edu/about-title-ix/mandatory-reporters/.

Pritchard, David, et al. “In.” Princeton University, The Trustees of Princeton University, https://introcs.cs.princeton.edu/java/stdlib/javadoc/In.html.

Sedgewick, Robert, and Kevin Wayne. “StdDraw.” Princeton University, The Trustees of Princeton University, https://introcs.cs.princeton.edu/java/stdlib/javadoc/StdDraw.html.

“Teaching Assistant Handbook.” Department of Computer Science at University of Iowa, https://cs.uiowa.edu/graduate-programs/teaching-assistant-handbook.

“Tutor Training.” Tips for Working with ESL Students, Chandler-Gilbert Community College, https://www.cgc.edu/Academics/LearningCenter/Training/Pages/ESLStudents.aspx.