Introduction

Early in the summer, I was offered the Lead TA position for the CS department for the 2025-2026 academic year. One of the main responsibilities is running the department’s TA training program, which primarily features teaching CS 501 (Techniques of Computer Science Teaching). This is a required course for all new graduate students in their first quarter, regardless of whether they have secured a concurrent TA position. Although I have been a TA many times, teaching an entire course on how to teach CS felt like a daunting task. It seemed to require a different skill set and knowledge base than what I had developed in the classroom as a TA.

Nevertheless, I took on the challenge because I saw an opportunity to evolve the existing program. When I started as a PhD student four years ago, I was enrolled in CS 501 myself. Yet, I still remember the dread and anxiety of standing in front of a classroom of 30 students for the first time. I remember the sleepless nights before my instruction days, lying in bed involuntarily rehearsing every sentence I planned to say.

Looking back, I realize that while I had completed the training course, there was a gap between the theory I learned and the reality of the classroom. Now, with four years of experience as both a TA and an independent instructor, I have the hindsight to see what CS 501 could have offered to better bridge that gap. My goal wasn’t to discard the past curriculum, but to build upon it with the practical lessons I had to learn on my own.

So I set out to remake the course to better prepare future TAs, given how given how vital TAs are to the undergraduate CS experience at UCSB, and how important CS 501 is as the foundation of their training.

The rest of this blog is organized as follows:

Background

What TAs do (at UCSB CS)

Teaching assistants are graduate students (MS or PhD) who support the instructional mission of our undergraduate courses. In the CS department, courses typically have high enrollment with only one primary instructor. Because one-on-one interaction with the professor is a limited resource, TAs serve as the primary contact point between the students and the instructional team. Moreover, due to the high student-to-instructor ratio at UCSB, TAs often bear a significant portion of the teaching load. Student-to-Instructor Ratio

The following diagram, provided by the UCSB Office of Teaching and Learning, shows a detailed breakdown of these responsibilities: TA Responsibilities

I want to focus on the following five tasks, which I believe are the most critical for CS TAs:

The Overall Training Program

CS 501 is just one pillar of the broader TA training program at UCSB CS, which consists of four main components:

  1. University-wide TA Orientation (TAO): An overview of general responsibilities and pedagogy workshops. (I also happened to lead the Leading Computer-Based Labs workshop, which used role-play to cover Tasks 3 and 5. I wrote about that experience here.)

    Note for future Lead TAs: Since TAO registration is optional, some CS 501 students might miss this workshop. It may be beneficial to integrate these role-play scenarios into a CS 501 meeting for those who couldn’t attend the orientation.

  2. CS 501 (The Training Course): Taught annually in the Fall, this course is a prerequisite for holding a TA position. It focuses specifically on the training for Tasks 1, 2, and 4.

  3. Mid-term Evaluations: Around Week 5, the Lead TA (me) sends surveys to students in every section. I then aggregate these results for the TAs using an automated system built by Zach, a previous Lead TA. This provides a “low-stakes” feedback cycle, allowing TAs to address student concerns while they still have 50% of the quarter remaining.

  4. Observation and Consultation: The Lead TA observes a section led by each new TA to provide personalized feedback. I also hold weekly office hours specifically to address teaching-related concerns from TAs across the department.

By moving through this cycle (teach → feedback → reflect → improve) we hope to encourage metacognition, helping TAs grow as educators long after the course ends.

Who is taking CS 501?

Before diving into the redesign, it helps to understand the audience. Interestingly, CS 501 is mostly taken by students who are not yet TAs. This Fall, of the 45 students enrolled, only 11 held a concurrent TA position.

CS 501 Enrollment Breakdown

This has a huge implication for the course design: teaching is a hands-on skill that requires practice. Because most students don’t have a real classroom yet, we have to create a simulated environment where they can “get their hands dirty” and practice what they’ve learned.

The demographics are also unique:

CS 501 Student Demographics

This creates an interesting classroom dynamic: half of the students have specifically chosen to be there to build a skill, while the other half are fulfilling a professional requirement. Balancing these different motivations was a key consideration in my redesign.

What’s New

