CSE 131 TA Manual
Mariah Yelenick
December 4, 2019
Table of Contents
What to expect when you’re expecting (to be paid)
How to help struggling students
How to help successful students
How to be an effective communicator
The student who confides in you
One-paragraph summary of must-knows
Flow chart for when you don’t know what to do
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.
Here
are some things you need to know to be a successful TA even if you’re a master
at the content.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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
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).
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
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
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
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, 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.
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.
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.
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!
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
2a. The student is genuinely struggling
2b. The student understands
the content and is just frustrated
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.
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.
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.
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.
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.
“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.