15-410 TA-aspirant page

Welcome! The goal of this page is to provide some insight into what the 15-410 instructors are hoping for in TA candidates. As discussed at the start of the semester, being a TA is one of the "grade above A" outcomes. Achieving an A grade for the semester is neither strictly necessary nor sufficient for TA candidacy. Below are some things we look for.

In a sense the list below could be summarized as "Do the weird things that are discussed in lecture that you have never needed to do before while getting A's in other classes".

Please note: because some of these things require repeated practice, it is best if TA aspirants commit at the start of the semester to pursuing these practices immediately and continuously.

• Come to class, in person, on time.

• Read indicated sections of the textbook (as the class progresses — not all in a rush right before the exam).

• Read handouts and specifications top to bottom, twice, before beginning work on a project. Read actively, meaning take notes while reading—perhaps ink on paper, or digital ink on a PDF, or a list of questions in a text file.

• Run the "assumption protocol" (for real, as opposed to detouring around the issue by replacing "assume" with "presume", etc.). If the "Questions" lecture doesn't change how you design code, something may be going very wrong.

• Genuinely consider multiple solutions to a problem before writing code. Do design matrices — all the way, meaning actually writing them down.

• Treat error handling as a matter of highest importance. This means doing case analysis often enough that it becomes natural (it may well start off seeming unnatural). If the "Errors" lecture doesn't change how you write code, something may be going very wrong.

• Use meaningful variable names, function names, and field names. Carefully place functions (and data) into files, including choosing sensible locations within files.

• Document code clearly — especially key points. While documenting, avoid "code narratives", such as, "We divided our code into the following five files ... In our initialization function, we first allocate a linked-list head node, then...". These narratives often do not match the submitted code, and also shed no light on why certain decisions were made. Also avoid comments that contribute nothing, such as: "++x; // increment x".

• Read code after writing it, especially before submitting it. In partner projects, this includes reading every line of code written by your partner (this is best done incrementally, not in a single rush at the last minute).

• Read test code before commiting to a design and carrying out an implementation. Write some test code, too!

We understand that you may well have been able to get A grades in classes without doing those things. However, OS TAs must be able to guide students through deploying these practices, thus OS TA candidates must demonstrate proficiency at doing those things. As just one example: TAs will need to read, and comment on, code written by arbitrary other students; reading one's partner's code, and discussing it, is necessary practice for that.

Students who aren't doing the things on the above list all semester long are unlikely to be strong TA candidates. In the other direction, students who are doing these things all semester will likely reap professional benefits (whether or not they end up serving as TAs).

[Last modified Wednesday July 31, 2024]