I won’t go into full detail on how CS 501 was run in the past, but if you are curious, the syllabus, assignments, and lecture slides from the last iteration are accessible here. These materials were thoughtfully developed by previous CS Lead TAs, including Zach, Yegi, Vaishali, and others before them.

In this section, I’ll focus on the key “deltas”, which are the specific ways the updated version differs from previous iterations. I’ve organized these changes around six guiding principles, explaining how each one informed the updates I made.

A quick note on word choice to avoid confusion:

Principle 1: Respecting People’s Time

You may be surprised that such an obvious thing is my first principle, but I sensed this was where some of the frustration with previous iterations of CS 501 originated. Most trainees are incredibly busy, balancing heavy schoolwork (for senior BS or MS students) or competing research responsibilities (for junior PhD students).

Historically, the training course required a high time commitment relative to the perceived density of the content. Trainees had to attend a weekly one-hour seminar during dinner time, but the core content of each seminar often filled only 20–30 minutes of that hour, according to the grapevine and my own experience. In many cases, the time spent traveling to the classroom exceeded the length of the actual instruction. When you combine this with a strict attendance policy and the fact that the course is mandatory for many, it’s easy to see why motivation and engagement might dip.

My fix was simple:

Principle 2: Structure Matters

When starting out as a fresh TA, I found classroom instruction to be the most daunting task. How was I going to fill an entire hour by just talking? Where do I even start to plan my instruction? Since the majority of CS 501 is about training people for the classroom, I was probably not alone in feeling lost as a new TA.

In response to this, the course previously covered assorted tips ranging from effective boardwork to how to facilitate group work. However, these tips sometimes felt scattered and unrelated. It wasn’t always clear why these instructional devices were effective, when they should be used, or how they fit together into a coherent strategy. This year, I revamped the curriculum to center around the backward design recipe. This provides a clear framework that trainees can follow, which can be broken down into three steps:

  1. Design student-centered learning outcomes.
  2. Determine how those outcomes can be measured.
  3. Build classroom activities and instructional materials to achieve those outcomes.

Besides being time-tested and reusable, this recipe helps trainees avoid the pitfalls of instruction-centered teaching that prioritizes what we want to cover as instructors. Instead, once we know what our goals for students are, those goals become our goalposts. Any instructional question about what we should or should not do can be answered by going back to those goals. If an activity contributes to the goal, we do it. Otherwise, we cut it out or adjust our goalposts if we decide the activity is actually important for another reason.

I covered various aspects of this recipe in four of the five class meetings:

I drew a lot of inspiration from the wonderful Pillars of Teaching Assistantship workshop series offered by the UCSB Office of Teaching and Learning, as well as materials from Grad 210 (College and University Teaching). The slides I used can be found in the Modules section of the course website.

Principle 3: Show, Don’t Just Tell

A key choice I made when designing these lessons was to incorporate modeling. This means showing how instructional practices actually look in a real classroom setting rather than just talking about them.

Modeling backward design and learning outcomes

I made sure to start every class meeting by discussing the learning outcomes (LOs) of the day. In fact, in one of the classes, I started with a conventional agenda slide that merely listed the topics to be covered. Agenda Slide

I then immediately contrasted that with a slide showing measurable LOs that focus on student learning. This highlighted how the latter can be much clearer signposts to guide student attention and prepare them mentally for what is to come.

Learning Outcomes Slide

Modeling active learning

The class on active learning introduces a range of activities that trainees can choose from. However, there is a real chance a trainee has not seen many of them, since CS courses are often lecture-heavy with little student interaction. I explicitly incorporated different types of active learning activities many times in class to help trainees get a feel for how they can be run.

For example, a key outcome of CS 501 is for trainees to be aware of university resources and policies that support student learning and their own well-being. In previous iterations, these resources were taught through slide presentations scattered across several classes. This time, I consolidated the most important policies and resources into one 50-minute class. To make this more engaging, I devised several imaginary scenarios that might arise in a student-TA interaction.

Instead of just lecturing, I asked the class to gather into groups of three or four to discuss how they would approach each scenario. Through these discussions, trainees could draw on their prior knowledge of various UCSB offices. Since many students in the class are BS/MS students at UCSB, they had often heard of or utilized these resources before. I positioned myself as a facilitator for the discussion, occasionally highlighting policies that students were less likely to be aware of, such as the university’s distressed student protocol.

Other activities I modeled include think-pair-share sessions, where trainees revised their drafted LOs with their neighbors, and worksheets for drafting teaching philosophy statements.

Modeling lab instruction

While these topics are relevant to both discussion and lab sections, labs are a unique format that some trainees might not have encountered in their previous education. I saw a good opportunity to model this format using the class meeting on autograder construction, which is a new topic I added this year.

Autograders are important since most CS courses at UCSB use them. Writing sound autograders requires technical knowledge so that students cannot easily exploit them, as well as an understanding of human psychology so that the autograder provides helpful feedback without encouraging overreliance on it for debugging.

Since autograders are just programs, a lab format seemed like a perfect way to teach them. I designed a brand new lab where trainees first listen to a short lecture on how autograders work at a high level. They then work on a structured assignment that asks them to modify a white-box autograder and then hack a black-box autograder to see how exploitable they are without security. These tasks are supplemented with reflection prompts on academic integrity and the limits of automated assessments.

Principle 4: More Practice, More Feedback

Previous iterations of CS 501 had some great assignments to help trainees practice and observe teaching. These included teaching observations, where non-TA trainees watched TA trainees lead their sections, and micro-teaching demos, where each non-TA trainee prepared and delivered a mini-lesson to the class. I largely kept these assignments as they were, but I reworked the implementation to address some practical issues that limited their effectiveness in the past.

To start, for both assignments, trainees used to rate each other’s teaching with numeric scores across several metrics. They would use a non-anonymous form and hand it back to the person being observed immediately afterward. The template was structured in a way that made written feedback feel like an afterthought. You can probably imagine that it isn’t very helpful to be rated a 3/5 on “question answering” without further comments. Similarly, trainees often received a 5/5 on every metric because the observer was a friend and didn’t want to make things awkward.

To remedy this, I replaced the old form with a new template that prioritizes written feedback. This template was designed by Lisa Berry and used in her Grad 210 course, where we did similar teaching demos. When I took her class, I found this format to be very effective at generating constructive feedback. After using it this quarter, I can say it was a success. The quality of the comments was much higher, and trainees seemed to take the feedback more seriously.

The next issue involved the micro-teaching demos. These are essential for non-TA trainees because they are often the only way to practice what they learned and get feedback. Previously, all demos happened during a single class period where trainees gathered into small groups of three to five. The presentation medium was very constrained. No slideshows were allowed because there was only one projector in the room, and only a few groups had access to a chalkboard. Furthermore, it was impossible for the instructor to provide substantial individual feedback because they could only listen to one group at a time.

This time, because the core content of the course was compressed into the first five weeks, we had Weeks 6 through 10 completely free. Since the enrollment was lower this year (around 45 students compared to 60 in previous years), I was able to organize smaller demo sessions. In each class from Weeks 6 to 10, a small group of six trainees would deliver a seven-minute demo. The rest of us listened intently and wrote down our comments. I then collected, aggregated, and sent the feedback back to each presenter.

Principle 5: Promoting Metacognition

The second part of the equation that closes the loop is actively parsing feedback and, hopefully, integrating it into our future teaching. I feel this is especially fruitful for trainees who are concurrently TAs. Since they are delivering classroom instruction every week, they are already in a cycle of receiving implicit feedback from their students.

I think all they need is a little nudge to intentionally look back on their experience periodically. To provide this, I added a weekly journal assignment. I actually borrowed this idea from a fellow Lead TA during the Lead TA Institute. In these journals, TAs document the time spent on teaching activities and reflect on their experiences from the past week using a few simple prompts. Practically, these journals also serve as a reservoir of ideas for the teaching philosophy statement (TPS) assignment, where they critically reflect on their personal approach to teaching and learning.

I debated whether to keep the TPS assignment, but in the end, I decided to keep it. As I recently completed a draft of my own TPS for academic jobs, it occurred to me just how much of my current philosophy originated from the first draft I wrote four years ago for CS 501. Even though I had very little teaching experience at that time, it made me reflect on my beliefs about learning. (I now understand these beliefs are rooted in the constructivism paradigm, and they have continued to influence my pedagogy ever since.

In the past, the course taught trainees how to draft a TPS using an assortment of “do’s and don’ts.” I revised this content to include more structured worksheet activities, which I adapted from a UCSB Office of Teaching and Learning workshop. These activities give the class plenty of time to reflect on their own teaching and learning experiences. They then distill these reflections into a small number of core principles. I provide a template to help them organize these reflections into clearly structured writing. Throughout this process, the emphasis is on the reflection itself rather than the quality of the prose. After all, these trainees aren’t yet writing statements for a faculty search committee.

Principle 6: Community

Although not an official goal of CS 501, I thought building a community for trainees would be really nice. Half of them are first-year PhD students, and CS 501 is likely the only course where they get to meet every single one of their fellow classmates. It is a great place to start building connections with other PhD and MS students whom they might meet again in future courses. Plus, having a support network is crucial for surviving CS grad school, especially considering how challenging the journey can be.

To this end, I incorporated a few simple things into the course. For example, I dedicated time in the first class meeting for everyone to introduce themselves with a fun memory game activity:

Memory Game Activity

I also set up a CS 501 Discord server for non-FERPA course communications to keep things informal. Finally, I tried to encourage connections through regular group activities, teaching observations, and peer feedback sessions.

Reflections

I won’t be posting the course evaluation ratings for the updated CS 501 here. I don’t have access to previous reports to provide adequate context, and numbers often don’t tell the whole story. Based on the written comments, however, some trainees seemed to enjoy the changes:

“I hear this course is much much better than it was previously and I credit you specifically for that. I think you did a great job teaching and covering the material and structuring the course in a way that covers all of the topics that we need to know.”

I am also heartened to learn that “the environment made everything much less intimidating.” I was not alone in finding some aspects of TAing daunting at the beginning, and I am glad the course made it slightly less so for others.

I want to end this blog with a list of things I wish I had done differently. This is intended for future CS Lead TAs, should they choose to base their instruction on this version.

Teaching Demos

This year, CS 501 saw a decrease in enrollment, from over 60 trainees in previous years to 45. This made our current format of teaching demos possible, where students sign up for one class between Weeks 6 and 10 to give a short presentation. However, even with the smaller class size, the capacity of this format was stretched to its limit.

Some students ended up having to record their presentations and perform peer evaluations asynchronously. For the in-person demos, fitting seven presentations into 50 minutes left very little time for trainees to incorporate substantial activities, like worksheets, or to handle questions from the audience. Some demos also had to be cut short. In the future, in addition to using regular class meetings, we could move some demos to non-class times, such as during finals week.

TA-Student Interaction

Most of the current materials revolve around classroom instruction. However, TAs spend an equal amount of time, and often more, interacting with students outside of class in office hours, on Q&A forums, and through emails. A range of challenging issues arise in these situations, but they are diverse enough that we don’t yet have a uniform theory for teaching trainees how to handle them.

For example, when I ran the workshop on leading computer-based labs, many participants voiced concerns about being unable to help students resolve complex programming issues during office hours. In my experience, fielding questions in office hours is very much an art. In future iterations of 501, it would be great to address these situations in class, perhaps by providing guiding principles or at least a platform for trainees to anticipate issues and collectively brainstorm strategies.

Manual Grading

Since I added a completely new module on autograders this year, I had to remove some older materials. I chose to cut the content on manual grading and implicit bias. In future iterations, we should probably find a way to add these back. Many classes are moving assessments back into the classroom due to the surge in generative AI usage among college students.

Customized Course Evaluation Questions

CS 501 is not a typical CS course, nor is it a standard university course. The pre-defined questions on the end-of-term evaluations gave very little insight into how trainees benefited from each major component of the class. In the future, it will help tremendously to add custom questions to the survey. This will provide the specific feedback needed to continue improving and updating the course.

Conclusion

I definitely learned as much as, if not more than, I taught while redesigning and running CS 501 this Fall. While there is always room for more improvement, I am happy with the progress we made in making the training more practical and structured. If you took CS 501 this Fall, I would love to hear your thoughts (in case you didn’t get a chance to fill out the course evaluation form). I hope this blog serves as a helpful roadmap for whoever takes the reigns of the program next year!